eCos, open-source RTOS Опции

[Серокой]

Да корявость проявляется скорее в том, что у меня голова коряво под эту утилитку заточена.
В общем, у меня своя плата, я беру за шаблон EB40A, она похожа в основны чертах, и начинаю собирать RedBoot... В итоге - масса настроек, кроме того, файлы ещё и ручками надо править (инициализацию амбы, например), в итоге нифига не работает. Где-то что-то не то скрутил.
В общем, будь интерфейс подружественней, корявости было бы меньше...

[IgorKossak]

На eCosCentric нашел более свежую версию утилиты конфигурирования eCos - configtool-040623.exe Config Tool.
Похоже, что эти утилиты и сама eCos это всё, что распространяется бесплатно.

[Серокой]

Ну ещё бесплатно есть книжки по eCos...

Это "EMBEDDED SOFTWARE DEVELOPMENT WITH ECOS™ Anthony J. Massa" и "RedBoot™ User’s Guide".
На FTP не видел, вроде бы нету, надо - залью.

[v_shamaev]

Ну ещё бесплатно есть книжки по eCos...

Это "EMBEDDED SOFTWARE DEVELOPMENT WITH ECOS™  Anthony J. Massa" и  "RedBoot™ User’s Guide".
На FTP не видел, вроде бы нету, надо - залью.

Вот здесь книга http://www.informit.com/content/downloads/.../0130354732.pdf

[v_shamaev]

Я как раз занимаюсь сейчас портированием Ecos на свою плату. Впечатления вполне позитивные  
С доступностью исходных кодов и кол-вом документации в принципе проблем нет.
По ходу есть конечно ряд вопросов - хотелось бы пообщаться с теми кто еще портировал данную  ОС . Есть тут такие ?

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

[one_man_show]

Уважаемые!
Хоть кто-то может сказать что-то конкретное об операционке? Уже две страницы написано, а конкретных отзывов нет. Пожалуйста, расскажите, что именно вней хорошо, если можно в сравнении, если нет, то без оного. Кроме того, всем, кто этой РТОС не пользуется могут быть интересны и полезны и минусы какие-то или подводные камни.

[Andrew2000]

И еще вопросы - eCos - написано что это RTOS, а разве Linux (даже 2.6) это RTOS? - как их сравнивать ?
И если eCos - RTOS, то какая - soft/hard ?

[IgorKossak]

И еще вопросы - eCos - написано что это RTOS, а разве Linux (даже 2.6) это RTOS? - как их сравнивать ?
И если eCos - RTOS, то какая - soft/hard ?

Однозначного, всеми поддерживаемого, стандарта определения RTOS на сегодняшний день не существует.
Кое что можно об этом узнать из прилагаемого черновика.

Прикрепленные файлы

 Rtos.pdf ( 693.56 килобайт ) Кол-во скачиваний: 5484

 

[one_man_show]

Давно сталкивался с принятыми определениями РТОС: жесткое реальное время и нежесткое РВ. Специалисты обычно используют два этих термина, но иногда хочется расширить палитру, тогда получаем, следующее. uC/OS-II - это ОС жесткого реального времени. Windows 95/98 - нет слов, NT/2K "потверже", хотя до реальной жесткости далеко. Linux "твердая", но не ОС жесткого реального времени.
Еще РТОСы разделяют на вытесняющие и невытесняющие. Это о том, что проиходит после обработки прерывания: либо возврат в текущую выполняемую задачу (невытесняющая РТОС), либо переход к более приоритетной задаче (вытесняющая).

На мой взгляд эти понятия устоялись в течение лет 20-ти и их смело можно использовать для характеристики операционок.

Теперь бы в этих терминах услышать что-либо о eCos

[v_shamaev]

Во-первых, это встраиваемая ОС - т.е. после конфигурирования и компиляции получаем
библиотеку, несколько объектников и набор хидеров с API. Пишем свое приложение,
собираем с этой библиотекой и получаем образ для ПЗУ.
Среда разработки - gcc, и только он - поначалу было желание использовать более эффективный компилятор, но это слишком много работы - операционка большая.
Отладка происходит след. образом (у меня) - во флеш target-платформы зашит
отладочный монитор (RedBoot, входит в eCos), он может общатся с хостом через
послед. (или любой другой) порт или ethernet. А на хосте - gdb/insight.
Сравнительно неплохо, GDB - хороший отладчик, но модуль большой - загружается
даже на 115200 долго - секунд 80 - сейчас посчитал.

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

Поддерживаемые платформы и устройства можно посмотреть тут: http://ecos.sourceware.org/hardware.html
Одно могу сказать - их очень много, и этот список на самом деле гораздо шире - не
все железо перечислено. Теперь относительно политики разработчиков/дистрибьюторов - поначалу (года 4) все было доступно полностью, сначало это был cygnus, затем RedHat,
а тепер eCosCentric - так вот, кое - что уже только за денюжки - или экспериментируй и
сам добивайся. Библиотеки у eCos все свои, так вод STL они не поддерживают, оно может
и правильно для встраиваемых систем, но не удобно. А в поставляемый eCosPro Developer's kit - входит расширенная библиотека, там эта поддержка есть.
Хотя eCos и заявлен как C++, но это весьма условно, чистый C, с возможностью использовать C++ (т.е. не нужно специально ничего доделывать).

Что касается жесткости реал-тайма, то в общих чертах - весьма жесткий, хотя с одной стороны - весьма настраиваемый (можно выбирать шедулер из трех, но я никогда
этим не занимался), можно и разрешить динамическое изменение приоритета при необходимости, а с другой - в критических участках можно просто запрещать шедулинг -
т. е. уже мягчеет. Да и для моих задач жесткий реал-тайм и не нужен, важнее скорость
переключения задач. Сам я измерениями не занимался, но знакомый рассказывал, что они сравнивали скорость реакции на прерывание - Linux, QNX, eCos - так у них быстрее всех
получился eCos, за ним QNX. Заранее готов предупредить вопрос - подробности мне неизвестны, хотя подозреваю, что люди, принимавшие участие в этом эксперименте посещают данный форум.

[one_man_show]

Спасибо, интересная информация.
Есть ли порт под РС (ДОС или Вин)? Если есть, запустите ради интереса на мощном РС под Вин и на слбенькой железке напрямую. Думаю получите интересный результат: "жесткости" будет больше не там, нде аппаратура мощнее, а где операционка честнее квантуется, т.е. на слабой железке, даже задачи могут шустрее переключаться.

[v_shamaev]

Под PC есть два варианта - как подзадача под линуксом (synthetic target )- и под голое железо. Первый вариант я использовал для отладки и освоения - сборка/запуск гораздо быстрее, можно проверять идеи, отлаживать взамодействие своей задачи с системой.

Второй вариант - уже как чисто встраиваемая, запускается и отлаживается под vmware.
Здесь можно было с сетевыми задачками поиграть - в vmware есть приличный эмулятор
сетевой карточки.

Да, и еще забыл написать - в eCos есть огромный набор тестов, объем кода тестов сопоставим с объемом кода самой ОС. Поэтому после генерации версии, с которой предстоит плотно работать, обычно собирается и прогоняется весь набор тестов - для ядра,
библиотек, драйверов, устройств Благо, процесс достаточно автоматизирован,
можно потом просто логи посмотреть и сделать выводы о пригодности версии.

[one_man_show]

Раз уж Вы так любезно консультируете, то, чтобы в доки не лезть, зачитайте вслух пожалуйста минимальные требования к железке. А то говорят про порты для АРМа, но АРМы-то разные бывают.

[IgorKossak]

Вполне достаточно минимального на сегодняшний день ARM-ядра без MMU - ARM7TDMI.
У eCos требований к железу и к памяти намного меньше, чем у uCLinux и, тем более чем у ARMLinux.

[v_shamaev]

Если вас интересует именно система - со свими правилами, устоями, и набором сервисов -
то приходится идти на некоторые затраты - я имею ввиду размер кода. Но если активно
использовать возможности системы, эти затраты не столь значительны. Текущий проект
у мнея на AT91 R40008 - не самый быстрый, не самый еавороченный. На настоящий момент объем кода ~600к, из них сама система (та часть, что требуется) - чуть больше 100к.

Это что касается ПЗУ, а с ОЗУ - зависит целиком от прикладной задачи, ну и еще если TCP
требуется - наиболее развит вариант от BSD, ну очень харчистый. А если пару ниток (threads) - еще служебные есть (idle) да 'Hello, World', - то и 16 к хватит.

Но для отладки (удобнее всеж-таки в ОЗУ отлаживатся) - прибавьте 500к-1м.

MMU не требуется - но и не отвергается. Т.е. при возможности защита памяти может быть
использована.

Да, и еще - в отличие от Линукса, система не является многозадачной в смысле запуска процессов (fork отсуисвует) - система многонитевая. Да я честно говоря, и смысла не вижу
в подобных вещах для встраиваемой системы реального времени.