Кто может сказать что-нибудь хорошего/плохого об этой ОС применительно к АРМам и не только.
На первый взгляд - заманчиво:
- открытые исходники;
- доступные средства разработки;
- много документации;
- многоплатформенность;
- ...?
Очень хочется услышать мнение профессионалов.

Заманчиво? Заманивайтесь!
Для начала попробуйте ее скачать... бесплатно... особенно по диалапу.
Потом будете платить Редхату.
Потом 2-3 квартала разбираться шож эти яйцеголовые накрутили на ровном месте.
Ни с чем не совместимое, поддерживается узким кругом разработчиков, соответсвенно документация, скажем очень скромная, круг пользователей узок.
Современный советский эмбеддер находится под жестким прессингом сроков, никто не позволит ему потратить пол года на изучение чего-то уводящего в сторону от мейнстрима и с неизвестными резудьтатами на финале...
Слава Богу англичане не дают коммерциализировать АРМ линух.

Итак, какая же разумная eCos альтернатива?
Ведь, насколько мне известно, ARM Linux разработана для кристаллов с MMU.
Что могут сказать специалисты об uClinux?

Да нормальная eCos (в смысле вполне осваиваемая) система.
Мы сделали управляющую плату (Cirrus Logic ARM, QVGA, RAM-Flash, Flash-disk, RS, USB, BlueTooth и FPGA со всякими специфическими перенастраиваемыми периферийными устройствами) и используем эту плату уже в нескольких устройствах.
На начальное освоение какое-то время конечно ушло. Но сейчат вроде проблем нет.

Спасибо за отзыв, svtsvt.
В связи с этим - попутный вопрос. Какой средой разработки Вы пользовались и была ли это eClipse based IDE от eCosCentric, а также, покупали ли Вы eCosPro Developer's Kit?
Заранее благодарен.

Да нет никакой среды.
GNUсные компиляторы и виндусовая утилита для настройки ядра системы.

Насколько я знаю лицензия более хорошая чем GPL, в явном виде сказано,
что можно прилинковывать свой код без его предоставления.
А то под GPL возъмешь кусок кода в качестве образца, а потом не понимаешь - после модификации его под свои нужды какая у него лицензия?

>Потом будете платить Редхату
вроде раньше это было, что redhat поддерживал eCos, вроде он отказался

>круг пользователей узок
вообще то, как правило производители не кричат, что их изделие
базируется на свободно распространяемой ОС, нет смысла.
Другое дело если Вы используете VxWorks и т.д. Это марка.

>виндусовая утилита для настройки ядра системы
утилита от eCosCentric?

С уважением,
Дмитрий.

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

А что екос? Что в нем такого хорошего, чего нет скажем в линуксе или uClinux?

Я пользую стандартное линуксовое ядро с патчем от санпипл. Вроде как для 2.6 ветки и патч не нужен. ARM там как родной.

1) Как верно заметил dch, есть отличия в лицензии (eCos License Overview). Правда, у нас часто не смотрят на лицензию продукта.
2) eCos, скажем так, более "легкая" ОС по сравнению с uClinux. Можно работать на target c меньшими рескрсами (флеш, RAM, ...).

2) eCos, скажем так, более "легкая" ОС по сравнению с uClinux. Можно работать на target c меньшими рескрсами (флеш, RAM, ...).

[/quote]

Меня привлекала именно - конфигурируемость и возможность обойтись минимумом ресурсов...

Чем конфигурируете?
Утилитой от eCosCentric или как-то иначе?

[/quote]
Чем конфигурируете?
Утилитой от eCosCentric или как-то иначе?

[/quote]

Утилитой самой Ecos... А есть еще какие-то варианты ? В смысле можно чем-то еще добиться какого-то лучшего результата ?

Ага, что такое eCosCentric? То самой утилиткой от екос как-то коряво получается...

Что значит "коряво" ? Можно аргументировать то ?

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

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

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

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

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

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

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

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

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

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

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

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

Во-первых, это встраиваемая ОС - т.е. после конфигурирования и компиляции получаем
библиотеку, несколько объектников и набор хидеров с 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. Заранее готов предупредить вопрос - подробности мне неизвестны, хотя подозреваю, что люди, принимавшие участие в этом эксперименте посещают данный форум.

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

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

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

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

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

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

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

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

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

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

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

Случайно наткнулся на данный форум.
Сейчас я как раз занимаюсь сборкой eCos для платформы на базе LPC2294.
У меня есть два вопроса :
1. Мне необходима возможность дистанционного обновления образа eCos. Соответственно вопрос RedBoot продолжает функционировать при запуске eCos? Так же непонятен процесс автоматичекого запуска Redboot-ом операционнки.
2. У меня следующая проблема RedBoot или приложение (например ping_test)откомпилированное с операционкой, запускаются исключительно с внутренней flash (стартовый адресс 0). Похоже у меня проблема с векторами прерываний, но как их изменить я не знаю.
Буду благодарен за любой совет.

RedBoot нужен только на период отладки - основные его задачи - при старте привести контроллер в рабочее состояние (чипселекты, вайтстейты, внутренние регистры, вектора)
и выйти на связь с GDB (точнее, запустить stub GDB) - и все, дальше стабом грузится ваша задача (это может быть и eCos собранный с прикладной задачей), и передается управление
задаче, правда с учетом присутствия отладчика - вектора прерываний перенаправлены.

Касательно места загрузки вашей задачи - это определяется в скрипте для линкера - в дистрибутиве системы - в packages/hal найдите вашу платформу, и там в include/pkgconf файлы *.h,*.lda,*.mlt для каждого варианта генерации (rom, ram, ronram) описывают модель памяти - можно подредактировать их, а можно и в сгенерированной системе - я делаю просто, *.ld стираю, а редактирую *.ldi соответствущий, после чего он make-ом восстанавливается (ldi проще).

mlt_xxx.h и mlt_xxx.ldi файлы я редактирую, также изменяю значение HAL_PLATFORM_RESET_ENTRY, но это почему то не помогает. Не зависимо от выбранного варианта запуска программа переходит на на 0-вые адреса. Попутно хотелось бы задать следующий вопрос:
В RedBoot я использую ethernet контроллер. При запуске приложения в котором не используется ethernet всё работает. Для примера:

+... waiting for BOOTP information
Ethernet eth0: MAC address 08:88:12:34:56:78
IP: 10.0.0.41/255.255.252.0, Gateway: 10.0.0.5
Default server: 10.0.1.10

RedBoot™ bootstrap and debug environment [ROM]
Non-certified release, version UNKNOWN - built 15:57:02, Jan 27 2005

Platform: ALBATROS MP9 PLC board (ARM7TDMI-S)
Copyright © 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.

RAM: 0x81000000-0x81200000, [0x8100a0a0-0x811ed000] available
FLASH: 0x80000000 - 0x80400000, 64 blocks of 0x00010000 bytes each.
== Executing boot script in 5.000 seconds - enter ^C to abort
*[cyg_net_init] Init: mbinit(0x00000000)
[cyg_net_init] Init: cyg_net_init_devs(0x00000000)
Init device 'cs8900a_eth0'
[cyg_net_init] Init: loopattach(0x00000000)
[cyg_net_init] Init: ifinit(0x00000000)
[cyg_net_init] Init: domaininit(0x00000000)
[cyg_net_init] Init: cyg_net_add_domain(0x81000ca4)
New domain internet at 0x00000000
[cyg_net_init] Init: cyg_net_add_domain(0x81000774)
New domain route at 0x00000000
[cyg_net_init] Init: call_route_init(0x00000000)
[cyg_net_init] Done
Hello, eCos world!

Если в приложение добавить:
int main(void)
{
printf("Hello, eCos world!\n");
///////////////////////////////////////////////
init_all_network_interfaces();
while(1);
}

То при вызове init_all_network_interfaces(); просходит перезапуск программы.
Хотя если нет Redboot всё работает без проблем (правда тогда прложение находится во внутренней flash).

Может здесь присутствует какая то общая ошибка (моя естественно)?

А памяти достаточно? Помнится, сходная ситуация была, когда под буфер стека IP пожадничали с выделением памяти - он там что-то много просил - это если BSD-ешный
стек. А вообще припоминаю, по листу на RedHat-е - было много вопросов по отладке из
RedBoot-а через Ethernet - коннект терялся. У меня в рабочей конфигурации сети нет, хотя
внешний контроллер есть, но в единственный разьем вставлено внешнее ОЗУ для отладки -
вместо flash.

Сделал дизассемблер и обнаружил следующюю вещь:

Disassembly of section .rom_vectors:

80000000 <__exception_handlers>:
80000000: ea00000e b 80000040 <_stext>
80000004: e59ff018 ldr pc, [pc, #24] ; 80000024 <.undefined_instruction>
80000008: e59ff018 ldr pc, [pc, #24] ; 80000028 <.software_interrupt>
8000000c: e59ff018 ldr pc, [pc, #24] ; 8000002c <.abort_prefetch>
80000010: e59ff018 ldr pc, [pc, #24] ; 80000030 <.abort_data>
80000014: 00000000 andeq r0, r0, r0
80000018: e59ff018 ldr pc, [pc, #24] ; 80000038 <.IRQ>
8000001c: e59ff018 ldr pc, [pc, #24] ; 8000003c <.FIQ>

00000000 <__exception_handlers>:
0: ea00000e b 40 <_stext>
4: e59ff018 ldr pc, [pc, #24] ; 24 <armreg_r9>
8: e59ff018 ldr pc, [pc, #24] ; 28 <armreg_r10>
c: e59ff018 ldr pc, [pc, #24] ; 2c <armreg_fp>
10: e59ff018 ldr pc, [pc, #24] ; 30 <armreg_ip>
14: 00000000 andeq r0, r0, r0
18: e59ff018 ldr pc, [pc, #24] ; 38 <armreg_lr>
1c: e59ff018 ldr pc, [pc, #24] ; 3c <armreg_pc>

Как видно описание переходов абсолютно одинаковое.
Кто нибудь знает -- у LPC22xx счетчик команд равен при попадании на вектор равен 0 или адресу собласти на которую производится mapping.

А просто по шагам под отладчиком? По ассемблерному, не по C? Нудно, но помогает.
И стек можно посмотреть - откуда попали.

Если бы я умел им пользоваться.......

Печально. Но не смертельно. Во-первых - есть запускаемый Insight? он называется arm-elf-insight, или бывает вариант arm-elf-gdb с ключом -w, если запускается - дальше просто - подключенный через com-порт или через ethernet (сложнее) RedBoot на целевой
машине - в Insight-е в меню target setting выбираем вариант подключения - remote serial или
remote TCP. Вообще, для начала стоит посмотреть книжку Antony J. Massa "Embedded Software Development with eCos", ссылку я в этой дискуссии раньше давал, там на стр. 305 все подробно написано - а дальше довольно просто - пошаговая отладка через иконки доступна, там есть как по коду на c, так и по машиннам командам. Стек можно посмотреть, вызвав окно. И пройти назад по цепочек вызовов. Рекомендация - инструментарием пользоватся только патченым в соответствии с указаниями на сайте eCos-centric-а.

Спасибо за информацию, сейчас буду разбираться.

Скачали последнюю текущую рабочую версию ecos. До этого пытались собирать ecos 2.0. В последней же версии в hal присутствует и плата AT91SAM7xEk, которая нам больше всего подходит. Но ни одна из конфигурации (начиная от редбута, заканчивая all) не собирается. Возникают ошибки типа CPSR_USER_MODE undeclared (first use in this function) и другие подобные, в которых фигурирует этот CPSR (вроде во всех файлах, которые указаны в ошибках, это объявлено). Как можно исправить проблему? может, из старой версии надо что-то скопировать и подправить? Вопрос, где??? Очень жду ответа!!!

Простой поиск показывает, что ...

CPSR_USER_MODE объявлен в hal_arch.h и просто не может быть undeclared при корректной сборке для ARM. Наверно ошибки в конфигурировании. Пока посоветовать ничего не могу, есть только вопросы.
Как вы конфигурируете ecos? Какие пакеты входят в конфигурацию? Какой компилятор? Windows или linux?

Про ecos 2.0 забудьте. Это старье. Не думаю, что оттуда стоит что-то копировать.

Спасибо за ответ. Вроде все нормально. Похоже, это был глюк с самим конфигтулом. Надо было, видимо, каждую новую конфигурацию под новым именем сохранять. А компилим под Линуксом.
Ещё вопрос:
Подскажите, пожалуйста, как написать простую программу зажигания светодиода на плате AS-Sam7x (мк AT91SAM7x256), используя функции eCos. Вроде собрали библиотеки для eCos (конфигурация default или minimal), в качестве template выбрали AT91SAM7x-EK. Скомпилировали пример (к-рый с платой поставлялся) вместе с полученными библиотеками. Бинарник прошили в мк, но, конечно, ничего не заморгало(этот пример ведь не для eCos). Где можно функции eCosовские посмотреть или может, примерчик есть у кого-нить простой?

Примеров полно в самом репозитарии ecos. Соберите тесты (есть практически для всех пакетов) или посмотрите директорию examples. Все примеры осуществляют вывод в консоль, поэтому проверить работоспособность легко.
Светодиод в ecos можно зажечь также как и в программе для МК без ОС, т.е. записать значение в порт. Ну разве, что принято использовать для этого макросы HAL_WRITE_UINT32 и HAL_READ_UINT32. Тут уже читайте документацию.

Ввложите. плз, если есть у кого, ссылку на exe-шник установочный для КОНФИГТУЛА под Windows (старую версию снесли, хотели новую скачать, все ссылки - на редхатовский сайт. В списке зеркал то ссылка не открывается, ошибку выдает, то при самой скачке ошибка и не грузится). Помогите, плз

Здесь вроде есть. Сам не скачивал, но должно работать.

[quote name='axle' date='Mar 17 2008, 09:08' post='380614']
Здесь вроде есть. Сам не скачивал, но должно работать.
[/quo
СПАСИБО!!!

Как обстоят дела на сегодняшний момент с этой ОСЬю? кто пользуется отпишитесь.

она умерла ...

Даладна!
Живет и у нас и за бугром, причем появляется поддержка новых архитектур.