Перейти к содержанию
    

Интересно стало: есть ли здесь кто-нибудь кто писал драйвер для фреймворка и отладил его? Под фреймворком я имею ввиду что-нибудь из COMEDI, IIO или ZIO.

Изменено пользователем Tarbal

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Интересно стало: есть ли здесь кто-нибудь кто писал драйвер для фреймворка и отладил его? Под фреймворком я имею ввиду что-нибудь из COMEDI, IIO или ZIO.

 

В IIO полно готовых драйверов в ванильном ядре даже в основной ветке а не в staging , для того же атмеловского ADC есть готовые драйверы и триггер аппартаный на TCB он поддерживает. Проблема в этом

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

 

то что хотел ТС не сделать с ядерными драйверами SPI например на at91, нужно все по-своему настраивать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Есть, писали :)

 

Comedi самый старый фреймворк, для него больше всего драйверов. К тому же, он поддерживает RTAI, что делает его весьма популярным (у буржуев, во всяком случае). Также он поддерживает все виды обмена - read/write, mmap, polling, triggering etc. Поэтому я и назвал его стандартом де-факто.

 

Еще полезно посмотреть обсуждения в мейлистах как самого COMEDI, так и RTAI - там обсуждались почти все сценарии использования.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Comedi самый старый фреймворк, для него больше всего драйверов. К тому же, он поддерживает RTAI, что делает его весьма популярным

 

RTAI конечно решает часть проблем, но опять же драйвер SPI надо переписывать под него, к тому же все эти "тонкие" ядра и виртуализация все менее актуальны когда появляются гибридные SoC

http://www.freescale.com/webapp/sps/site/p....jsp?code=VF6xx

 

и есть готовые решения для коммуникаций

https://linuxlink.timesys.com/docs/wiki/eng...uide_vybrid_mcc

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Ну и порт надо настроить, ведь я не буду использивать PCI, а подключу АЦП прямо к одному из портов ЦПУ.

 

RTAI не поддерживает этот процессор

http://www.rtai.dk/cgi-bin/gratiswiki.pl?RTAI_On_ARM

 

Изменено пользователем Tarbal

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Ну и порт надо настроить, ведь я не буду использивать PCI, а подключу АЦП прямо к одному из портов ЦПУ.

..

 

Так, как указано здесь http://www.comedi.org/doc/driverwriting.html

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Так, как указано здесь http://www.comedi.org/doc/driverwriting.html

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

 

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

 

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

Меня реал-тайм проблемы не остановят :)

 

Изменено пользователем Tarbal

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Это тоже кернельный фреймворк :) Преимущества как и у любого фреймворка - дополнительный слой абстракции. Т.е. там уже есть понятия как девайсы, сабдевайсы, каналы, диапазоны измерений, 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 абстрактого драйвера

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

Изменено пользователем Tarbal

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Моя проблема в том, что в ссылке, что вы дали под линком:

How to use DMA and interrupts?

 

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

 

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

 

Мне мало информации, чтобы понять как это работает, а о том как писать драйверы под кернел и куча книг и в интернете полно информации.

 

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

 

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

 

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

 

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

 

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

Изменено пользователем vshemm

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Изменено пользователем Tarbal

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Кстати 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.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вопрос знатокам.

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

 

Возникают вопросы:

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

Какие примеры смотреть?

 

Как сделать стандартный (мне не нравится сектантское название "сырой") драйвер я знаю.

example:

drivers/net/fec.c

Изменено пользователем Tarbal

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вопрос знатокам.

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

 

Возникают вопросы:

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

Какие примеры смотреть?

 

Выбор там небольшой - 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 для выделения ресурсов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Выбор там небольшой - 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ак сделать стандартный драйвер я знаю. У меня вопрос как сделать драйвер для подобного устройства с использованием фреймворков.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...