RTLinux на ядре 2.6

Народ, а юзает ли кто сие? Наша контора уже 10 делает системы реального времени используя в контроллерах ДОС, операторские и диспетчерские места под оффтопом. Вот и думаю перекинуть это всё дело под Линь ... P.S. Нужон hard real-time, в строго определённый промежуток времени около 10 мс нужно опрашивать сеть модулей ввода на RS-232 и выдавать управляющие сигналы модулями вывода.

http://www.microsoft.com/Rus/Windows/Embedded/Default.mspx

;)

> Re: RTLinux на ядре 2.6 http://www.microsoft.com/Rus/Windows/Embedded/Default.mspx ;)

Ффф топку! Один наш самый опытный коллега уже полгода е...ся с MS Embedded, плюётся и дальше е...ся, результатов пока нет но говорит, что у людей работает, и ещё говорит о том что всё сделано через жопу, всё закрыто, короче - конфиги глазами не почитаешь и руками не поправишь. А начать осваивать линупс в этой области мешает груз накопленного опыта, жалко наверное человеку с ним расставаться

>Ффф топку! Один наш самый опытный коллега уже полгода е...ся с MS Embedded, плюётся и дальше е...ся, результатов пока нет но говорит, что у людей работает, и ещё говорит о том что всё сделано через жопу, всё закрыто, короче - конфиги глазами не почитаешь и руками не поправишь. А начать осваивать линупс в этой области мешает груз накопленного опыта, жалко наверное человеку с ним расставаться

В общем оно вообще не эмбедед. Работает оно конечно. Мы года три четыре использовали. От эмбеда только RO фильтр на FS. И тот гады доводили года два. С поддержкой гуев на 256М флэшку не втолкать. Фэйк на базе XPPro (часть DLL меняли на от нее потому что фиксы запаздывали на несколько месяцев)

дам-с маздай есть маздай

> http://www.microsoft.com/Rus/Windows/Embedded/Default.mspx

вы сами то пробовали это чудо? можно скачать пробную версию MS Windows Embedded. таки сперва пробуйте сами, а уж потом советуйте всякую каку..

// wbr

Хотел было скачать, но тянуть по модему сотни мегабайт как-то расхотелось.

> http://www.microsoft.com/Rus/Windows/Embedded/Default.mspx >вы сами то пробовали это чудо? можно скачать пробную версию MS Windows >Embedded. таки сперва пробуйте сами, а уж потом советуйте всякую каку..

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

> Вот с этим чюдом мой товарищ и иб..ётся, и ничего лестного он не сказал, у меня вот пробная версия в тумбочке валяется в красивой упаковочке, они её наверное её пихают со всеми промышленными платами.

мои соболезнования..

> Хотел попробовать, но посмотрел на коллегу и подумал, что может это на линупсе прикольней будет

indeed. но при одном условии: руки должны быть в достаточной степени параллельны :) если с руками все ok то без проблем.

// wbr

>Народ, а юзает ли кто сие? Наша контора уже 10 делает системы >реального времени используя в контроллерах ДОС, операторские и >диспетчерские места под оффтопом. Вот и думаю перекинуть это всё дело >под Линь ... P.S. Нужон hard real-time, в строго определённый >промежуток времени около 10 мс нужно опрашивать сеть модулей ввода на >RS-232 и выдавать управляющие сигналы модулями вывода.

Это довольно легко сделать на линукс (сам не делал, но смотрел исходники прошивок), даже один человек за месяц сделает то, что нужно.

А для 10 мс я думаю даже не нужно расширение RTLinux, хотя оно не повредит и проблем быть не должно.

Я юзал RTAI www.rtai.org . 8 Кгц работало как часики, опрашивал RS-232. Но гемор был, к железу это дело чувствительно очень.
Hard real time действительно был, сверху запускал все что угодно, X, java, updatedb. Толька нада было не забывать DMA вырубать для IDE

У меня почему-то с RTAI Х падали очень чясто :(

IMHO хорошая заметка на эту тему, пробегала в opennet.ru:

http://lwn.net/Articles/139047/

// wbr

А это имеет смысл использовать на десктопе? Улучшит ли это быстродействие/время отклика?

не имеет, не улучшит

> Толька нада было не забывать DMA вырубать для IDE

Вырубать?! расскажи почему

>> версию расширения реального времени RTLinux

"Реального" - следовало бы писать в кавычках. Ака псевдоквази.

Делал драйвер для MIL-STD 1553 под 2.4. Так вот 10 мс. без проблем получается без RTLinux, причем очень точно по сравнению с RTX+NT4.0. Правда проверял осциллоскопом на глаз :-). А вот если нужно меньшие интервалы, то я не думая в таймеры вставлял программную задержку+повторы посылок и получал периоды до 2,5 мс. Правда от машины к машине это время плывет. Но на одной и той-же по сравнению с Виндузом Линукс много точнее. На виндузе у меня этот же код расброс давал от 3,5 - 9 мс. P.S. RTLinux не работал.

Систем реального времени довольно много и не только на Linux ядре.
Вот, на моей конференции, есть относительно подробный обзор. Я думаю, удалось рассмотреть больше половины популярных систем:
http://www.teleology.ru/cgi-bin/ib1/ikonboard.cgi?act=ST;f=3;t=26

Из короткого комментария сложно понять всю вашу специфику. Однако, я бы обратил внимание на TinyOS http://www.tinyos.net . Пока не уточнял, насколько она соответствует Вашим требованиям, в частности RT, но, безусловнно, интересна, например, своими беспроводными возможностями и "заточенностью" ровно под системы датчиков.

Первому анонимусу: RTLinux 
используют еще как, 10мс совсем без проблем на
RTLinux, у него заявленное время реакции на аппаратное прерывание ->
порядка 10-20 мкс, если не доверяешь ихнему планировщику (а в ранних
релизах там у них были ошибки) - можно
повесить обработчик прерывания на UART (есть везде :)) запрограммировать
его на нужную скорость и получить отличный отклик :)

Это снова я, первый anonymous :)

Спасибо всем за полезную инфу! Буду расти в этом направлении. 10мс это интервал полного цикла взаимодействия с модулями ВВ. 1 модуль гарантированно отвечает в течении 1 мс. Т.е. на сеанс связи с одним модулем уходит не > 1 мс. Т.е. время полного цикла взаимодействия с модулями ВВ = количеству этих модулей. После получения от некоторых входных модулей данных, которые являются критическими (в основном от модулей аналоговых сигналов веса преобразованных в код (вообще главная задача точно отдозировать некоторый материал)) на выходные посылаются управляющие команды. Т.е. нужно гарантированно в миллисекундный интервал времени выполнять сеанс связи (запрос-получение данных) c очередным модулем. Вот.

>>Толька нада было не забывать DMA вырубать для IDE
>Вырубать?! расскажи почему

Фиг его знает - DMA на IDE сильно увеличивают латентность.
Может потому что нельзя прервать DMA трансфер, нада обязательно ждать
пока он закончится.

> вообще главная задача точно отдозировать некоторый материал

автомат по продаже кокаина под управлением Linux? :)))

hard real-time под дос? клиенты еще на вас в суд за п%"%ж не подали?

Вообще-то 10мс на RS-232 можно легко получить на любой MS опреационке без проблем. Ком порт он вообще работает как часы, и даже под виндой :-)

А заодно вопрос, никто не писал и под QNX и под Linux? А то я сам писал под Win и QNX, а под Linux не доводилось, ну вот и Win и QNX меня достали. Т.е. понятно что это операционки разного класса, т.е. QNX hard realtime, а Linux 2.6 в лучшем случае это soft realtime, но в наших задачах это не проблема, т.к. все hard realtime задачи решаются в выделенном железе, а комп всю систему объединяет.

Вот собственно вопрос, насколько приятно писать под Linux по сравнению с QNX? При условии что надо шарится по COM-портам, и общаться с кастомными PCI устройствами?

И ещё вопрос: где можно нарыть документ типа Linux API reference?

И обязательно ли надо писать модуль ядра для доступа к PCI устройству?

Клалафуда и писал.

Писал и нахваливал.

P.S. Ян, класcно я тебя сдал, правда? На чем, кстати, вы сейчас свои системы лепите, по-прежнему на netbsd?

Разница между Linux и коммерческими ОС в наличии исходников (и не только, конечно), что сильно облегчает работу с жедезом. При наличии "прямых рук" всегда можно попытаться исправить даже ядро для собственных нужд. Модуль ядра (драйвер) под linux проще написать, как мне кажется, чем Resource Manager под QNX. Да и API под linux побогаче будет.

Документация (полная) по API входит в состав любого дистрибутива.

Для доступа к PCI модуль ядра писать обязательно.

Писать драйверы для PCI устройств под Linux весьма удобно и приятно. На мой взгляд несколько более удобнее чем под Windows используя HAL -- NT Drivers (правда сейчас используют в основном WDM). В Linux следует использовать обёртку pci_driver.

Use Ecos, господа.
use Ecos

> где можно нарыть документ типа Linux API reference?

http://www.opennet.ru/docs/137.shtml

> Клалафуда и писал.

но преимущественно под QNX4 && как-то не приходилось под Linux.

> Писал и нахваливал.

ну скажем так - на QNX* есть свои плюсы и минусы :)

> P.S. Ян, класcно я тебя сдал, правда? На чем, кстати, вы сейчас свои системы лепите, по-прежнему на netbsd?

Win2k && *BSD.

// wbr

а расскажите, что хорошего (и плохого, конечно) в этом eCos по сравнению с.. с тем, что использовали раньше.