RTOS

[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