Драйвер, написать самому Опции

[Dubov]

Стало необходимо написать свой драйвер SPI устройства. Драйвер для работы из пользовательского пространства не годится, так как данные нужно принимать от АЦП по SPI в DMA буфер непрерывно(пропуски в данных недопускаются) со скоростью 100К семплов в секунду, чего нельзя добится из user space. Из пользовательского пространства я планирую только забирать блоками через драйвер.
Для моей платформы есть файлы для работы с spi в папке /drivers/spi/

Вопрос:
файлы в /drivers/spi - это всё что нужно для написания своего драйвера(модуля ядра)?

Просто ранее я писал только standalone приложения и смущает отсутствие в Linux процедур прямого обращения к регистрам (здесь всё через обёртки какие то мудрёные).
В линукс смущает то что нету так привычных мне *.h файлов где через дефайны описаны адреса всех регистров (по мануалу).

Сообщение отредактировал Dubov - Nov 12 2012, 10:27

[vshemm]

Простейший способ "в лоб" - это char device, внутри которого 2 буфера, в один пишем, другой готов к чтению
из приложения через read(). При заполнении одного буфера DMA перезапускается на другой буфер. Либо "дмашить"
в кольцевой буфер. Как сделать лучше - см. спеки на железо.

Есть нюансы Во-первых, вам нужно перезапустить DMA за 10мкс (по прерыванию, например). Не факт, что вы
успеете, т.к. если обращение к регистру занимает (к примеру) 1мкс, а вам нужно перезаписать 5шт - это уже 10мкс.
Некоторые DMA умны настолько, что могут сами брать дескрипторы из памяти и закольцовываться по их списку.
В этом случае перезапускать DMA нет необходимости. Если это не так и терять данные нельзя вообще - то вы
близки к теоретическому пределу железа - опять же, см. спеки на железо.
Во-вторых, при использовании своего char dev нужно убедиться, что никто через линуксовый SPI-фреймворк не
обращается к SPI контроллеру (и через DMA фреймворк тоже).

Что касается "сложности" драйверов в linux - это нормально На самом деле там все довольно просто - почти
все разбито на слои и фреймворки для облегчения портируемости и расширения. Фактически, там используется ООП
подход, со всеми вытекающими. В итоге вход в это хозяйство усложняется (и кажется странным для людей
работавших до этого с МК осями/bare metal), но иначе никак. Вообще, такой подход характерен для всех
не-tiny мультиплатформенных ОС.

P.S. Есть фреймворк comedi, все еще стандарт де-факто для data acquisition. Но 100К семплов/с - немалая величина,
и с ней оверхед фреймворка может стать неприемлемым.