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

[TigerSHARC]

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

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

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

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

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

[Tarbal]

Моя проблема в том, что в ссылке, что вы дали под линком:
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 абстрактого драйвера

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

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

[sasamy]

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

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

Even if no physical bus is involved with ZIO, by relying on this software abstraction we are able to deal with several devices of the same type.

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