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

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

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

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

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



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

Моя проблема в том, что в ссылке, что вы дали под линком:
How to use DMA and interrupts?

Вот такая страничка.

http://www.comedi.org/doc/drivercallbacks.html

Мне мало информации, чтобы понять как это работает, а о том как писать драйверы под кернел и куча книг и в интернете полно информации. Про ПДП в нарушение обещания данного в названии ссылки ни слова не нашел. Вы сами драйвер писали? Для нового устройства. Так чтобы там ДМА контроллер был специфический. Я подозреваю, что там начнется песня с пляской.

Вот сейчас мы работаем со стандартной Линукс библиотекой OPAL она нужна для организации видео телефонных звонков через интернет. Автор легко добавил необходимые нам свойства и оно легко заработало на х86 железе. А дальше начались сюрпризы с портингом на iMX53. И это заметьте все в пространстве пользователя происходит. Ни строчки из кернела не затронуто. Автор библиотеки уже два месяца бьётся над решением возникающих проблем.

Вы поймите, я не против использования фреймворка, мне интересно разобраться если оно мне надо.

Кстати ZIO должна быть серьёзной системой, но самое смешное, что там нужно знать ту информацию, которую я давал. Вот выдержка из manual:

3 The Bus Abstraction
The ZIO core module is called zio.ko and it creates a new bus item in Linux. A bus is a
software abstraction for kernel-related software modules; it splits the role of the device from the
role of the driver. In order to have a new peripheral working in your system you thus need both
items: the driver is in charge of any device that appears in the system, while the device is a data
structure that describes the parameters of the specific hardware instance. The two structures
are bound by calling a match function, which is at the core of the bus abstraction. If the device
and the driver match, the driver is asked to manage the new device instance.





Метод бритвы Оккама призывает делать вещи проще.


зачем read/write драйверы содержат IOCTL функции для этой цели, Второй метод через procfs.

А вы в \comedi\drivers\skel.c заглядывали? Там половина текста - комментарии что и как и зачем и когда реализовывать. И это актуальная инфа. В отличие от "книг по..". Так или иначе разбираться с этим придется, и чтение кода просто необходимо. Это нормально для инженера, перестаньте слушать маркетинговую чушь

Ок, опишу свои действия, если бы мне поставили подобную задачу (при условии, что я такого раньше не делал). Первое - это провести исследование на предмет решения подобных проблем. Т.е. сразу же появляются варианты - raw driver, comedi, IIO, ZIO... Это пара часов. Далее, я бы изучил за и против данных подходов с точки зрения реальной задачи (для чего этот драйвер пишется, сроки, бюджет, кому он нужен, требования, срок жизни, стоимость поддержки и т.п.). Это день, максимум, два. В результате у меня на руках была бы _аргументированная_ точка зрения, почему я выбрал то и то. Все, далее согласование (если нужно) и кодирование. Профит.

Конечно, это по-хорошему должны делать архитекты/техлиды или хотя бы сеньоры. А кодировать можно уже поручить и кодеру. А вы хотите, чтобы на форуме телепаты сказали как _вам_ лучше? Не бывает такого. А если и бывает, то либо лгут, либо ораторы идиоты, либо банальщина полная.

Так что вперед, изучайте доки и код, направление задано. Это единственный путь

З.Ы. Доки пошаговые есть, код есть, мейллисты (списки рассылки есть) - это не недостаток информации, а избыток

TigerShark если у вас будут вопросы по реализации стандартного Линукс драйвера я вам отвечу. Какой процессор и какой АЦП вы используете?

Главное чтобы вы понимали для чего им понадобилась своя абстрактная шина



на то он и фреймворк - это код для целого класса устройств. Теперь подумайте для чего вы все это рассказывали ТС.

Вопрос знатокам.
В данный момент я делаю драйвер ethernet порта на KSZ8863 of Micrel. Мне надо, чтобы третий порт был подключен к моему процессору iMX53, а два остальных могли быть использованы для подключения к сети. Причем надо обеспечить сквозное прохождение не предназначенных моему ЦПУ пакетов.

Возникают вопросы:
Какой фреймворк мне лучше использовать?
Какие примеры смотреть?

Как сделать стандартный (мне не нравится сектантское название "сырой") драйвер я знаю.
example:
drivers/net/fec.c

Выбор там небольшой - network devices отдельный класс устройств, а KSZ8863 вообще phy device (PHY Abstraction Layer).
Документация - /Documentation/networking/
MAC драйвер - /drivers/net/ethernet/freescale/
KSZ8863 драйвер - /drivers/net/phy/micrel.c

Настройку свича проще всего сделать прошив в EEPROM KSZ8863 нужные настройки через i2c или spi (прямо из юзермода). Если EEPROM или i2c/spi отсутствуют на вашей борде, тогда настройку можно сделать через mdio bus (MII интерфейс) который точно подключен.

Ну и может понадобиться пошаманить над /arch/arm/mach-imx для выделения ресурсов.

Спасибо.

Kак сделать стандартный драйвер я знаю. У меня вопрос как сделать драйвер для подобного устройства с использованием фреймворков.

Ваш вопрос к теме АЦП вроде не имеет отношения ?

http://lwn.net/Articles/302333/
http://electronix.ru/forum/index.php?showtopic=102499

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