Частота прерываний под Linux'ом, реально достижимая Опции

[Alexashka]

Господа-товарищи программисты, если у кого опыт, поделитесь пожалуйста с какой максимальной частотой реально можно обрабатывать прерывания под Линухом? Скажем частота 100кГц. Это много? Процессор AT91SAM9G45, тактовая 400МГц, память DDR2 (платка SK-AT91SAM9G45SK-AT91SAM9G45 от Starterkita)

[TigerSHARC]

Господа, я надеюсь действующая полемика не относится к kernel space. Мне нужно писать драйвер АЦП и обрабатывать аппаратные прерывания с частотой в 100кГц. Но всё это на уровне ядра (в модуле ядра).
Думаю такое возможно, а иначе как работают действующие драйверы АЦП?
Тогда возникает вопрос для ТС: почему бы обработку прерываний не вынести в модуль ядра?

P.S. Возможно я чего-то не понимаю.

[Alexashka]

Господа, я надеюсь действующая полемика не относится к kernel space. Мне нужно писать драйвер АЦП и обрабатывать аппаратные прерывания с частотой в 100кГц. Но всё это на уровне ядра (в модуле ядра).
Думаю такое возможно, а иначе как работают действующие драйверы АЦП?
Тогда возникает вопрос для ТС: почему бы обработку прерываний не вынести в модуль ядра?

P.S. Возможно я чего-то не понимаю.

Если Вы про платы сбора данных типа NI то скорей всего там с АЦП работает ПЛИСина, которая является также буфером, тогда требования для процессора и ОС в основном касаются пропускной способности шины, задержки на реакцию уже не так важны.
То что касается Вашего вопроса ко мне, то тут все проще -никаких ядер у меня нет и ничего встраивать не нужно. Все обрабатывается обычным прерыванием, даже не стал заморачиваться с FIQ. Быстродействия хватает с лихвой. Я не понимаю почему нельзя сделать простой обработчик прерываний в ОС, который бы работал так как и задумано для прерывания- прерывал текущую задачу, отрабатывал и потом возвращался к прерванной задаче с минимальными издержками.
Я думаю Вам однозначно надо предусмотреть буфер на PLD или какомто малоногом контроллере, который будет заниматься лишь сбором данных с АЦП. Обмен между процами можно сделать по SDIO через DMA. Это у меня был как один из запасных вариантов.
Либо еще вариант -настроить проц на считывание АЦП через ДМА, используя 2 канала ДМА в режиме качелей. Но тут надо досконально знать железо и его особенности.

[TigerSHARC]

Если Вы про платы сбора данных типа NI то скорей всего там с АЦП работает ПЛИСина, которая является также буфером, тогда требования для процессора и ОС в основном касаются пропускной способности шины, задержки на реакцию уже не так важны.
То что касается Вашего вопроса ко мне, то тут все проще -никаких ядер у меня нет и ничего встраивать не нужно. Все обрабатывается обычным прерыванием, даже не стал заморачиваться с FIQ. Быстродействия хватает с лихвой. Я не понимаю почему нельзя сделать простой обработчик прерываний в ОС, который бы работал так как и задумано для прерывания- прерывал текущую задачу, отрабатывал и потом возвращался к прерванной задаче с минимальными издержками.
Я думаю Вам однозначно надо предусмотреть буфер на PLD или какомто малоногом контроллере, который будет заниматься лишь сбором данных с АЦП. Обмен между процами можно сделать по SDIO через DMA. Это у меня был как один из запасных вариантов.
Либо еще вариант -настроить проц на считывание АЦП через ДМА, используя 2 канала ДМА в режиме качелей. Но тут надо досконально знать железо и его особенности.

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

[Alexashka]

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

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

[Dubov]

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

Сообщение отредактировал Dubov - Aug 13 2012, 06:51