свой драйвер АЦП, два пути Опции

[TigerSHARC]

Надобно написать драйвер(модуль ядра) АЦП.

Прочитав Linux Device Drevers вижу очевидный путь: пишу модуль ядра, который представляет собой standalone программу, принимающую данные от АЦП поп рерыванию от АЦП(сигнал когда данные готовы), и оформленную как собственно модуль/драйвер для Linux (благо доступ к регистрам есть из пространства ядра)

Но! Вижу что устройства "по-хорошему" регистрируются в sysfs, а вот этот путь не совсем понятен.

Вопрос: чем чреват первый путь и и как писать для второго(статейки может какие есть с примерами...)?

Сообщение отредактировал TigerSHARC - Jun 13 2013, 11:30

[Tarbal]

Теперь такая проблема. У меня ЦПУ Freescale Cortex A8 -- iMX53. Насколько легко подогнать драйвер от Фреймворка к моим нуждам? Скажем драйвер параллельного АЦП. Мне надо настроить ДМА и прерывания.
Ну и порт надо настроить, ведь я не буду использивать PCI, а подключу АЦП прямо к одному из портов ЦПУ.

RTAI не поддерживает этот процессор
http://www.rtai.dk/cgi-bin/gratiswiki.pl?RTAI_On_ARM


Сообщение отредактировал Tarbal - Sep 5 2013, 12:31

[vshemm]

Теперь такая проблема. У меня ЦПУ Freescale Cortex A8 -- iMX53. Насколько легко подогнать драйвер от Фреймворка к моим нуждам? Скажем драйвер параллельного АЦП. Мне надо настроить ДМА и прерывания.
Ну и порт надо настроить, ведь я не буду использивать PCI, а подключу АЦП прямо к одному из портов ЦПУ.
..

Так, как указано здесь http://www.comedi.org/doc/driverwriting.html
Т.е. берете скелетон драйвера и имплементируете все необходимые функции (attach, read/write etc). БОльшая часть работы по подгонке - это работа с железом.

[Tarbal]

Так, как указано здесь http://www.comedi.org/doc/driverwriting.html
Т.е. берете скелетон драйвера и имплементируете все необходимые функции (attach, read/write etc). БОльшая часть работы по подгонке - это работа с железом.

И чем это лучше чем написать стандартный Линукс драйвер, кторый не будет зависеть от Фреймворка, требовать установки фреймворковских библиотек и изучения фреймворковских требований и ограничений? Тем более, что Линукс драйвер похожего устройства можно найти в кернеле.

Разве что не требуется понимания реал-тайм проблем. Все спрятано во фреймворке.
Меня реал-тайм проблемы не остановят


Сообщение отредактировал Tarbal - Sep 5 2013, 13:33

[vshemm]

И чем это лучше чем написать стандартный Линукс драйвер, кторый не будет зависеть от Фреймворка, требовать установки фреймворковских библиотек и изучения фреймворковских требований и ограничений? Тем более, что Линукс драйвер похожего устройства можно найти в кернеле.

Это тоже кернельный фреймворк Преимущества как и у любого фреймворка - дополнительный слой абстракции. Т.е. там уже есть понятия как девайсы, сабдевайсы, каналы, диапазоны измерений, ADC, DAC и т.п. с которыми работать удобнее, чем с read/write абстрактого драйвера. Зачем изобретать свой велосипед, если уже есть неплохой. Плюс, под камеди написано много софта (некоторый можно использовать как тесты). Плюс, в linux любят менять интерфейсы ядра, поэтому свой драйвер придется допиливать под разные версии; в камеди же этим занимаются мейнтейнеры и низкоуровневая часть (ваша) меняться не будет.

Плата за это - раздутие кода, хоть в данном случае и небольшое. Изучать там не больше, чем изучать другие интерфейсы с ядром. В любом случае решать вам, может, действительно тупой драйвер будет лучше.

Разве что не требуется понимания реал-тайм проблем. Все спрятано во фреймворке.
Меня реал-тайм проблемы не остановят

Риалтайм проблемы тут не причем, RTAI отдельная песня, позволяющая виртуализировать ядро linux. Так вот, в камеди есть интерфейс для сообщения с этим супервизором. Фактически, это уже не линуксовый драйвер получится, а RTAI-шный (но умеющий общаться с программами в linux).