[TigerSHARC 0]

Если Вы про платы сбора данных типа NI то скорей всего там с АЦП работает ПЛИСина, которая является также буфером, тогда требования для процессора и ОС в основном касаются пропускной способности шины, задержки на реакцию уже не так важны.

То что касается Вашего вопроса ко мне, то тут все проще -никаких ядер у меня нет и ничего встраивать не нужно. Все обрабатывается обычным прерыванием, даже не стал заморачиваться с FIQ. Быстродействия хватает с лихвой. Я не понимаю почему нельзя сделать простой обработчик прерываний в ОС, который бы работал так как и задумано для прерывания- прерывал текущую задачу, отрабатывал и потом возвращался к прерванной задаче с минимальными издержками.

Я думаю Вам однозначно надо предусмотреть буфер на PLD или какомто малоногом контроллере, который будет заниматься лишь сбором данных с АЦП. Обмен между процами можно сделать по SDIO через DMA. Это у меня был как один из запасных вариантов.

Либо еще вариант -настроить проц на считывание АЦП через ДМА, используя 2 канала ДМА в режиме качелей. Но тут надо досконально знать железо и его особенности.

Зачем буфер на PLD? если можно кольцевой буфер сделать в самом драйвере. В драйвере же считывать через DMA по SPI данные с АЦП.

[Alexashka 0]

Зачем буфер на PLD? если можно кольцевой буфер сделать в самом драйвере. В драйвере же считывать через DMA по SPI данные с АЦП.

а что за проц? и сколько Msample/s нужно захватывать?

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

[Dubov 0]

По-моему тоже можно непарится насчёт буфера и делать его в драйвере, если только частота невокая, порядка сотен килогерц

Изменено 13 августа, 2012 пользователем Dubov

[aaarrr 69]

По-моему тоже можно непарится насчёт буфера и делать его в драйвере, если только частота невокая, порядка сотен килогерц

Сотни кГц? Я бы очень сильно напрягся, если бы приходилось дергать систему с частотой 10кГц, а уж о сотнях не стал бы и думать - это просто похоронить производительность на оверхеде от прерываний.

[TigerSHARC 0]

Сотни кГц? Я бы очень сильно напрягся, если бы приходилось дергать систему с частотой 10кГц, а уж о сотнях не стал бы и думать - это просто похоронить производительность на оверхеде от прерываний.

можно по-подробнее?

Просто в исходниках ядра полно драйверов различных АЦП. И разработчики из технической поддержки AD охотно давали советы, когда я спрашивал про тактирование и приём данных от АЦП.

А вы говорите что такое невозможно...

 

P.S. Платформа AT91SAM9G20

Изменено 13 августа, 2012 пользователем TigerSHARC

[aaarrr 69]

можно по-подробнее?

Подробнее о чем? Мне казалось, что все предельно ясно: прерывание = оверхед. Чем чаще прерывание, тем хуже системе в целом.

 

А вы говорите что такое невозможно...

Где я сказал, что невозможно? В некоторых случаях прерываться с "небольшой" частотой "порядка сотен килогерц" может быть и возможно, конечно. Процессоры нынче мощные, никто и не заметит, что 50% времени он проводит на входе и выходе из прерывания.

[Alexashka 0]

Просто в исходниках ядра полно драйверов различных АЦП.

А можно поинтересоваться что за ядро такое? Его можно где скачать-посмотреть?

Кстати, может там и не программно прерывание обрабатывается, а скажем запускает ДМА передачу. Хотя ДМА тоже надо перенастраивать и тут выходит опять-таки надо обрабатывать прерывание уже от ДМА. :05:

[TigerSHARC 0]

Скачайте ванильное ядро Linux. Папка /drivers/staging/iio/adc

есть драйвера, которые обрабатывают аппаратные прерывания от АЦП(сигнал готовности данных) - например AD7606.

[Alexashka 0]

Скачайте ванильное ядро Linux. Папка /drivers/staging/iio/adc

есть драйвера, которые обрабатывают аппаратные прерывания от АЦП(сигнал готовности данных) - например AD7606.

Посмотрел. И возник вопрос -чем в данном случае прерывания от АЦП отличаются от любых других прерываний? Кстати в примерах для АЦП можно задать период опроса АЦП в миллисекундах :)

[TigerSHARC 0]

Ничем не отличаются, те же самые прерывания.

А где вы увидели что можно задать период опроса? В драйвере для AD7606(к примеру), есть понятие триггера, который задаёт частоту тактирования, н вот что интересно - разработчики написали,наряду с аппаратными(для Blackfin), софтовые триггеры, т.е. частота дискретизации АЦП задаётся от GPIO процессора программно, что естественно приводит к ужасающему джиттеру и, например, при загрузке mc сигнал тактирования АЦП просто пропадает, что ожидаемо. Тогда риторический вопрос: "Кому нужен такой клок для АЦП и зачем разработчики его писали?"

Замечания по использованию драйвера: когда пробовал использовать родной драйвер и испольовал в качестве прерывания линию IRQ микропроцессора, видел что процесс softirq жрёт 70% времени процессора (через top смотрел). Мне посоветовали смотреть что не так в драйвере...

В итоге я решил писать свой драйверок(без iio, триггеров и пр.) - просто прерывания, буфер и работа с SPI в одном модуле. Как напишу - буду тестировать.

[Alexashka 0]

В итоге я решил писать свой драйверок(без iio, триггеров и пр.) - просто прерывания, буфер и работа с SPI в одном модуле. Как напишу - буду тестировать.

Ага, именно так и поступил наш программист, о результатах я писал в начале темы. Возможно он не дооптимизировал сборку для RT операций, но даже если бы он получил в 10 раз лучший результат, при наличии такого большого разброса латентности обработки прерываний в linux я бы все равно не был уверен, что система обеспечит требуемые параметры.

Без ОС у меня получился запас почти на порядок с очень жестким и стабильным временем реакции.

[TigerSHARC 0]

Посмотрите вот этот аппарат: uake.ru

Работает по Linux. Частота АЦП 100кГц.

 

P.S. Информация взята с сайта http://www.r-technology.ru/products/exampl...est-electro.php

 

Вроде как всё работает. Думаю проблема решается за счёт применения большого буфера и Linux со своей латентностью забирает данные когда получится, но прерывание отрабатывает чётко и получает данные от АЦП нужное время(в области ядра).

Изменено 16 августа, 2012 пользователем TigerSHARC

[sasamy 0]

А можно поинтересоваться что за ядро такое? Его можно где скачать-посмотреть?

Кстати, может там и не программно прерывание обрабатывается, а скажем запускает ДМА передачу. Хотя ДМА тоже надо перенастраивать и тут выходит опять-таки надо обрабатывать прерывание уже от ДМА. :05:

 

делаете пару буферов для 1000 сэмплов и прерываний нужно уже не 100к а 100, при этом можно уже не думать ни о какой латентности - пока DMA следующий буфер заполняет времени хватит выше крыши.

[TigerSHARC 0]

делаете пару буферов для 1000 сэмплов и прерываний нужно уже не 100к а 100, при этом можно уже не думать ни о какой латентности - пока DMA следующий буфер заполняет времени хватит выше крыши.

прерывание, на уровне ядра, всё равно же отробатывается, когда данные готовы от АЦП, что зависит от частоты дискретизации АЦП, например для 100кГц, нужно 100к прерываний в секунду (а иначе как забирать данные?). В прерывании на уровне ядра: заполняем буфер по указателю через DMA и инкрементируем указатель.

 

А уже медленное пользовательское приложение забирает данные из БОЛЬШОГО буфера ядра.

 

Так ведь? прерывания всё равно нужно отработать быстро.

[sasamy 0]

прерывание, на уровне ядра, всё равно же отробатывается, когда данные готовы от АЦП, что зависит от частоты дискретизации АЦП, например для 100кГц,

 

ну это вы так решили что busy нужно как источник прерывания использовать :)

 

нужно 100к прерываний в секунду (а иначе как забирать данные?).

 

вы же не для ванильного ядра фреймворк делаете как AD для все своей продукции - так что в реализации не стеснены. Например берем процессор atmel и ацп ad7606. Берем вариант Timing Diagrams - Figure 2. CONVST Timing—Reading After a Conversion (Rev. C | Page 9 of 36). У atmel есть 6 таймеров - вам надо всего 2 чтобы сформировать времянки аппаратно - один для CONVST A,CONVST B, второй для клока spi. Переводите spi atmel в slave, busy заводите на CS ad7606 и NSS atmel, его же на внешний триггер таймеров - чтобы засинхронизировать спадающим фронтом busy счетчики таймеров т.к. t_CONV "плавает". Нужно вам 128 клоков второго таймера на период первого (если рассматривать 8 канальный вариант ацп, или 64 чтобы по-быстрей считать с 2 выходов параллельно - тогда второй spi у atmel включить) - в итоге процессор нужно дергать только когда PDC буфер заполнит, при этом данные будут продолжать приниматься в следующий буфер - у PDC два указателя

If the value of next counter is zero, the channel stops transferring data and sets the

appropriate flag. But if the next counter value is greater then zero, the values of the next

pointer/next counter are copied into the current pointer/current counter and the channel resumes

the transfer whereas next pointer/next counter get zero/zero as values

т.о. вам нужно будет в прерывании по заполнению буфера корректировать Receive Next Pointer Register & Receive Next Counter Register чтобы процесс был циклическим и никогда не прерывался.

 

PS можно еще четче сделать - на busy вообще забить, а CS управлять каналом B первого таймера - отсчитывать им (t₁^max + t_CONV^max) и выдать CS active, его спадающий фронт использоватьв качестве триггера второго таймера который формирует клок для spi, соответсвенно нужное количество клоков spi уложить во время CS active - тогда количество сэмплов в секунду будет строго фиксированным.

Изменено 17 августа, 2012 пользователем sasamy