В принципе, ничего сложного. Могу порекомендовать переводную книгу по этой теме:
http://www.nclug.ru/wiki/index.php?page=knz_ldd2 (Linux Device Drivers 2nd edition)
Если надо - приаттачу простой код


Тогда все нужно описывать в kernel space и уповать, что проца хватит (в должном объеме) и на эту нитку тоже...
Судя по постановке задачи, жрущих процессорное время в 3 горла процессов нет, да и активируются они редко. Тогда:
1) если не очень принципиальны редкие задержки - разделить код на User и Kernel Space
2) если очень принципиально - все в kernel space.

Хочу также обратить внимание на "быструю" и "долгую" обработку прерываний в Linux.

Нет, не надо - user space realtime это уже давно прошедший этап в RTAI.

Я помню про RTAI - с Вашей подачи познакомился с этим чудом с полгода назад. Но он есть далеко не для всех процов! Для "народного" AT91RM9200 нету. Для PXA270 свободного не видел. Вот тут хотят 300 евро, причем за image - непонятно, как там насчет GPL и исходников...
http://www.vollmann.ch/en/colibri/shop.html#pro_support

Для Cirrus EP93xxx RTAI есть - но не тянет меня на эти процы по ряду причин.

Спасибо за желание помочь - это очень приятно. LDD2, LDD3 у меня есть, с "техническим" английким проблем не испытываю. Есть даже переведенная книжка Померанца по программированию kernel module. Но как-то стремно нырять в этот омут. Я хотел вариант lite написать в user space (при помощи всяких внешних аппаратных ухищрений доведя допустимую девиацию до 100 мс), а затем, по мере набора опыта, перетащить полностью или целиком в kernel space.

Я бы так и делал, и, может оказаться, не только в lite, но и в конечном варианте...
Я не скажу наверняка, как это будет в Linux (я это не проверял), но в QNX - разумно распорядившись приоритетами, можно гарантировать, что время начала операции будет плавать между 2-4 ticksize ... но всё, что касается диспетчеризации, вытеснения + деталей отработки службы времени (а там всё совсем не очевидно) - это всё регламентируется моделями POSIX, а одна и другая ОС в той или иной мере пытаются следовать POSIX. Мне кажется, что при ticksize=10мс. вы должны определённо вписаться в 100мс. интервал, если обезопаситься от всех неожиданностей + разумно распорядиться приоритетами + использовать только статические приоритеты при RR диспетчеризации (это те, кторые RT - об этом хорошо растолковывается в такой книжке "Ядро LINUX с комментариями" ... или как-то так - нет под рукой). Потом результат можно легко проверить на адекватность ... и у вас ещё остаётся возможность переопределить в ядре ticksize в сторону уменьшения.

P.S. в конечном счёте, если это серьёзная нужда и не лень повозиться, я готов специально найти, вырезать и выслать из книжки:
http://www.books.ru/shop/books/357604
- раздельчик, где специально ставилась задача синхронизации с наименьшей дисперсией интервала, с проверкой результата (это под QNX, но GCC - может быть "в лоб" перенесено в LINUX и проверено) ... это не совсем то, но очень близкие вещи - может на что-то натолкнуть.

Спасибо! Думаю, за 150р мне проще будт ее купить QNX мне не грозит, все будет под Linux, вначале на AT91RM9200, затем на PXA270.

Какой arm значения не имеет - клавное что архитектура поддерживается ядром, заточить ядро под новый камень (их в за год с десяток появляется) дело одно-двух дней. Такой древний камень как AT91RM9200 работает под linux'ом давно, RTAI его держит, по памяти, с 2005 года.
Если требования к задаче довольно строги - перенос в kernel space особого рояля не играет.




А кстати как QNX, атмеловские кристаллы держит ?

P.S. Вот линка на текущий порт linux на атмеловское чудо: http://maxim.org.za/AT91RM9200/2.6/

Решение есть. Появилось совсем недавно, в виде патча к последнему(или одному из последних) ядер 2.6. Собственно, страница с патчем: http://kerneltrap.org/node/6750 После патча и включения его в ядро, функции usleep и nanosleep начинают работать настолько точно, насколько позволяет ваша машина. (Насколько я понимаю, зависит это от чипсета) Мне-таки удалось получить 100 микросекундную выдержку - проверял осциллографом - на PIV с i975. А на старом компьютере (PIII c VIA Apollo Pro) минимальным временем задержки стала 1 миллисекунда вместо 20 мс, что тоже неплохо. Впрочем, судя по дате последнего сообщения, это уже неактуально.

P.S. А вот интересно, под windows кто-нибудь пробовал получать задержки в порядка сотни микросекунд..?

Это так называемые RT патчи от Молнара - к реалтайму имеют слабое отношение - так как писались для сведения задержек до приемлемого уровня для multimedia apps. Чипсет тут ни причем - существует понятие time source - это может быть RTC, RTDSC,, HPET или APIC тамеры, т.е. RTAI например чудесно работает на 486SX или других подобных процах, которых полно во встраиваемом оборудовании.

Ой-Ой-Ой. Отписал не в ту тему, прошу меня извинить. Да-да, это те самые патчи, которые делают возможным брать задержки от другого источника... Но, насколько я понимаю(могу сильно ошибаться) например, HPET таймер реализуется именно чипсетом - однако, это уже оффтопик.
По теме: если вопросы переключения задач зависят в данном случае только от ядра(причем, гарантировать нужный timeslice скорее всего, нельзя), то, быть может, само ядро стоит немного подправить?))
Насколько "немного" - уже другой вопрос. Однако сама возможность не исключается?

Если переключение/и т.д. будет зависеть от ядра - то мы будем иметь классический хреновый realtime, которого полным полно (RTLinux/QNX/Linux-rt). Посмотрите как устроен adeos - это тонкая прослойка между железом и всем остальным, включая ядра (т.е. несколько совершенно различных OS не проблема) - adeos виртуализирует прерывания/таймеры/scheduler - сами ядра OS запускаются как самая низкоприоритетная RT-задача, соответственно ядра править не надо.

Прошу прощение за поднятие старой темы. Но для меня это актуально.

Т.е. я правильно понимаю, что если под linux запущу это

То мне не гарантируется меандр с периодом 200 мс на неком порте X, разряде 1? RT патчи особо не интересуют, отношение почему-то скептическое...

Прерывания обрабатывать не нужно.

Правильно.
Во-первых, sleep(100) отправит процесс спать на 100 секунд, а не на 100 мс.
Во-вторых, никто не гарантирует, что когда время сна истечет, планировщик немедленно передаст управление этой задаче. Там может оказаться много других желающих получить процессорное время...

Ну вообще я написал псевдокод. Поэтому у меня sleep засыпает на миллисекунды)))

Ок, понятно. А если еще и приложения типа интенсивно работающего веб-сервера, то вообще труба...

Спасибо!

C RT патчами как раз никакой нагруженный веб-сервер и даже обработчик прерываний не заставит ждать задачу с большим приоритетом - это и подразумевает детерминизм, ну а скепсис в основном от непонимания происходящего

Сообщение отредактировал sasamy - Feb 26 2013, 11:32

Да, Вы правы! Мое понимание пока основывается на чтении соответствующих статей, а там неоднозначность, ровно как и на соответствующих форумах. Все-таки же не зря RTOS существуют...?)