RTOS

[kosmax]

Очень хотелось бы развернуть дискуссию по особенностям различных ОСРВ. Например, услышать отзывы о применении их в реальных проектах (чем обусловлена необходимость применения ОСРВ, почему именно эту ОС выбрали, с какими багами столкнулись, какие плюсы). Я имею достаточно большой опыт разработки под VxWorks и STLite/OS20 , однако, для меня остаётся секретом, почему первая относится к классу ОС "жёсткого реального времени", а вторая к обычным ОСРВ. Хотелось бы услышать мнения по этому вопросу

[Гром]

Перечитай две статьи 1. моя второая не моя на сайте.
Обе посвящены RTOS.

Дело в том, что там как раз 1 статья - мнение - вторая обзор перевод.
А то получится повторение.

Я оттебя впервые слышу о жесткой и не жесткой - раздление ОСРВ таким образом не видел....

[kosmax]

Занимательный обзор, но достаточно общий. Гром описал real-time программирование с точки зрения реализации под ОС, которые с большой натяжкой можно назвать RTOS  Однако в реальной embedded системе, чаще всего приходится действовать в условиях серьёзных ограничений на ресурсы, которые должны оптимально разделяться несколькими процессами или потоками, поэтому появление дополнительных процессов или потоков бывает крайне нежелательно (особенно если "железо" не поддерживает их должным образом). В случае полноценной RTOS, на прерывание от COMа можно повесить собственный обрабочик, который семафорит приложению, что пришли данные. При высокой интенсивности передачи можно использовать кольцовой буфер, размер которого зависит от интенсивности. Обработчик в него пишет, а приложение из него читает. В этом случае отпадает необходимость дополнительных потоков    Кстати, а WinCE позволяет работать с прерываниями?

[Гром]

Кстати, а WinCE позволяет работать с прерываниями?

А как же - обязательно

В случае полноценной RTOS, на прерывание от COMа можно повесить собственный обрабочик, который семафорит приложению, что пришли данные. При высокой интенсивности передачи можно использовать кольцовой буфер, размер которого зависит от интенсивности. Обработчик в него пишет, а приложение из него читает. В этом случае отпадает необходимость дополнительных потоков

Я даже в DOS могу сделать это...  А в апликации иметь петлю , которая периодически опрашивает функцию состояния COM порта.

В Виновс тем более.

В общем мне не понятен наверное вопрос дисскуссии, какова цель, что мы пытаемся выяснить?

[kosmax]

Я даже в DOS могу сделать это... А в апликации иметь петлю , которая периодически опрашивает функцию состояния COM порта.

Согласен, только тогда не понятно зачем нужны навороты для real-time?  

В общем мне не понятен наверное вопрос дисскуссии, какова цель, что мы пытаемся выяснить?

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

[NeilPryde]

У меня опыт работы не большой - всего одна операционка, и та оказалась какашкой. А вообще мне эта тема очень интересна! И не только мне. Вот кто-то даже обзорчик небольшой на эту тему написал: http://www.uspensky.com/os/RTOS.doc
HRT – не HRT я думаю определяется по максимальному времени реакции. Где оно большое – то не HRT. Но конкретного общепризнанного руководства по тому что называть системой HRT а что нет, мне встречать не приходилось, но очень хочется.
Иногда под этим скрываются всяческие маркетинговые уловки.

[kosmax]

Вообще, в мануале по VxWorks, HRT определяется гарантированным временем на обработку события в целом. Т.е. типа HRTОS гарантирует, что событие будет обработано в течении определённого кванта времени от его возникновения. Однако опыт    и здравый смысл    подсказывают, что глючное приложение может свести на нет любые гарантии любой операционки будь-то HRT или SRT. Кстати, время реакции на прерывание и время переключения контекста у VxWorks больше чем у некоторых SRTOS (см. обзор http://www.uspensky.com/os/RTOS.doc) . А вообще действительно похоже на маркетинг.

[Гром]

Ссылка у меня не работает...
Кстати обзор твой лежит на этом сайте.

https://club.shelek.ru/viewart.php?id=46

Чего сам забыл

По теме, по моему слишком акцентировано слишком в системах RTOS скидка на RT а не на ОS .
Имею ввиду, что по моему вся бодяга раздута Реал тайм ....

Я умудрялся в свое время, рабротая с РОМ ДОС писать псевдо мультитрединг, и обработку входящих сетевых коннектов (до 10 одновременно) эмулируя временное разделение ресурсов не трогая ни защищенный ни расширенный режимы процессора.

А сам чинил программки написанные под PocketPC и WinCE которые вешали девайс одним потоком!!!

То ли я не понимаю столь мощного отличия, то ли не такое уж сильное отличие...

Тут уже спорили что делать с RTOS кого к ним относить - основным считалось критическое время реакции.

[NeilPryde]

Хэх! А это не мой обзор… Это еще один, другой! Странно... Все работало, но вчера. Вот так понадеешься что ссылка еще долго просуществует, и потом обломишся. Что делать-то? Не копировать же весь инет к себе на диск??

[Гром]

Копируй к нам на сайт - и почему твоего обзора нет до сих пор у нас???

Надеюсь он у тебя остался???

[NeilPryde]

Как нет обзора? А тот, что ты указал в ссылке не тот что-ли?? Если да, так он вроде уже на вашем сайте лежит. Или я чего-то не допонимаю?
Ссылка, кстати, работает. Тычь по моей, а не по kosmax’ской – у него скобка вставляется.

Насчет отличий. Они есть. В RT – гарантировано, что событие будет обработано в течении определённого кванта времени от его возникновения. Но вот утверждать что это и есть Hard RT – скорее всего не верно. И если в обзоре указаны реальные цифры а не с потолка, то он это только подтверждает.

[Гром]

Хэх! А это не мой обзор… Это еще один, другой!

Т.е. есть два обзора - ты указал на свой я на твой на этом сайте, ты сказал, что это не тот, а где тот ...
Что-то не пойму.

[Гром]

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

[NeilPryde]

Есть 2 обзора по RTOS – один я перевел. И еще один – «другой обзор» написал другой дядька какой-то. А я его в сети нашел (не дядьку, а обзор) и ссылочку указал вот она: http://www.uspensky.com/os/RTOS.doc . Надеюсь ситуация теперь прояснилась.
Можно было - бы его и к нам на сайт положить, но для этого надо разрешения у того дядьки-автора спросить.

[Гром]

Понял - я решил, что это твой обзор тоже...

А ссылка все равно не работает.

[RXL]

Гром, если ты о http://www.uspensky.com/os/RTOS.doc , то это работает. Наверно от тебя доступ не работает. Можно переслать (~400k).

[Гром]

Странно у меня домен сам не виден...
Ок - присылай на почту.
Надо посмотреть.

И куда подевался kosmax?

[RXL]

Странно у меня домен сам не виден...
Ок - присылай на почту.
Надо посмотреть.

А какой имейл-то?

[kosmax]

А вот и я!    Интересная ситуация: перерыл кучу статей и обзоров по ОСРВ, однако, везде разные цифры времён переключения контекста и разные цифры времён реакции на прерывание для одних и тех же ОС, причём разброс достаточно большой. А в фирменной документации на ОСы я вообще этих цифирей не нашёл  :? Откуда их авторы берут?
Кстати,  вот на мой взгляд более-менее вразумительная статейка - http://www.pcweek.ru/year1999/N8/CP1251/Industrial&built-in/chapt1.htm

[Гром]

Боюсь все это фикция - так как на разном железе цифры будут разными.

ИМХО конечно - но время реакции не стоит мерять только абсолютными цифрами, важна конкретная задача и ее удовлетворение.

Скажем при критичности времени реакции на железе А в размере < Х секунд придется тестировать ОС - и смотреть какие условиям удовлетворят наилушим образом...

[Olej]

Интересная ситуация: перерыл кучу статей и обзоров по ОСРВ, однако, везде разные цифры времён переключения контекста и разные цифры времён реакции на прерывание для одних и тех же ОС, причём разброс достаточно большой.

Абсолютные значения времён - практически не имеют значения для характеристики realtime. Более того - HRTOS будут, как правило, иметь бОльшие времена на выполнение тех же самых операций, чем OS не realtime: т.е. одно и то-же действие будет быстрее в Win98 чем QNX... (за счёт более корректных переключений контекстов!). Посмотрите здесь, кое-что:
http://qnx.org.ru/forum/viewtopic.php?topic=1690&forum=7&71

А в фирменной документации на ОСы я вообще этих цифирей не нашёл  :? Откуда их авторы берут?

Пожалуй, наиболее квалифицированные отчёты тестирования с фактическим материалом и сравнениями - можете найти здесь:

Dedicated Systems Experts sa
Engineering Audit & Expert Services
Bergensesteenweg 421, bus 12
B-1600 St-Pieters-Leeuw, Belgium
http://www.dedicated-systems.com

[Кот]

А всетаки интересно было бы узнать кто какие реальные задачи решал под ОСРВ и с какими специфическими трудностями столкнулся и как их решал

[Гром]

Я работал с этим - могу рассказать
Что именно интересует - проблемы организации, алгоритмирования, какие решения принимались или как???

[Кот]

Вот собираюсь засесть за MicroPC там ROM DOS стоит. Вот мне интересно хватит мне ентой Досы или есть смысл перейти на QNX. Задача впринципе линейная опросить входы и по запросу от мастера выкинуть данные.Ну пару сигналов завести на прерывание.Единственное жесткое требование скорость опроса 10 мс.

[NeilPryde]

Сколько у вас опрашиваемых датчиков? Какой способ связи с мастером использовать собираетесь? И почему вы решили использовать OC в своей разработке? Может быть можно вообще без нее обойтись?

[Кот]

Датчиков за сотню на объекте.Связь либо Ethernet либо РРЛ. Критичным является время опроса и реакции на изменение состояния сигналов на самом объекте порядка 10 - 50 мс. Потому и решено было использовать MicroPC. Ресурсов у нее много опятьже архитектура хорошо знакома. Вот только надо гарантировать временные параметры.
Реализация проекта только в перспективе на след. год вот и сижу думаю хватит ДОСа и QNX поставить или использовать RTKernel поверх доса (у него вроде многопоточность есть и гарантии по времени реакции).

Кстати мож кто юзал RTKernel.

[NeilPryde]

Возможно, я тебя не так понял. Насколько мне известно, MicroPC – это стандарт такой, типа ISA. Что за проц./контроллер на ней стоит? Нельзя  ли поподробнее?
Насчет систем… Ни с той ни с другой не работал. По QNX здесь Olej специалист. На первый взгляд требования у тебя вполне выполнимые. Все RTOSины должны гарантировать определенное время реакции. Я бы на твоем месте на QNX остановился.

[Кот]

На сколько я вкурсе MicroPC это стандарт который разработал Octagon и он практически единственный кто его поддерживает. В России Fastwell выпускает платы этого формата. Формат ISA. А архитектура x86. Процы стоят 386, 486, Пни и АМдшники. Факт что архитектура х86 и софт мона писать соответственно как под обычный писюк.
QNX только в глаза видел потому переход на него малость затруднен. А библиотека RTKernel как раз расчитана чтобы вставать по верх ДОС.

[CaptHowdy]

Всем привет!
Читал - читал... 8)
Хочется сказать, что наилучшей ОСРВ по моему мнению является ОС QNX Momentics 6.2.1. Вы спросите почему? Я отвечу: потому как это единственная ОС, которую очень широко применяют в Military практике - самолеты, ракеты, космические корабли... Многие из них работают на базе QNX. Еще можно добавить, что это очень гибкая система. И очень маленькая по объему. Напрмер, я написал ПО для системы управления асфальто-смесительными агрегатами производства КРЕДМАШ (http://www.kredmash.com). Все это поставил на DiskOnModule и заняло это все у меня 21Мб. Все - это имеется ввиду следующее: собственно ОС (Embeded QNX), GUI-интерфейс (Photon), основная программа, программы работы с базами данных, сеть и интернет.

В некоммерческий пакет входят средства разработки GUI-приложений (PhAB)

Так что всем советую попробовать. Скачать образы некоммерческих версий можно здесь:
http://www.openqnx.сom/Downloads+index-req-viewdownload-cid-1.html
предварительно надо зарегистрироваться здесь:
http://www.openqnx.com/user.php?op=check_age&module=NS-NewUser
иначе вы не сможете ничего увидеть и закачать по ссылке выше.
Зайдя по ссылке, надобно качать образы:

QNX 6.1 ISO  
Description: This is the full version of the ISO image of the QNX RTP version 6.1
cksum: 2313332395 463765504 qnxrtp61.iso
md5sum: 8d2db8bef362f61cdc0a19d9e8963024 qnxrtp61.iso
Version: 6.1 | Filesize: 442.28 MB
этот образ позволит вам создавать встраиваемые системы.

А вот это - последняя версия этой ОС:
QNX 6.2.1 NC ISO image  
Description: This free download contains the version 6.2.1 of the QNX Neutrino RTOS with the QNX Photon microGUI. This ISO is a complete realtime development platform with a comprehensive suite of tools and software. For non commercial user only.
cksum qnxnc621.iso 179511721 248741888 qnxnc621.iso
md5sum qnxnc621.iso 0489c116af49f3aca814df33a6a3e13e qnxnc621.iso
Thanks to the recent coverage of QNX on various medias, there is a renewed interested in QNX download. Following this discussion if you have problems/questions in downloading: http://www.openqnx.com/PNphpBB2-viewtopic-t190-.html
Version: 6.2.1 | Filesize: 237.22 MB

P.S. Описание взято напрямую с сайта http://www.openqnx.com

[CaptHowdy]

Кот пишет:
Вот собираюсь засесть за MicroPC там ROM DOS стоит. Вот мне интересно хватит мне ентой Досы или есть смысл перейти на QNX. Задача впринципе линейная опросить входы и по запросу от мастера выкинуть данные.Ну пару сигналов завести на прерывание.Единственное жесткое требование скорость опроса 10 мс

Используйте QNX. Если вам не нужна визуализация на уровне GUI всю вашу задачу вместе с системой можно запихнуть в модуль не более 4Мб. С GUI соответственно увеличатся размеры. На счет времмени 10 мс. У QNX существует так называемый системный тик 1 мс по умолчанию (который, кстати можно уменьшить или увеличить). Это означает, что все потоки и процессы отрабатываются ядром за такой временной интервал (1 мс). Вам это подходит. В первом приближении это можно построить на таймерах в одной программе (RtTimer) или играться с многопоточностью (pthread_create) или через Resource Manager или сделать многопроцессовую систему (под процессом понимается отдельно запущенная программа параллельно другим программам). в общем, советую перейти на QNX.

[Гром]

CaptHowdy, хорошо агитируешь - верим - у нас недавно еще был свой спец по QNX да пока пропал - занят.
Есть у нас и статейки по QNX - то имеешь предложить?

[kosmax]

ИМНО, 4 Мб это очень много для решения данной задачи, конечно если ресурсы ограничены    Я думаю, что ДОСа + RTKernel вполне хватит, тем более если есть опыт работы с ними. Насчёт наилучшести QNX я бы не был так категоричен, поскольку в некоторых случаях лучше одно, а в некоторых другое. В Military не только QNX используется, насколько мне известно. CaptHowdy, а что такое  DiskOnModule ? :oops:

[Lex]

а что такое DiskOnModule ?

На сколько я понимаю это отдельная платка с Flash-памятью и контроллером какой-нить шины, например IDE. Неакая нразнавидность CompactFlah или подобных карт.

[Кот]

Привет всем.

4 метра софта это многовато. Я всегда думал что QNX на дискетку можно упихать. А сама софтина ну ни больше 350 кило будет весить.

P.S. хоть какое то оживление на форуме

[Гром]

Кот, заходи почаще, будет еще большее оживление...

[Lex]

4 метра софта это многовато. Я всегда думал что QNX на дискетку можно упихать. А сама софтина ну ни больше 350 кило будет весить.

Упихать то можно. Но нужно хорошо занть, что тебе надо, а что нет.

У нас на работе используют ecos? так сама система занимает 200К-300К вместе с TCP/IP стеком и поддержкое USB, правда без GUI. Думаю с QNX можно сделать так же. Только надо будет выкинуть все лишнее, когда ее будешь собирать.

[Zerg]

Интересно по поводу ecos.
На какой аппаратуре вы ее используете?

А есть здесь люди связанные с отечественной ОСРВ? Называется ОСРВ Багет, или ОС2000.

[Гром]

А есть здесь люди связанные с отечественной ОСРВ? Называется ОСРВ Багет, или ОС2000

Что- то не припомню я их ...

 Таганрог

Земляк - привет.!!!

[kosmax]

так сама система занимает 200К-300К вместе с TCP/IP стеком и поддержкое USB, правда без GUI. Думаю с QNX можно сделать так же. Только надо будет выкинуть все лишнее, когда ее будешь собирать.

Я думаю, что даже эту цифру можно уменьшить, тем более как я понял ГУИ вообще не требуется. Кот, а как часто мастер будет запросы выдавать и каким образом он будет их генерить. Может вообще можно без ОСРВ обойтись? насколько я понял ведь задачу можно свести к линейному опросу датчиков переодически прерываемому запросами от мастера. Если грамотно просчитать частоту возникновения запросов от мастера, а следовательно и передаваемый за один раз объём информации, то можно прикинуть время обработки одного запроса. Зная это время и время на опрос датчиков можно получить время одной итерации линейного алгоритма, которое вполне может тебя устроить, тем более ресурсы железа хорошие.
Lex, а что за зверь ecos? Где по нему можно что-нибудь почитать?

[Кот]

kosmax, Как часто мастер будет опрашивать объекты неизвестно соответственно от этого зависит и объем передаваемых данных либо это будут текущие значения либо архив за некий период. Самое важное это опрос датчиков с интервалом 10-50 мс большинство из них аналоговые. Соответственно система должна отреагировать в течении порядка 5-10 мс при определенном значении параметра. Ну и архивчик долбить надо на контроллере а потом по запросу сверху скинуть ему данные. Можно и в досе все это сделать но есть одно большое но это стабильность доса. Хотя конечно если руки ни оттуда растут то я думаю и QNX завесить не вопрос (QNX я незнаю поэтому утверждать не буду). в общем на волне влюбленности манагеров в QNX возможно придется делать на нем. Собственно поэтому и поднимал тему что бы узнать мнение народа.

[Lex]

kosmax, eCos это фришная ОСРВ. Чего-то сейчас ссылки на нее не могу найти. У нас она работает в ASIC с двумя ARM7 ядрами.

[Zerg]

А есть здесь люди связанные с отечественной ОСРВ? Называется ОСРВ Багет, или ОС2000

Что- то не припомню я их ...

Это операционка утвержденная министерством обороны для применения в военных встроенных системах. Пока еще монополисты на этом "рынке".

[Гром]

Zerg, в какой стране?

[Anonymous]

Zerg, в какой стране?

Сегодня узнал что вы живете не в России
ОСРВ Багет - это операционная система реального времени
разработанная (скорее слизанная) на основе vxWorks.
Разработку ведёт Научно Исследовательский Институт Системных
Исследований Российской Академии Наук (НИИ СИ РАН). Работает
на IDT процессорах MIPS R3081. Есть версия под Intel, но её,
кажется, не развивают. Принята российскими военными в качестве
стандарта для встроенных систем.

Реализация выполнена отвратительно Поддержки никакой.
Приходится писать прикладное ПО, работающее под этим чудом.
Хотел вот найти товарищей по несчастью...

[Гром]

Гость,   сожалею

[Elena]

Насчет ОС2000: товарищи по несчастью есть - это весь наш институт ЦН
ИИ Электроприбор в Питере. Кое-кто уже написал работающие программы, но долго кувыркались. Интерфейс с пользователем вышел корявый. Мне тоже предстоит кувыркаться начиная с осени

[anonimus_secretus]

Насчет ОС2000: товарищи по несчастью есть - это весь наш институт ЦН
ИИ Электроприбор в Питере. Кое-кто уже написал работающие программы, но долго кувыркались. Интерфейс с пользователем вышел корявый. Мне тоже предстоит кувыркаться начиная с осени

А мне ОСРВ Багет v2.0 даже нравиться начала уже. Пишешь себе на xlib и имеешь счастье в шустрых приложениях. Правда с nfs у нее глюки

[sergeydr]

Привет всем!

С интересом просмотрел всю переписку и удивился. Почему-то никто не вспомнил о Linux RTAI (Real-Time Application Interface) или о других Linux RT / Embedded !!! Странно ..., а ведь Linux 2.6 + RTAI  - гораздо шустрее и детерминированнее чем QNX6 ! Внимание, QNX4 - RTOS вне всякой конуренции ...

[RXL]

sergeydr, видимо никто из участников дискуссии не пользуется им.
Если не лень, расскажи в кратце, что там особенного. Ссылочки то же не помешели бы.

[sergeydr]

Ничего особенного там нет, просто очень удобно использовать б/п многоплатформенную 32-х разрядную ОС с возможностями HRT/SRT и б/п средства разработки ... и результаты неплохие (лучше чем в QNX6). В общих чертах архитектура RTAI  выглядит так (фрагмент перевода из DIAPM RTAI - Beginner's Guide):

" ... Linux недостаёт поддержки реального времени. Для получения поведения, отвечающего различным временным ограничениям, необходимо произвести изменения в ядре: в процедурах обработки прерываний и политиках планирования. Следуя этому пути можно получить систему реального времени с малой задержкой и высокой предсказуемостью, размещённую внутри обычного Linux окружения (предоставляющего доступ к TCP/IP сервисам, графическим системам, системам баз данных и т.д.).
RTAI предоставляет все функции ядра Linux с добавлением функций индустриальной системы ОС реального времени. Он представляет собой диспетчер прерываний: RTAI перехватывает прерывания от периферии и, в случае необходимости, перенаправляет их в Linux. RTAI не требует серьёзной модификацией ядра – используется концепция HAL (hardware abstraction layer – уровень аппаратной абстракции) для получения информации из ядра и для перехвата основных функций. Такой подход ведёт к небольшой зависимости от ядра. Это ведёт к простой адаптации к ядру Linux, простому переносу RTAI на новые версии Linux и более простому использованию других ОС вместо RTAI. RTAI представляет Linux фоновой задачей, которая запускается, когда не происходит никакой активности, требующей выполнения в реальном времени ..."

Основные ссылки:

http://www.rtai.org/ и http://www.aero.polimi.it/~rtai/

[Гром]

Я сижу на VxWorks сейчас...
А по поводу Линукс РТОС - eCos на базе Редната я ей пользовался одно время - жутко не понравилась, с одной стороны - все проблему Линукса у нее есть, с другой стороны нет ничего точно и подробно описанного и сделанного - много кустарщины и багов -

[sergeydr]

NB! Я прошу прощения, но eCos отноится к классу "компонентной" ОС и к Linux (другая архитектура) отношение имеет только постольку, поскольку ... Это был проект фирмы Red Hat, который позже вылился в самостоятельное направление (см. www.ecoscentric.com), котоорое активно развивается сейчас. Например, насколько мне известно, один из контроллеров фирмы ТЕКОН, Москва, использует как раз eCos 2.0... BTW! Как сейчас в eCos с драйверами для Ethernet?

[Михалыч]

... и результаты неплохие (лучше чем в QNX6)
Это сильно напоминает анекдот (из КВН-а кажется)
- Армяне лучше чем грузины!
- Чем лучше???
- Чем грузины!...
В чем лучше? Доводы и цифры в студию! Я так вот лично наоборот считаю. Доводы о цене в расчет не принимаются
Если я не ошибаюсь, на том же сайте dedicated system - ссылку см. выше, где-то в этой же теме - есть сравнение QNX c RTLinux.
Впрочем поискать - можно найти еще минимум 1-2 сравнения. Просто у меня нет ссылок под руками, увы. Но в свое время я этим занимался - так вот у меня как раз сложилось абсолютно обратное мнение. Linux лучше только в одном - условно бесплатный. Точнее дешевый. Бесплатного уже ничего нет Но спорить не буду. Аргументировать на ДАННЫЙ момент нечем. Если не лень - поищите сами

[Гром]

eCos: http://sources.redhat.com/ecos/ как видно из ссылки по прежнему под Красной шапкой.

Как видно из новостей - ОС продолжает развиваться.
С сетевыми драйверами я там не работал, ибо было направление совершенно иное. Однако по структуре ИКось по прежнему Линукс. И по структуре и по всему остальному, конфигурится вполне нормально и имеет поддержку от посикса до различных расширений и множества типов проессоров.

По приведенной тобой ссылке пройдя далее можно попасть сюды http://www.ecoscentric.com/ecos/index.shtml где есть ссылка на http://ecos.sourceware.org/ которая пересылает на мою.
Никуда он из под эгиды красной шапки не вышел....

А фраза "но eCos отноится к классу "компонентной" ОС и к Linux (другая архитектура) отношение имеет только постольку, поскольку" меня несколько рассмешила

[sergeydr]

Ну, для начала объявите _свои_ доводы и цифры ("в студию") ...

NB! Ваше _личное_ мнение в расчет не принимается!

[Михалыч]

Ну, для начала объявите _свои_ доводы и цифры ("в студию") ...
NB! Ваше _личное_ мнение в расчет не принимается!

Нет уж, нет уж... Лучше Вы...
Оригинальный метод отвечать.
А Ваше мнение - не ЛИЧНОЕ?
Не могу пока найти сравнения с RTLinux, но вот, например, то, что есть.
Пожалуйста - "с цифирями"
http://www.cniil.org/QNX_NEUTRINO_RTOS_V6_2_0.html
http://www.qnx.com/download/download/8122/QNX_Neutrino_62_vs_RedHat_Embedded_Linux.pdf

[Михалыч]

Впрочем RTAI и RTLinux не есть одно и тоже
http://bernia.disca.upv.es/rtportal/comparative/rtl_vs_rtai.html
Так что мои доводы легко можно оспорить
Впрочем, можно посмотреть вот тут - доводов и материалов навалом.
http://www.qnxclub.net/modules.php?name=Forums&file=viewforum&f=11&sid=3c28a653bb7fc7ab212032370591f986

http://www.qnxclub.net/modules.php?name=Forums&file=viewtopic&t=36&start=0&postdays=0&postorder=asc&highlight=&sid=3c28a653bb7fc7ab212032370591f986

http://www.qnxclub.net/modules.php?name=Forums&file=viewtopic&t=158&start=0&postdays=0&postorder=asc&highlight=&sid=3c28a653bb7fc7ab212032370591f986

http://www.qnxclub.net/modules.php?name=Forums&file=viewtopic&t=233&start=0&postdays=0&postorder=asc&highlight=&sid=3c28a653bb7fc7ab212032370591f986

А вообще-то, IMHO, такие сравнения (аналогично linux vs windows) неконструктивны. Инструмент хорош только в нормальных руках, кривым никакой распрекрасный инструмент не поможет. (Боже упаси, я ни о ком из присутствующих - не поймите неправильно ) А по сему критерии выбора могут быть и такими: Нравится - и ради бога. По деньгам - ну и хорошо. Руководство одобряет выбор - дык чего еще желать?
А так - сравнивать что блестит ярче и где цацек больше - странно. До сих пор уйма проектов разрабатывается и работает просто под МС ДОС. И ведь работает! Дводов приводить не стану, отошлю опять же на qnxclub.net там об этом спорили не раз и аргументированно. Можно и не повторяться

[RXL]

Только не надо распаляться! Знаю: сначала жаркий спор, затем битье посуды и разложение мебели на части...


Хотелось бы услышать любое (об- или суб-ективное) сравнение RTAI и VxWorks. Я ни на одном из них не программивал, но много работал с оборудованием под управлением VxWorks и скажу, что сервис у нее на уровне MSDOS, и нежная стабильность: если не дышать, то работает годами.

[sergeydr]

...


Хотелось бы услышать любое (об- или суб-ективное) сравнение RTAI и VxWorks. Я ни на одном из них не программивал, но много работал с оборудованием под управлением VxWorks и скажу, что сервис у нее на уровне MSDOS, и нежная стабильность: если не дышать, то работает годами.

Собственного опыта работы с VxWorks нет, поэтому я здесь "пас"  ...

В дополнение могу лишь добавить, что наша команда работает с QNX4 начиная с 1994 г., с появлением в 2000 г QNX RTP (ныне QNX6.3) мы серьезно задумались ... и в результате (несколько лет проб и ошибок) прешли в Linux Debian/GNU+RTAI. Но при этом от QNX4 не отказались.

[sergeydr]

...
А вообще-то, IMHO, такие сравнения (аналогично linux vs windows) неконструктивны. Инструмент хорош только в нормальных руках, кривым никакой распрекрасный инструмент не поможет. (Боже упаси, я ни о ком из присутствующих - не поймите неправильно ) А по сему критерии выбора могут быть и такими: Нравится - и ради бога. По деньгам - ну и хорошо. Руководство одобряет выбор - дык чего еще желать?
А так - сравнивать что блестит ярче и где цацек больше - странно. До сих пор уйма проектов разрабатывается и работает просто под МС ДОС. И ведь работает! Дводов приводить не стану, отошлю опять же на qnxclub.net там об этом спорили не раз и аргументированно. Можно и не повторяться

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

[sergeydr]

В продолжение темы "встраиваемый Linux и реальное время": многие производители электронных модулей PC/104 и др. дополняют свой "железный ряд":

1. Diamond Systems: RTLinux Pro

http://www.diamondsystems.com/products/rtlinuxpro.php3

2. CompuLab Ltd: RH Linux

http://www.compulab.co.il/linux.htm

3. Ampro - используют TimeSys Linux

http://www.timesys.com/products/

(но не афишируют)

и др.
 

[RXL]

Кстати, стоит упомянуть, что фирмы, делающие модифицированные ядра Linux-а, частенько не предоставляют исходников, чем нарушают GPL.

[sergeydr]

Кстати, стоит упомянуть, что фирмы, делающие модифицированные ядра Linux-а, частенько не предоставляют исходников, чем нарушают GPL.

Есть такое дело ... Однако, GPL требует только:

"... обеспечить получение новыми обладателями программы ее исходного текста или возможность его получить..." (автор перевода Елена Тяпкина,  tiapkina@hotmail.com , 09 -Aug-2001

BTW! В большинстве случаев конечный потребитель не нуждается в исходниках, а партнеры при необходимости такой "доступ к телу" получают.
 

[Михалыч]

to sergeydr
Да, конечно, я и не собирался никого убеждать что это лучше - а это хуже... Эмоционален - да! Что есть, того не отнять
А у Вас солидный опыт работы. С 94 года с QNX - это действительно серьезный опыт. Наша контора пришла к QNX-у примерно 4 года назад. Правда сейчас мы серьезно используем QNX6.2.1 а не 6.3. Ввиду новой ценовой политики QSSL. Конечно, 6.0 и 6.1 это были вообще не системы. Экспериментальный образец, скорее. А сейчас - вполне ничего. В этом отношении мне было бы крайне интересно (если не трудно Вам конечно) услышать Ваше мнение о том - почему конкретно вы ушли на Linux+RTAI. Т.е. именно о тех самых пробах и ошибках. Нам-то с этим еще жить и жить Можно не в форум - в мыло. Буду очень благодарен.

[RXL]

Протестую! Почему же не в форуме? Конечно, если в том какая информация не для всех, то понятно, а так - лучше здесь. Думаю не только мне было бы интересно почитать.

[Михалыч]

  ничего против не имею...

[RXL]

ж)

[sergeydr]

...

В этом отношении мне было бы крайне интересно (если не трудно Вам конечно) услышать Ваше мнение о том - почему конкретно вы ушли на Linux+RTAI.
...

Кратко:

1. Начиная с версии 4.25 QNX4 стал "беднеть" в части поддержки "продвинутых" девайсов (драйверы)
2. Отсутствие в QNX RTP (2000 г.) любимого Watcom C/C++
3. Несовместимость приложений версий 4 и 6 (кстати, такая же ситуация была, когда появилась QNX4, a QNX2 была "жива" (1991)
4. Явное стремление QSSL интегрироваться в Linux-коммьюнити (GCC)
5. Неудовлетворительные результаты тестов на производительность (пузырьковая сортировка, например) по сравнению с QNX4.25
6. Очень дорогие средства разработки и графическая среда
7. Сомнения в рыночных перспективах этого продукта в РФ
8. Привлекательность философии "open source" в среде программистов, заинтересованность ряда заказчиков в ОС с открытыми исходными текстами (сертифицируемость)
9. Положительные результаты собственных работ с Linux RH 6, 7, 9, Madrake 8, Witedwarf Linux, Embedded Linux Development Kit (ELDK) 2.1.0, Debian/GNU Linux (Woody, Sarge).

и др.

Итог: в качестве базовой программной платформы выбран Debian/GNU Linux (Woody, Sarge), RTAI.

Но QNX4 и QNX6 мы не "закрыли" для себя окончательно ... (-:] 

[Михалыч]

Ну, да... С пунктами 1-3 не согласится невозможно. Особенно с первым Собственно это был один из определяющих моментов отказа от 4.25 в пользу 6. Пункты 2 и 4 под вопросом. Тут м.б. и неизвестно - хорошо это, или плохо. Скорее хорошо, по-моему Пункт 6 - не просто да, а ДА!!! Не дешево, но платить то можно один раз, а пользоваться "до посинения", то бишь до окупаемости. В наших (специфичных) условиях об окупаемости речь не шла изначально. Бо не ширпотреб делаем (наверное к сожалению ). Скорее о предсказуемости, надежности и гарантиях реактивности. Отсюда и пункт 7 для нас как бы не очень актуален, хотя, никто не скажет, как может жизнь завтра повернуться

[sergeydr]

...
В наших (специфичных) условиях об окупаемости речь не шла изначально. Бо не ширпотреб делаем (наверное к сожалению ). Скорее о предсказуемости, надежности и гарантиях реактивности.
...

Насчет окупаемости - в наших условиях (РФ) эб этом редко задумываются. Это правда. Тем более, что речь идет, прежде всего, о стоимости средств разработки (самая "тяжелая" составляющая сметы нового проекта), что сложно просчитываются.

Что-же до "предсказуемости, надежности и гарантиях реактивности" - по моему разумению (и по хронологии выхода версий QNX4 за 10 лет) для того, чтобы ОСРВ дошла до полностью заявляемых кондиций необходимо мин. 5 лет тяжелого труда пользователей (программеров-разработчиков) - т.к. вычерпать все баги на этапе разработки и тестирования невозможно!!!

Т.о. сечас можно приступать к QNX 6.3 с большими гарантиями "предсказуемости, надежности и гарантиях реактивности" (-:]

[sergeydr]

...
А фраза "но eCos отноится к классу "компонентной" ОС и к Linux (другая архитектура) отношение имеет только постольку, поскольку" меня несколько рассмешила

Ответ Грому поводу отличий eCos от Linux:

Цитирую "доктора геббельса" (Anthony J. Massa Embedded Software Development with eCos™ Chapter 1, Pg. 3):
" ...
One method to control software components is at run time. In this method, no up-front configuration of the component is done. The code linked to the application provides support for all behaviors of the component whether it is required by the application or not, causing the code size to be much larger. An example of run-time control is an application that runs on a desktop. When the application is executed from the disk drive, the shared libraries (Dynamic Link Libraries [DLL], etc.) needed by the application are loaded when the application starts.

Another method for component control is at link time. In this case, the code can use only the specific functions of a component that it needs, and the code that supports functionality not needed by the application is left out. Many linkers, such as the GNU linker (ld), offer link-time control, or commonly called, selective linking. With selective linking, unreferenced functions and data are removed from the application image. However, this is still insufficient because only entire functions can be removed—an all-or-nothing approach

eCos uses compile-time control methods for its software components, along with selective linking provided by the GNU linker. Using compile-time control or source-level configuration is achieved by using the C preprocessor. An example of source-level configuration is shown in Code Listing 1.1. The flag INCLUDE_FUNCTIONALITY is either enabled or disabled by the developer. When this section of the code is compiled, only the code that is needed is included in the application image.Listing 1.1 Example code of source-level configuration.1  #ifdef INCLUDE_FUNCTIONALITY23  ...45  #else67  ...89  #endifWith source-level configuration, very specific options can be applied in the code, which is appropriate for embedded systems since the majority of embedded applications compile into static images."

Надеюсь дополнения излишни ... (-:]!

[Narg]

Интересно по поводу ecos.
На какой аппаратуре вы ее используете?

А есть здесь люди связанные с отечественной ОСРВ? Называется ОСРВ Багет, или ОС2000.

Есть. ос2000 разрабатывается у нас в отделе системного программирования НИИСИ РАН. Вводную информацию о системе можно получить здесь:

http://www.niisi.ru/intro1.htm