Обработка прерываний с АЦП

[drifterlom]

День добрый,
у меня в голове путается работа в QNX и Linux
По всем запросам в Гугле по поводу обработки прерываний в Linux пишут про работу на уровне ядра. Это здорово, к этому придется прийти ибо в RTLinux надо бут писать программу как модуль. Но для начала хотел поэкспериментировать в user space. И ничего не могу найти. Есть у кого пара ссылок и возможно это вообще?
Необходимо во время выполнения основного потока все время ловить сигнал с АЦП о завершении преобразования запускать обработчик сохраняя полученные данные в массив.
Или сразу писать модуль и не думать о плохом? =)

[mrcashe]

Дело в том, что в отличие от QNX, в Linux аппаратные прерывания никак не могут быть выведены из ядра в User Space. Нет такого замечательного свойства. В том числе за это и платят деньги, покупая QNX. Поэтому, если АЦП находится на шине PCI, то иного варианта, как писать модуль, на самом деле нет.

[ssh]

Это не совсем так.

"Настоящие" прерывания, действительно, можно обрабатывать только на уровне ядра. Но действительно ли без них совсем уж никак нельзя обойтись? Если в задаче умеренные требования к скорости отклика (скажем, допустима задержка съема данных после измерения в пределах долей миллисекунды), то можно спокойно работать из user-space'а в режиме опроса готовности устройства, что намного удобнее и переносимее (между ядрами, например). Программу типа "неинтерактивный обработчик снимает показания - интерактивный клиент пишет их на диск + показывает на экран + управляет измерениями" в этом случае можно строить по схеме:

Код: Выделить всё

(общая инициализация);

pid = fork()

if( pid == 0 )
 {
   начало потомка-"обработчика":
  "демонизируемся" ( отключаемся от
   папиных stdin/stderr/stdout);

   while( 1 )
    {
      петля потомка-"обработчика":
      опрашивает готовность устройства;
      собирает информацию;
      передает ее основному процессу - папе;
      спит 0.001-0.01-0.1-1-10-100 миллисекунд.
    }
 }
else
 {
   while( 1 )
    {
      петля папы:
      ждем данные от потомка,
          их сохраняем, обрабатываем,
          отображаем, общаемся с человеком
          и т.д.
    }

  прибиваем потомка перед  выходом;
  деинициализируем устройство;
 }

Общение между обоими процессами после fork'а можно организовать, например, через разделяемую память и семафоры.

Того же эффекта, вероятно, можно добиться, с помощью thread'ов (или как они там называются) в рамках одного и того же процесса, не прибегая к порождению самостоятельного потомка. Кстати, по этой схеме хорошо работать с usb-устройствами, у которых с аппаратными прерываниями вообще туго.

[drifterlom]

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

З.Ы. QNX хорош и им как бы и пользовались, но оказалось что наши сурьездные ведомства работают тока в Линухе и на QNX уже заказы не сделаешь. Вот поэтому я тут и флудю

[mrcashe]

Это не совсем так.

"Настоящие" прерывания, действительно, можно обрабатывать только на уровне ядра. Но действительно ли без них совсем уж никак нельзя обойтись? Если в задаче умеренные требования к скорости отклика (скажем, допустима задержка съема данных после измерения в пределах долей миллисекунды), то можно спокойно работать из user-space'а в режиме опроса готовности устройства, что намного удобнее и переносимее (между ядрами, например). Программу типа "неинтерактивный обработчик снимает показания - интерактивный клиент пишет их на диск + показывает на экран + управляет измерениями" в этом случае можно строить по схеме:

Ну, это у же не работа по прерыванию, а простой поллинг - наиболее простой способ сбора информации. Для начала сойдёт.
Тут ещё проблема: как без модуля ядра получить доступ к портам ввода-вывода. ЕМНИП, в ядре есть функции доступа к отдельным портам, выведенные в userspace, но доступ к ним имеет только root. Как, впрочем, и в QNX: только root может обрабатывать прерывания.

[drifterlom]

Доступ к портам I/O я уж получил в прошлой теме благодаря ssh ))), из user space
Все работает, с ЦАП на осцилограф разного рода синусойды шлю, с АЦП получаю сигнал. Все путем.

[Wagan]

Доступ к портам I/O я уж получил в прошлой теме благодаря ssh ))), из user space
Все работает, с ЦАП на осцилограф разного рода синусойды шлю, с АЦП получаю сигнал. Все путем

А если параллельно запустить какой-нибудь нудный процесс, тайминг не плывет разве? Или в Вашей задаче равномерность чтения из АЦП не важна?