Реальное время в Linux user space, Сколько оно нереально? Опции

[Evgeny_CD]

Вот есть процесс в user space Linux. Он в цикле опрашивает порт IO (через медленную функцию доступа к IO из user space). Если там что-то случилось/не случилось, он делает некую работу.

Есть другие процессы (и сама система). Они прерывают мой процесс. Процессов таких минимум, они не сильно активны. По сети активности нет. Винчестера нет, только NOR FLASH и SD.

Если вести речь о PXA270, на 312 Мгц, то о какой "временной девиации" может идти речь? Т.е. на какое максимальное время система может прервать мой процесс? Можно ли говорить о том, что "дырка" будет не более 10 мс?

Аспекты kernel module, RTAI чур пока не трогать. Реь идет о тупом программизме в user space.

[bigirbis]

Вообще, по моему скромному мнению, следует внести опрос портов IO в kernel space с последующей записью в файл устройства. А далее из user space жрать из этого файла устройство все, что надо.
Если есть беспокойство по поводу того, что ядро не даст нужного приоритета для kernel module, есть один вариант (я как-то его реализовывал, но придумал не сам). Если надо, потом попробую описать.

[Evgeny_CD]

Вообще, по моему скромному мнению, следует внести опрос портов IO в kernel space с последующей записью в файл устройства. А далее из user space жрать из этого файла устройство все, что надо.

Это правильно, но есть одна загвоздка - надо уметь писать программы для kernel space.

[Harbour]

Вообще, по моему скромному мнению, следует внести опрос портов IO в kernel space с последующей записью в файл устройства. А далее из user space жрать из этого файла устройство все, что надо.

Это правильно, но есть одна загвоздка - надо уметь писать программы для kernel space.

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

[Evgeny_CD]

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

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

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

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

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

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

Я хотел вариант lite написать в user space (при помощи всяких внешних аппаратных ухищрений доведя допустимую девиацию до 100 мс), а затем, по мере набора опыта, перетащить полностью или целиком в kernel space.

[Harbour]

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

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

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

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

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

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

Я хотел вариант lite написать в user space (при помощи всяких внешних аппаратных ухищрений доведя допустимую девиацию до 100 мс), а затем, по мере набора опыта, перетащить полностью или целиком в kernel space.

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

Я хотел вариант 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 и проверено) ... это не совсем то, но очень близкие вещи - может на что-то натолкнуть.

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

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