В обычном Linux ты этого не сделаешь (RT-процессы могут засыпать очень надолго временами). Копай в сторону RTLinux.

А может тогда уж сразу QNX?

RT-процессы долго спать не должны если им есть что делать и их RT-приоритет выше, чем у всех остальных. Но вот за разделяемые ресурсы они "борются" как и все остальные, поэтому если процесс с маленьким приоритетом захватил что-то (в простейшем случае через mutex), то пока он не отпустит, высокоприоритетный будет ждать как и все остальные.

А я думал, что в модулях всё организую и запущу -Ю и всё будет ок??? если нет, то как шо игде QNX или RTLinux?? где, куда??

А может, я выделю тачку с допустимым минимумом, организую всё шо надо на дискетке (если это возможно) и тока свою прогу юзать буду???

Если что-то типа updatedb запустится и кучу ресурсов захватит?

>RT-процессы долго спать не должны если им есть что делать Вообще говоря, не должны, но оценку времени отклика при обработке ошибки страницы дать сложно. Ну пусть даже сделали mlockall(), все равно временами возникают прерывания.

Т.е. обычный Linux - это не RTOS, иногда такие называют Soft-RT, IIRC. :)

Мне нужна действительно RT-система! Так Вывод какой? -> как я понял QNX или RTLinux??? так к чему лучше обратиться с точки зрения эффективности и с точки зрения наявности документации?? (наверное RTLinux ближе?).

www.rtai.org

в книге Linux Device Drivers один из автроров использовал Linux для РТ Радарной системы.?????

Так как немного знаком с темой "радарных систем", то могу сказать, что там крайне редко возникает необходимость использовать т.н. Hard RealTime.

Если кто-нибудь ипользовал RTAI, напишите, пожалуйста, свои впечатления.

А кто нибуть узнавал сколька QNX стоит?
Если цена там приемливая, то ниче лучше не найти, она изначально делалась как RT система.

maxgor.

Мне кажется, что для системы реального времени, многозадачная операционка не подойдёт, нужно что нить типа ms-dos, можно его самого :-)). Но это ИМХО.

Смотря насколько реально твое реальное время. Если вопрос о сотнях миллисекунд, то ненагруженный Р-100 под линуксом с отключенным свопом вполне тебя устроит. Если речь идет о микросекундах, то персоналка тебе просто не подходит, независимо от камня и ОС (из-за DRAM).

цена - окол. 7000 инопланетных буказоидоа :)))

RTLinux тоже не бесплатен кажется. а в последних ядрах 2.6 кое-что в сторону RT копали. надо подробнее поглядеть. может кто-ть поконкретнее скажет?

 Итак - про QNX читайте здесь:
http://www.swd.ru/qnx/
http://www.qnx.org.ru/
 Про RTLinux:
http://www.fsmlabs.com/products/products.html
есть там на условиях GPL
 можно попробовать KURT /в виде модуля к ядру/
http://www.ittc.ku.edu/kurt/
Да -  для начла можно попробовать 
http://sourceforge.net/projects/wolk/
ядро. можно погираться с параметрами - как то гарантированное время отклика.... 
 Удач.
 $echo from Siberia.

Может подойдет типа BusyBox? Там кажись идея такая - грузится ядро и процесс, который исполняется ( если речь идет об исполнении одного процесса)

Для работы в реальном времени существует целый набор ОСЖ
- VxWorks WindRiver
- QNX (Neutrino)
- TymeSys Montavista
- T-Engine TRON 
- RTLinux как rt process с idle Linux
- uCLinux как embedded
- eCos как embedded
и пр. см ссылку: http://beru.univ-brest.fr/~singhoff/DOC/OS/RTOS/rtos2.html
или 
comp.realtime archives

Теперь о назначении...
Все вышеперечисленные РТОСы имеют свои применения: одни для встраивания в СУ, другие для работы в корпоративных серверах и т.д. Иными словами необходимо точно сформулировать задачу и область применения.
Типы реалтайма:
- soft RT
- hard RT
отличаются фиксированныем (гарантированным) временем выполнения операции (отклика), примерная временная граница ~40 мкс (ниже hard, выше soft)
Про остальное читай http://www.llp.fu-berlin.de/pool/software/rtapps/

исключительно имхо - системы hard rt на персоналках и иже с ними (IBM совместимыми, короче) - чистая туфта. работал сначала с фрей, потом с QNX, сейчас пишу на линухе. при правильной настройке системы линух пашет не хуже QNX одназначно, по своим возможностям embedded линух от QNX ненамного отстал (если вообще отстал), а если вспомнить про глюки QNX - бррр, и вспомнить-то... все разговоры про гарантированное время отклика на ибмках - лажа. если кривой (или просто даже обычный) девайс захватывает шину данных и не отдает ее - то будь тут хоть линух, хоть дважды нейтрино - а пока шина занята - система будет стесняться в сторонке. опять же опыту - очень мало есть систем, в которых время отклика имеет настолько уж критическое значение. обычно 1-2 млс вполне примлеио. хотя у меня на 400 пне время входа в обработчик прерывания ни разу не привысило 35 мкс. если это мало - вам нужна не персоналка.

а что за задачка? можно поподробнее?

To: anonymous (*) (2003-09-16 13:22:11.251639) слушай, скажи пожалуйста как с тобой можна связаться!!! уж очень надо, плизззззз!!! ICQ, e-mail

Задача такая (в общем). <br> есть радар, надо, принимать с него данные (уже работает) и в соответствии с данными производить некоторые вычисления и выдавать воздействие.

Значит раньше работало всё, а как только нагрузка больше - не справляется Linux мой!!! - вернее я с ним не справляюсь.

To: anonymous (*) (2003-09-16 13:22:11.251639) слушай, скажи пожалуйста как с тобой можна связаться!!! уж очень надо, плизззззз!!! ICQ, e-mail

попробуй vinill@land.ru

а радар как к компу поцеплен? через какой интерфейс?

>Значит раньше работало всё, а как только нагрузка больше - не справляется Linux мой!!! - вернее я с ним не справляюсь.
Надо полагать, mlockall, sched_setscheduler и иже с ними ты уже пробовал?

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!

к anonymous (*) (2003-09-16 13:22:11.251639) если ты так четко гворишь о своем опыте, то вообще почему упомянул ИСПОЛЬЗОВАНИЕ ПЕРСОНАЛОК ДЛЯ СУ ИЛИ ПРОСТО ДЛЯ РАБОТЫ В РЕАЛЬНОМ ВРЕМЕНИ? А? Это просто кощунство!!! Все СУ строятся на special purpose hardware (в частности встраиваемые системы) и обкатываются (подчеркиваю обкатываются и только) на персоналках и то только в том случае, когда стеснены в возможностях разработчики. Я 10 лет с РТОСами для СУ (в том числе для сложных технологических систем - роботы, АСУТП,и пр) работаю и если кто-то заикается по поводу использования ПК в таких системах - "растрел на месте". А по поводу Linux и его отставаний: я скажу так монолитное ядро ЛЮБОЙ системы не способно выдерживать требований натурального RT (hard) по определению и точка, даже разговаривать не буду. А если не сумел совладать с QNX, то это твои проблемы. К твоему сведению несколько Телекоммуникационных компаний, а также Ядерная энергетика нескольких государств исполльзует эту (правда чуть видоизмененную) систему. А в основном все системы ЗАКАЗНЫЕ! Кстати VxWorks также весьма популярна. Так что учись и поддавайся обучению. Итог разговора: человеку надо определить что за процесс он будет контроллировать, а потом сидеть и думать использовать готовое решение или же использовать исходники чего-то открытого и написать свое! Удачи и успехов.

а если не нужен такой критичный RT а гарантированное время отклика получить хочется? тоже свою железяку городить? дороговато получается...
висит какая-ть сопля на RS232 и ее крутить постоянно надо.... не атомная станция же....

офтопик но реал таим на х86 туфта

а на чем не туфта?

Позволю себе повториться:
человеку надо определить что за процесс он будет контроллировать, а потом сидеть и думать использовать готовое решение или же использовать исходники чего-то открытого и написать свое!
Иными словами нужна четкая формулировка задачи!
В противном случае - выполнение будет осложнено неясностью цели и в итоге просто приведет в тупик.
Если же мы тут говорим просто о каком-то ну очень простом считывании по порту данных, их обработке за определенный промежуток времени и последующей реакции, то в таком случае мы говорим о некой системе мониторинга, где совершенно не обязательно использовать такие критичные РТОСы как VxWorks, QNX или (A)RTLinux и тому подобное.
Еще раз говорю
- надо четко сформулировать задачу
- затем построить схематическую модель (пускай даже простую) динамики управляемого процесса (медленная, быстрая, смешанная)
- потом проссчитать (или просто прикинуть хотя бы - при сильном упрощении) где какая реакция необходима
- и только после этого (опускаю несколько пунктов) можно прикидывать зная характеристики железа (управляющего/управляемого) и ПО (включая ОС) определять дальнейшие шаги
Такие вот дела.

эк тебя торкнуло :-). а я тут что, написал, что персоналка рулез форева? просто несложно предположить, что если человек ЗАДАЕТ ТУТ вопрос относительно использования систем реального времени, то он явно не на космической станции системщиком работает.

относительно опыта по QNX - есть QNX 4.25 - он работает, а есть QNX 6.x - ему еще вылизаться надо и даже спорить об этом не собираюсь - все уже перетерто по 100 раз. а вообще в таких вещах используются не только заказные программные среды, но и заказное железо, в котором и ОС зачастую вообще не нужна.

а человеку, задавшему вопрос, повторюсь - линух тебя устроит, и не мечись во все стороны. интересен QNX (просто больше ты ничего некоммерчески бесплатного из профессиональных РТ ОС не найдешь) - www.qnx.com, www.qnx.org.ru - вперед, для общего развития вполне полезно :-)

почитай, интереса ради http://qnx.org.ru/forum/viewtopic.php?topic=1920&forum=4&35

Помогите вдуть тупому ... я очень серьёзно! мне надо для начала: - на персоналке отработать, чтобы посмотреть, что оно (железо) работает, а так же для предварительной демонстрации. - надо принимать сигнал с радара (антенны), о том где нах-ся наблюдаемый объект - для отработки пока 4 вида сигналов - в соответствии с видом сигнала выдавать воздецствие - через LPT порт с частотой 400Гц (лучше выше) - широтно модулированный сигнал.

оно работает коряво - мне кажется это из-за того, что это не RTOS.

?????????????????????

как быть??? подскажите, направте меня, чтобы я начал обогащать свой скудный разум.

400Гц (если это частота оцифровки) - 1 слово в 2.5 млс :-) - это даже на винде без проблем должно прокатывать, какие уж тут РТОС ты б сказал - что значит коряво? читается через раз, лажа с порта прет, отрабатывать не успевает?... тут судя по всему, не систему, а твою программу смотреть надо

Надо сигнал с частотной модуляцией частота его с 400-100Гц (лучше 1000) на выходе с LPT

Хорошо как сгенерировать такой сигнал?? 1 на выходе, задержка, 0 на выходе, задержка, 1, ..... так, так вот очень коряво получается ... надо чтобы это время генерации, никем не испортилось, т.е. сигнал не искозился бы

И как лучше устанавливать на выходе LPT, необходимое состояние 1,0?

Дальше всё гораздо усложнится и мне кажется без RTos не обойтись (ну это только потом)

если тебе надо писать в порт, а не читать, тогда смотри сюда: /usr/src/linux/Documentation/rtc.txt есть описание, есть пример - настраивай его на твою частоту и валяй

если тебе надо писать в порт, а не читать, тогда смотри сюда: /usr/src/linux/Documentation/rtc.txt есть описание, есть пример - настраивай его на твою частоту и валяй да, ядро надо 2.4.х

при желании можно даже драйвер rtc подправить под свои нужды, тогда уж точно частота выдачи отсчетов будет вне конкуренции - уровень ядра, всетки :-)

EPP LPT

Прощу прощения что не в тему, но может есть спецы, которые работали в EPP LPT портами. Доку то я нашел, но все равно нифига не работает.
Если есть cпецы, хотелось бы обсудить кое что.

Не совсем понятен вопрос - ты откуда сигнал получаешь, с антенны??? Это не реально. Может просле уж детектора или порогового устройства? В каком виде он приходит? Если уже готовый детектированный сигнал, то темп приема (если радар типа ипульсный кругового обзора) вполне приемлимый. Если это так, то думаю главное тебе считать сигнал, обработать выдать воздействие. Вот что должна делать система. А формировать ШИМ на LPT программно не надо - лучше присабачить на LPT железяку (на коленке собрать можно), занимающуюся формированием ШИМ и писать в LPT твое "воздействие" (код какойнить), который бы говорил этой железяке как формировать сигнал. Под Досой такую фигню за мило дело слепить можно или ж посмотри busybox - там грузится ядро и прога в монопольном режиме ( у нас так под линухом приблуда спутниковой тарелькой управляет - отслеживает уровень приема и по нему корректирует тарельку)

Не могу претендовать на "спеца в EPP LPT портах", но работал с этой штукой, может смогу на некоторые вопросы ответить.

PETER дело говорит.все зависит от необходимой точности. в прнципе rtc довольно точная точная штука.

>>Не могу претендовать на "спеца в EPP LPT портах", но работал с этой >>штукой, может смогу на некоторые вопросы ответи

Есть у нас девайс, он подключен к LPT порту и работает в EPP режиме.
Так вот, проблем с этим девайсом нет, пишеш/читаеш DATA port и все в порядке. Проблема у меня с двумя компами, соединеными LPT кабелем.
На одном пишу, на втором читаю. На обеих концах выставляется TimeOut.
Идеально бы помог пример проги, которая пересылает и принимает через
EPP link какой нибуть буфер. Может нада порты инициализировать как то,
я довольствуюсь настройкой в биосе.

По поводу общения между компьютерами через LPT порт хорошо написано в книге М.Ю, Гука "Аппаратные средства PC". Вообще-то такую задачу через EPP режим решать трудно. Тут лучше использовать ECP режим, потому что в нем уже реализована буферизация. Кроме того, в классическом EPP режиме PC всегда ведущий в обмене (и при чтении и при записи), соединить два PC в таком варианте опять-таки сложно.

>>Кроме того, в классическом EPP режиме PC всегда ведущий в обмене (и >>при чтении и при записи), соединить два PC в таком варианте опять-таки >>сложно.

Как это ведущий и ведомый? А как же там все эти цикли чтения и записи,
рукопожатия и все такое?

Ведущий это тот, кто инициирует циклы чтения и записи, т.е. в "рукопожатии он первый протягивает руку, а не ждет пока ему протянут, ждать этого он не умеет". Если на обеих сторонах находятся такие товарищи, то они не могут в принципе начать цикл обмена.