Есть ли кто нибудь кто практически использует еСos? Стоит ли с ним связываться ? Хотелосьбы унифицировать все проекты (и там где стоят маленькие АРМ и те которые делаються на промышленных компьютерах ) под один РТОС. Посмотрел вроде это наиболее подходящее но попробовал сделать синтетический порт под линуха то немного помулался. А порт на РС с redboot пока не получился. Вот и начал задумываться стоит дальше мучаться или нет. И еще вопрос по литературе и вообще по интересным ссылкам и проектам , где копать?

Ну, практически, нет, а разбираться начал ...
upload/DOCs/Eclipse/ecosarm-1.3.chm - буду дополнять по-мере освоения
"Стоит ли с ним связываться ?" сам хочу понять (а то и дополнять нечего

Собирал под vmware - не работает, под PC - нет проблем.
Но свободной персоналки нет, хочу под vmware или под Linux (еще не пробовал).

А в чем под Linux проблемам - может поделитесь?

Я установил eCos под Fedora Core 4, научился делать загрузочные дискеты для ПК, запускать прогу на таргете под отладчиком, но дело встало.
Может кто подскажет как заставить eCos видеть винт и грузить с него проги?

А зачем? Он это делать умеет, но на мой взгляд - зря. eCos - встраиваемая операционка, т.е. библиотека - пишете приложение, собираете с осью, получается двоичный образ, зашивается в ПЗУ - и все. А всякие динамические загрузки и выделения памяти - потенциальный завис.

Мне это какраз нужно. Для начала я хотел бы собрать eCos с тестовым приложением и заставить всё это стартовать с жёсткого диска на x86. Так же нужен файловый ввод/вывод, последовательные порты.

Если одно приложение - особых проблем не вижу - получаете загрузочный образ, на диск - вперед. Но на мой взгляд это целесообразно только если стоит одна задача, уже не учебная. Я бы поступил так - поставил vmware, и из под нее грузил бы хоть двадцать образов - каждый в виде файла. Консоль есть, файловая система тоже поддерживается. Да и отлаживаться при нужде можно (хоть и несколько сложно )

Приложений будет 2. Я пишу под Linux'ом в POSIX, так что отлаживать эти программы на целевой платформе не придётся (я надеюсь).
По поводу загрузочного модуля. Как его получить? В примере из документации собираетрся RedBoot, заливается на дискету. А тестовая программа компилится в отдельном проекте и загружается по сети или COM (командой load) на таргет. Дальше исполняется командой go. Но это не то, что мне нужно. К стати после команды go в терминал выводится бред вместо "Test string\n". У меня получилось запустить тест в отладчике так-же через COM.

Так точно так же как и RedBoot - в конце концов, он то же из eCos собирается. Только вместо RedBoot на дискету, образ заливается приложение, собранное с eCos. В тестовом примере разбирается отладочный случай - редбут все-же проще запустить, а если он работает, значит уже можно и свое что через отладочный канал грузить-отлаживать. Ну а если прошлись по всем граблям, дальнейшее труда не составит. Ну и еще - в окончательном варианте не должно быть резидентной части отладчика, модель памяти - ROM, и вся инициализация своя - не из RedBoot-а

При компиляции редбута создаётся bin файл, который заливается на дискету. При компиляции шаблона i386 PC target (default) такого файла нет. При компиляции непосредственно программы с либами из шаблона всё проходит успешно. Но как её объединить с eCos?

Т.е. проблема в получении двоичного образа из elf-а? objcopy -Obinary это делает. А эти самые "либы из шаблона" - и есть eCos. Для образца можно посмотреть make из examples. Там все правильно собирается

Я так и поступил. Взял Makefile из примера, компилю, запускаю i386-elf-objcopy, заливаю полученный бинарник на дискету (dd conv=sync if=bin_file of=/dev/fd0), сую дискету в дисковод, перезагружаюсь и ничего. К дискете происходит обращение и система виснет.

Значит где-то в конфигурации eCos что-то. Попробовать запустить под vmware или эмулятором DOS линукса в отладочной моде, посмотреть где висит или циклится, ну и по карте загрузки - в каком месте. Если в самом начале - или вектора, или неправильная модель памяти. А под отладчиком - посмотреть в начале инициализация, в разных моделях памяти по-разному происходит. А если не в начале - то с консольными портами ошибка в конфигурации. В любом случае - идти по шагам, попытки сразу получить конечный результат - нахальство.

Та же проблема, только наоборот: с дискетки на PC запускается, под VMWARE - виснет при обращении к дискете (запускал RedBoot).
Три версии VMWARE перепробовал ...

В прошлом году я тоже баловался с eCOS. Даже запустил один из примеров на LPC2294 без внешнего ОЗУ. На том дело и заглохло.
По поводу зависонов - они были. eCOS был сконфигурирован для роботы из ROM.При прогоне под симулятором выяснил, что eCOS виснет при вызове статических конструкторов( функция cyg_hal_invoke_constructors(), если не ошибаюсь). Вылечилось правкой файла линкера - перенос секций __CTORS__ и __DTORS__ в глубь секции .text.
Изменилось ли что нибудь с тех пор - не знаю.

А есть макрооопределение по поводу вызова конструкторов. Необходимость вызова определяется при конфигурировании.

Получилось запустить с дискеты на ПК. Установил "Startup type" в "FLOPPY" и тест запустился.
Но есть вопрос по конфигуратору. Например я хочу добавить в проект семейство функций, но как атоматически это сделать? Неужели только руками?

Что значит руками и какие функции? Я обычно делаю несколько конфигураций (под разные режимы - с отладкой и без) гуевым конфигуратором, потом - экспорт из него .ecm файла и создание шелл-файла, собирающего систему. Это - общая настройка, нужный темплейт, пакеты. А затем уже - тонкая настройка руками .ecm файла. И каждый раз - сборка системы, тестов, прогон.

В тестовой проге я работаю с функциями каталогов. В гуевом конфигураторе в "ISO C and POSIX infrastructure" ставлю галочку напротив "<dirent.h> definitions implementatiom header", собираю проект, компилю тестовую прогу. Вылезает ошибка, что нету объявления типа DIR. В документации написано, что параметры типа booldata, которым и является изменяемый мной параметр, это строка. Применимо к параметру "<dirent.h>", это, как я понимаю, путь к хедеру. Где его взять?