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

[TigerSHARC]

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

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

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

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

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

[psL]

Драйвер АЦП, имхо, по простому - это символьное устройство: данные накапливаются в fifo, размер которого превышает максимальное время опроса. Метка времени отсчетам не нужна, потому что если частота дискретизации постоянная, время отсчета можно узнать по номеру отсчета в буфере, относительно последнего.
Если АЦП является неотьемлемой частью системы, т.е. подключен в течение всего времени работы устройства, udev не нужен, потому что при этом драйвер включается на шину при старте ядра в MACHINE_START. udev нужен только при p&p.
Регистрация устройства в /dev производится последовательностью вызовов register_chrdev, class_create, device_create при probe драйвера. После того как драйвер поднимется ядром при старте, ему доступны зарегистрированные в file_operations вызовы.
Что касается sysfs, это просто интерфейс между драйвером и юзерспейсом, можно пользовать, а можно и нет. Как альтернатива, например, вызов ioctl драйвера. Кроме того, sysfs удобен с т.з. настройки устройства, выдачи статистики драйвера и т.п. поскольку позволяет работать c устройством через echo/cat из консоли.
Что касается встраивания устройства в различные фреймфорки (v4l) это, имхо, имеет смысл в случае, когда необходимо типовое использование устройства в основном в сторонних программах, в случае специфической подсистемы видимо это избыточно.

[Tarbal]

Драйвер АЦП, имхо, по простому - это символьное устройство: данные накапливаются в fifo, размер которого превышает максимальное время опроса. Метка времени отсчетам не нужна, потому что если частота дискретизации постоянная, время отсчета можно узнать по номеру отсчета в буфере, относительно последнего.
Если АЦП является неотьемлемой частью системы, т.е. подключен в течение всего времени работы устройства, udev не нужен, потому что при этом драйвер включается на шину при старте ядра в MACHINE_START. udev нужен только при p&p.
Регистрация устройства в /dev производится последовательностью вызовов register_chrdev, class_create, device_create при probe драйвера. После того как драйвер поднимется ядром при старте, ему доступны зарегистрированные в file_operations вызовы.
Что касается sysfs, это просто интерфейс между драйвером и юзерспейсом, можно пользовать, а можно и нет. Как альтернатива, например, вызов ioctl драйвера. Кроме того, sysfs удобен с т.з. настройки устройства, выдачи статистики драйвера и т.п. поскольку позволяет работать c устройством через echo/cat из консоли.
Что касается встраивания устройства в различные фреймфорки (v4l) это, имхо, имеет смысл в случае, когда необходимо типовое использование устройства в основном в сторонних программах, в случае специфической подсистемы видимо это избыточно.

Нет желания спорить по всем пунктам, по которым не согласен. Лишь о главном.
V4L это video for Linux. Я не вижу никакого смысла делать драйвер АЦП в видео системе. Кстати уже давно используется новая версия V4L2.
То что вы называете fifo, используется не только в видео фор линукс, но и в сетевых драйверах, USB драйверах, фрейм буферах и т.д.. Это называется ПДП (DMA). Зачем надо усложнять драйвер ненужными наворотами из видео системы, когда можно написать простой с использованием ПДП?


посмотите что такое udev и как он создает пайпы для всех устройств, а не только PnP
http://www.iredale.net/p/by-title/introduc...tion-latest.pdf

[psL]

V4L это video for Linux. Я не вижу никакого смысла делать драйвер АЦП в видео системе. Кстати уже давно используется новая версия V4L2.
То что вы называете fifo, используется не только в видео фор линукс, но и в сетевых драйверах, USB драйверах, фрейм буферах и т.д.. Это называется ПДП (DMA). Зачем надо усложнять драйвер ненужными наворотами из видео системы, когда можно написать простой с использованием ПДП?

посмотите что такое udev и как он создает пайпы для всех устройств, а не только PnP
http://www.iredale.net/p/by-title/introduc...tion-latest.pdf

Не нужно путать мягкое с мокрым. FIFO - это способ организации памяти по принципу первый вошел, первый вышел, а ПДП - механизм обмена периферии с памятью на прямую, без участия процессора. При том, что fifo можно заполнять хоть по полингу, а ПДП м.б. к одному адресу памяти
udev для встраиваемых систем вообще избыточен, поскольку состав подключаемого оборудования известен заранее и находится уже на борту. Обычно используют mdev из bb
Хотя может вы про adc на usb или pci шине.
V4L (про 2 в курсе) приведен как пример (было в предыдущих постах), по поводу АЦП в V4L - во-первых, видеосигналы и АЦП бывают разные, во-вторых, аудиопоток в видео никто не отменял

[Tarbal]

по поводу АЦП в V4L - во-первых, видеосигналы и АЦП бывают разные, во-вторых, аудиопоток в видео никто не отменял

Вы о чем? Вопрос стоит как проще сделать драйвер для АЦП, а не о способах использования АЦП в муьтимедиа даже если для вас это наиболее удобный способ подключить АЦП.

Не нужно путать мягкое с мокрым. FIFO - это способ организации памяти по принципу первый вошел, первый вышел, а ПДП - механизм обмена периферии с памятью на прямую, без участия процессора. При том, что fifo можно заполнять хоть по полингу, а ПДП м.б. к одному адресу памятиwink.gif

ПДП может
- скопировать блок памяти в другое место
- пересылать значение из фиксированного адреса в инкрементируемый поинтер (назовем так для краткости изложения)
- пересылать из инкрементируемого адреса в фиксированный.

Я натянул второй метод на фифо, хотя он гораздо удобнее -- он сразу доставит данные.
Но если вы настаиваете, то имея ПДП фифо не нужен как страшный сон.

udev для встраиваемых систем вообще избыточен, поскольку состав подключаемого оборудования известен заранее и находится уже на борту. Обычно используют mdev из bb

Это уже придирка. Я имел ввиду udev как концепцию в противовес методу делать пайпы вручную.


Сообщение отредактировал Tarbal - Aug 31 2013, 17:15

[sasamy]

Но если вы настаиваете, то имея ПДП фифо не нужен как страшный сон.

Скоростная периферия работает не с контроллером DMA а сама является bus master и фифо там нужен чтобы смягчить нагрузку на шину. Периферии попроще - тоже самое, только чтобы упростить жизнь контроллеру DMA у которого каналов до и более. Без фифо любит делать атмел - кривейшая периферия наверно из того с чем встречался. Хотя я вас возможно неправильно понял (тут вы сами виноваты) и имеется ввиду фифо в общей памяти а не локальная память периферийных устройств, так без буферов для DMA которые в очередь как фифо выстраиваются ни одна нормальная ОС не обходится.

Сообщение отредактировал sasamy - Aug 31 2013, 18:07

[Tarbal]

Скоростная периферия работает не с контроллером DMA а сама является bus master и фифо там нужен чтобы смягчить нагрузку на шину. Периферии попроще - тоже самое, только чтобы упростить жизнь контроллеру DMA у которого каналов до и более. Без фифо любит делать атмел - кривейшая периферия наверно из того с чем встречался.

Я с этим не спорю.
Разве вопрос стоит о том как устроена скоростная периферия?
Давайте не будем уходить в теорию в то время, когда человеку надо решить его конкретную проблему.
Был вопрос как проще сделать драйвер для АЦП и каким способом сделать это правильно, чтобы /sys был заполнен необходимыми псевфо файлами. Я предложил как это сделать. Что имеется ввиду под фифо в контексте данной задачи я смутно себе представляю. Надо поставить какой-то дополнительный чип? Или как? Исполнить его программно в интеррапте? В то же время процессор имеет немерянное число каналов ПДП, один из которых прекрасно справится с работой.
В то же время использование мультимедиа драйверов в качестве прототипа я считаю не лучшим подходом.

[sasamy]

Был вопрос как проще сделать драйвер для АЦП и каким способом сделать это правильно

Пример V4l2 - это как можно не напрягая мозг использовать фреймворк у которого есть готовые средства для управления памятью ( буфер DMA + метаинформация) буферы отображаются в памяти пользовательского процесса и позволяют избежать лишнего копирования за счет CPU которе неизбежно будет при использовании read/write (copy_to_user()/copy_from_user() )

Что имеется ввиду под фифо в контексте данной задачи

Кольцевая очередь (циклический двусвязный список) из этих буферов (вернее их там две). Кто и по какому интерфейсу заполняет буферы - вообще не важно, хоть за счет ЦПУ.

В то же время использование мультимедиа драйверов в качестве прототипа я считаю не лучшим подходом.

Естественно, есть готовые фреймворки, но ТС непременно хочет _свой_, он так и написал.

Сообщение отредактировал sasamy - Aug 31 2013, 19:08

[Tarbal]

Пример V4l2 - это как можно не напрягая мозг использовать фреймворк у которого есть готовые средства для управления памятью ( буфер DMA + метаинформация) буферы отображаются в памяти пользовательского процесса и позволяют избежать лишнего копирования за счет CPU которе неизбежно будет при использовании read/write (copy_to_user()/copy_from_user() )

Кому как. Мне так легче сделать как требуется. Я так привык.

Кольцевая очередь (циклический двусвязный список) из этих буферов (вернее их там две). Кто и по какому интерфейсу заполняет буферы - вообще не важно, хоть за счет ЦПУ.

Как закоренелый реалтаймщик я не принимаю решений за счет ЦПУ, когда есть хардвер, которуй не только для этой задачи предназначен, но и сделает работу эффективнее.
Я не спорю насчет мультимедиа, потому как не делал таких драйверовm, а код ковырять просто для поиска доказательств лень, однако в драйвере фрейм буфера используется ПДП. Подозреваю, что если копнуть, то и в мултимедиа фифо буферами оперирует, которые на низком уровне заполнены при помощи ПДП.

Естественно, есть готовые фреймворки, но ТС непременно хочет _свой_, он так и написал.

На мой взгляд он абсолютно прав. Надо делать так как надо, а не так как получится.



Сообщение отредактировал Tarbal - Aug 31 2013, 19:57

[sasamy]

я не принимаю решений за счет ЦПУ

При чем тут ЦПУ ? вы похоже ни слова не поняли из того что я написал.

На мой взгляд он абсолютно прав. Надо делать так как надо, а не так как получится.

Рекомендую эти два поста прочитать и сходить по ссылкам которые там

http://electronix.ru/forum/index.php?showt...t&p=1175040

если делать правильно о таких вещах которые вы тут про ноды и шины описываете вообще не надо думать, за это отвечает общий код для класса соотвествующих устройств, вы пишете только код специфичный для вашего устройства - ага ООП стиль во все поля. Даже если приспичило велосипед изобрести - есть специальный класс misc device
http://lxr.free-electrons.com/source/drivers/char/misc.c

Сообщение отредактировал sasamy - Sep 2 2013, 14:26