********************** Где что берется **********************
http://www.rtems.org/ - центральное место

RTEMS Users List Archive - с хорошим поиском!
http://www.rtems.org/ml/rtems-users/

Wiki - много всего интересного
http://www.rtems.org/wiki/index.php/Main_Page

Исходники, доки. Брать последний релиз 4.6.99.3. Тут же тулчейн лежит.
ftp://ftp.rtems.com/pub/rtems/

В последнее время часто возникают траблы с ftp (писал в лист - ISP что-то там с фаерволами намудрил). Альетрнативный вариант доступа
http://www.rtems.com/ftp
http://www.rtems.org/ml/rtems-users/2006/a...t/msg00036.html

********************** Обзор **********************
Исторически RTEMS была первой "взрослой" ОСью, на которую я обратил внимание. Но "дух *nix", которым от RTEMS веет основательно, несколько испугал меня.

Потом мое внимание переключилось на eCos - больше чисто "микроконтроллерных" фишек, и мне она в тот момент показалась более понятно и доступной. Теперь вот снова "вернулся".

Обзор и выводы ниже.

********************** История **********************
http://www.rtems.org/wiki/index.php/RTEMSReferences

Самая ранняя публикация - 1991 год. 15 лет - это уже история!

********************** Докумнетация **********************
Входит в дистрибутив. Та, что на главной странице сайта - устарела.

Доки достаточно много, и она вполне качественная.

Код - саму ОСь не смотрел; смотрел много портов - код простой и качественный, неплохо откоментированный. Чем-то стиль исходников BSD напоминает.

********************** Реальность RT **********************
###
http://www.slac.stanford.edu/econf/C011127/WEBI001.pdf

Видно, что при использовании native API реальное время остается вполне реальным даже при сильной загрузке системы.

MVME2306 - информация о том, что это за плата
http://www.innovative-research.com/manuals...ME2308-spec.pdf

MPC604 - процессор на этой плате. 300 Мгц - не более 500 MIPS.
http://www.freescale.com/files/32bit/doc/d...heet/MPC604.pdf

####
http://www.rtems.org/wiki/index.php/CPR-041
In the SCADA industry that this processor was designed for, time stamping of event information is critical. We require millisecond accuracy for events in the system. We run RTEMS with a 1ms clock tick, but we also have a mirosecond counter (between ticks) for precise calculations

!!! We have to time synchronise all processors in the network to within 500us on the Arcnet interface so a fast low-latency RTOS was required.

The CPR-041 is based on the Coldfire 5307
Процессор - 70 MIPS at 90 MHz
http://www.freescale.com/webapp/sps/site/p...sp?code=MCF5307
Далеко не самый быстрый процессор. И то, что они достигли таких временных характеристик - говорит о многом.

###
Zetron Simulcast Paging System - родное для меня
http://www.rtems.org/wiki/index.php/Zetron...t_Paging_System

The Zetron High Speed Simulcast Paging System (http://www.zetron.com/pages/english/products/m600.html) consists of one M600 unit and multiple M620 units. Both the M600 and the M620 use the RTEMS operating system running on a Motorola MPC860.

Zetron's High Speed Simulcast Paging System employs a single Source Unit (Model 600 Wireless Data Manager) and multiple (up to 1000) Destination Units (Model 620 Wireless Data Encoders). The units are all equipped with GPS receivers, and their time base is synchronized to within 1 microsecond. This is a complicated system with multiple units transmitting the same data from multiple sites, and the bit edges from each transmitter are aligned to within +/- 500ns (using a GPS receiver at each site for time reference). The bit alignment is done using RTEMS-managed interrupts and the 860's onboard timers.

Процессор MPC860 - тоже далеко не самый быстрый камень.
http://www.freescale.com/webapp/sps/site/p...jsp?code=MPC860
Embedded MPC8xx Core with 88 MIPS at 66 MHz (using Dhrystone 2.1); MPC860P - 106 MIPS at 80 MHz for the MPC860P

### в комплект RTEMS входит test suite, который позволяет протестировать все временные характеристики на целевой платформе при наличии одного свободного таймера.

###
В общем, можно смело говорить о реальности реального времени RTEMS в пределах десятков мкс для 100+ DMIPS процессоров.

Это дает возможность "похулиганить" - вместо написания полноценного драйвера пишется обработчик ISR, который взаимодействует через IPC (Inter Process Communication) со "спящим" процессом. Вся работа с периферией идет из обычного процесса - MMU нам не мешает. RTEMS поддерживает MMU, но не использует его.

********************** POSIX'овость, стандарты **********************

В моем понимании, RTEMS гораздо более POSIX, чем eCos.

http://www.rtems.org/wiki/index.php/Standa...upport_By_RTEMS

With the addition of file system infrastructure, RTEMS supports approximately 80% of the POSIX 1003.1b-1996 standard. This standard defines the programming interfaces of standard UNIX. This means that much source code that works on UNIX, also works on RTEMS.

RTEMS includes a port of the FreeBSD TCP/IP stack and thus supports BSD sockets. It also includes support for numerous networking clients (DHCP, TFTP, NFS, etc.) and servers (FTPD, HTTPD, etc.).

Есть порт стандарного PPPd.

Есть вообще много разного софта, портированного под RTEMS. В честности, NFS client. Это очень удобно для отладки.

RTOS State of the Art Analysis - очень интересный обзор
http://www.ocera.org/archive/deliverables/...6/WP1/D1.1.html
http://www.ocera.org/archive/deliverables/....1.html#AEN2041

RTEMS executive does not implement multiprocess environment with separated application address spaces. As a result, next functions supporting independent process creation and deletion are not implemented: fork(), execl(), execv(), execle(), execve(), execlp(), execvp(), pthread_atfork() and wait().

RTEMS executive is focused on multithread applications and its Task Manager supports full set of functions in classic and POSIX API. Cancellation functions are implemented by Cancellation Manager.

RTEMS implements all standard POSIX 1003.1b IPC mechanisms for concurrent threads synchronization and communication.

Interrupts are not converted to signals or other asynchronous events. They are handled by any C routine which was connected to the given interrupt vector. An interrupt handler can be established by any normal thread, kernel driver is not needed.

###
Программеры из http://www.nsg.ru/ говорили мне о том, что им удавалось портировать под RTEMS серьезные Unix софты с минимальным "перехаком". А они на RTEMS собаку съели - она долгое время использовалась у них в маршрутизаторах (сейчас, правда, они перешли на Linux). NSG долгое время висела на сайте RTEMS в списке главных контрибуторов.

********************** Файловая система **********************

In-Memory FileSystem (IMFS). The IMFS is a full featured POSIX filesystem that keeps all information in memory.

Есть хорошая дока. Описано, как писать порты любых FS для RTEMS.

Есть некий FAT16/32 (без lfn). Вроде как есть дрова для IDE и CF.

То, что только RAM - не здорово, но при нынешних ценах (32М - 3...5$, 64M - 6...10$) пережить можно. А вот то, что это POSIX по полной программе (mount/unmount и т.д.) - это здорово!

На первое время можно похулиганить: взять efsl, запустить ее как отдельный процесс, и синхронизировать содержимое носителя с RAM FS.
http://sourceforge.net/projects/efsl/
http://www.efsl.be/

###
YAFFS (YAFFS2)
http://www.aleph1.co.uk/node/344
http://www.aleph1.co.uk/node/129 - портирование
http://www.aleph1.co.uk/node/127 - портирование
http://www.aleph1.co.uk/node/130 - многопоточность

Простая и эффективня файловая система. Полагаю, будет совсем не сложно прикрутить ее к RTEMS.

********************** Базы данных **********************
### Berkeley DB
http://dev.sleepycat.com/

Вся работа с ОСью вынесена в отдельные директории. При сборке для *NIX используются automake, autoconf.

Конфигурируется очень гибко. Скорее всего, удастся собрать с разумными усилиями.

********************** Графика **********************
http://www.microwindows.org/

Есть качественный порт для RTEMS 4.6.

********************** Toolchain **********************
Все построено на automake, autoconf. На первый взгляд, кошмаристо. Но если упереться рогом, и "прорюхать" эти automake, autoconf - то все остальное будет уже просто.

Тулчейн используется свой, GNU, слегка пропатченный. Лежит на FTP.

!!! Очень интересно !!! Народ умудрился собрать тулчейн под Win32 без Cygwin DLL (используя MinGW),
http://www.rtems.org/wiki/index.php/MinGW_Tools_for_Windows

и вроде как все это работает!
http://www.rtems.com/ml/rtems-users/2006/a...t/msg00000.html
"I have built a m68k multilib RTEMS on Windows with the tools in a cmd box."

В скором времени обещаны скрипты, чтобы можно было весь процесс из-под VS запустить!

Одно но - automake, autoconf нужно использовать либо Cygwin, либо MSYS (часть проекта MinGW) версии этих тулзов
http://www.mingw.org/download.shtml

Таким образом, вырисовывается следующая среда для разработки:

* написание софта в красивой виндузятной IDE (на тот случай, если с VIM не удастся "сростись")
* "тестовая" (поиск тупых ошибок) компиляция в Win32 версии компилера из-под IDE
* окончательная сборка проекта под Cygwin или даже VmWare-Linux
* дебаггинг - под Cygwin или VmWare-Linux

###
Building RTEMS for the ColdFire with Cygwin/WinNT
http://sca.uwaterloo.ca/coldfire/ftp/david...rting-rtems.htm

********************** Симуляторы **********************
http://www.rtems.org/wiki/index.php/Emulator - подробно все расписано

### http://www.skyeye.org/

Порт RTEMS для edb7312 (отладочная борда для Cirrus EP7312) успешно работает в симуляторе:

http://www.rtems.com/ml/rtems-users/2005/d...r/msg00156.html
http://www.rtems.com/ml/rtems-users/2006/j...y/msg00041.html

### SID http://sourceware.org/sid/

Есть такой документ:
eCos and SID on ARM PID target HOWTO
http://www.asisi.co.uk/ecos_sid.html

Порта RTEMS для PID7T нет (древняя отладочная плата от ARM; атиквариат - даже доки на плату не найти), но, полагаю, на основе этого документа можно запустить RTEMS на SID (это будет не просто).

### http://www.slicer.ca/coldfire/ - Motorola ColdFire emulator

По сообщению Victor V. Vengerov работает!
I have got mcf5206elite BSP running on this simulator today.
http://www.rtems.com/ml/rtems-users/2006/j...y/msg00060.html

### Синтетические порты

Для Unix - есть. В доке где-то упоминается, что чуть ли не под Cygwin синтетический порт можно запустить.

********************** Удаленная отладка **********************
GDB через COM или Ethernet.

По Ethernet отладке - наиболее хорошо она проработана для 68K/ColdFire и PPC
http://www.slac.stanford.edu/~strauman/rtems/gdb/index.html

********************** Консоль **********************

Среди всякого софта для RTEMS на сервере есть некое подобие консоли и Telnet сервер. Набор команд там не шибко большой, но эту прогу можно использовать в качестве образца при написании своих приложений, которые тестовый printf/scanf через IP делают.

********************** Порты **********************
Из наиболее интересных портов:

* AT91RM9200
* AMD Au1100, 1500
* Cirrus EP7312
* MCF5206e, 5272, 5282, 5235
* MPC5200 (правда старый вариант, не , PPC403, PPC405.
* пЫсюк, понятно, тоже не забыт

Т.е. все стратегически интересные камни на месте. Нет портов на новые и очень интересные ColdFire (5208, 5270) - но они не сильно от 5282 отличаются - полагаю, можно перехачить с разумными усилиями.

********************** Автоматическое тестировние софта **********************

Рассмотрим вариант с AT91RM9200.

Есть замечатальня "народная" плата Электроникс
http://electronix.ru/forum/index.php?showforum=139

Есть не менее замечательная плата от dch EVM9200
http://www.ucrouter.ru/hardware.html

На плату Электроникс COMA поставил Linux
http://electronix.ru/forum/index.php?showtopic=17534

В процессе этого геройского поступка на плату "поставился" U-Boot. А он умеет сам по TFTP грузить с хост машины образ и запускать его.

В результате получаем полностью автоматическую систему тестирования на реальном железе без "крутых" JTAG за много килобаксов

* собрали проект
* обресетили плату
* U-Boot загрузил и запустить образ
* Через сокеты взаимодействуем с нашим test suite.
* "repeat untill передохнут"

Подробнее:
TDD (Test-driven Development) применительно к embedded системам: похоже, я догнал, как это должно быть устроено.
http://www.caxapa.ru/echo/arm.html?id=63285
http://electronix.ru/forum/index.php?showtopic=18859

Развитие идей по упрощенной отладке.
http://www.caxapa.ru/echo/arm.html?id=63474
http://electronix.ru/forum/index.php?s=&am...st&p=136520


********************** Скриптовые языки **********************

На сервере лежат следующие порты:

* TCL 8
* Python 2.4

LUA нет, но учитывая POSIX'ность RTEMS - полагаю, больших проблем не будет.

********************** Вывод **********************

Есть uCOS - все просто и понятно.

Есть Linux - популярно, но не шибко понятно (мне) и сильно не просто (для меня) - если дрова писать и отлаживать.

Есть eCos. Много о ней писали. Если бы был открытый и доступный порт на AT91RM9200 и ColdFire - больше бы ничего не искал.

Есть RTEMS. Самый большой кайф - это, вне всякого сомнения - отлаженное ядро и базовые сервисы типа RAM FS и IP стек. И самое сложное при освоении этой оси будет сделать первый "hello, world!" на консоль.

В некотором смысле выборе между uCOS и RTEMS - это как выбор между асм и С.

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

А фундаментльное отличие от uCOS состоит в готовых сервисах операционки - Pthreads всякие там и пр. Т.е. можно комбинировать толстые и тяжелые софты, рассчитанные на POSIX, с достаточно простыми самописными "модульками", обслуживающими периферию в реальном времени.

RTEMS также можно рассматривать как ступеньку в подготовке на пути к Embedded Linux. Освоив RTEMS, разобравшись с этими automake, autoconf, потом почти наверняка будет куда проще "по-взрослому" с линухом разобраться.

С автоматическим тестированием все тоже хорошо получается. Поскольку все серьезные современные камни имеют встроенный Ethernet, то, как я писал выше, можно сделать полностью автоматический test suite без особых материальынх усилий (только как следует разобраться с уже существующими софтами).

Судя по всему, RTEMS очень хорошо подходит для "трехслойной идеологии"

* ASM, дрова
* C, RTOS
* "обобщенные сущности" как процессы под RTOS, скриптовый движек.

Об этом будет пост чуть позже.

********************** Вопросы **********************

Есть кто живой, кто с RTEMS работал? Может я чего плохого не нашел в этой ОСьке?

********************** Приложения **********************
### Omni-NFS Enterprise

* NFS сервер
* NFS клиент
* FTP сервер

http://www.xlink.com/download/d_page/enter2k_demo.htm

Omni-NFS Enterprise for Windows 2000/2003/NT/98/95/ME/XP

Ссылки для скачивания:
Version: 5.2
Platform: Win 2000/2003/NT/9x/ME/XP
File Name: nfse2k.exe
File Size: 6,056 KB
ftp://ftp.xlink.com/pub/xlink_demo/nfse2k.exe
ftp://ftp.xlink2.com/pub/xlink_demo/nfse2k.exe

Клизьмы водятся в изобилии http://astalavista.box.sk/

### GNU Autoconf, Automake, and Libtool
By Vaughan, V. Gary, Ben Elliston, Tom Tromey, Ian Lance Taylor

Publisher : New Riders Publishing
Pub Date : October 06, 2000
ISBN : 1-57870-190-2
Pages : 432
Slots : 1.0

Качать:
http://rapidshare.de/files/28613880/GNU.rar.html
http://upload.caxapa.ru/GNU.rar
Пароль:
hgfdyufdtffytc

Мое IMHO - нужно разделить категории применения "конгломератов" (rtems/ucos/ecos/и т.д.) и embedded OS (uClinux/etc.) - т.е. нефиг все мешать в одну кучу - есть приложения когда 32k озу/50 MIPS, есть когда 32Mb/200 MIPS - при всем желании получить универсальное масштабируемое решение ничего не выйдет - придется вести два разных по архитектуре проекта. Далее, интересует конкретная сравнительная аргументация аля rtems и остальные сильные игроки на данном поприще - ThreadX/TNTKernel/Ucos/etc: по фишкам/памяти/поддержке/тестам - наблюдаются бестолковые сравнений RTEMS с Linux, но с таким же успехом можно сранивать ее и с QNX.

По мне есть две категории проблем:

1. Есть железо и в него нужно уложиться при любом раскладе.
2. Есть задача - и под нее готовы сваять любое железо (в пределах разумного)

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

Прошу прощения за некоторую сумбурность изложения.

Спектр решений, которые я хтел бы покрыть RTEMS - это 60+ MIPS/8+ Mbyte SDRAM. Т.е. это:
* MCF52xx
* LPC28xx
* LH7952x

и более мощные чипы.

Насчет конкретной аргументации по RTEMS - пока не возьмусь приводить, только начал тщательно вкуривать доку.

Чуть более точная формулировка:

* RTOS не покупная за много килобаксов для линейки контроллеров
* от описанного выше минимума до MPC5200, PPC405
* простая в освоении
* с возможность работы с крос тулзами из-под виндов
* IP, FS, POSIX по максимуму.
* долгоиграющая - чтобы жила 10+ лет, и через 10 лет не выглядела жутким анахронизмом

RTEMS на AT91RM9200 - полет нормальный!

http://www.rtems.org/ml/rtems-users/2006/a...t/msg00044.html

"We have successfully been using RTEMS for AT91RM9200 on our 'own' boards for more than a year now. The best way to debug your AT91RM9200 is via JTAG and BDI2000 - debugger. BDI2000 will also allow you to program your FLASH. We are using UBOOT for loading RTEMS via DHCP/TFTPBOOT from a Linux-host."

Плюсов (C++) нету. А для меня это большой минус. Замечание по поводу возможности открыть в одном классе больше одной нити - весьма забавно. Видимо, стар я уже стал - в голову такой изощренный метод мазохизма не приходил никогда.

Мои познания в С++ пренебрежимо малы. Но там вроде есть нечто на тему
rtems-4.6.99.3.tar.bz2\rtems-4.6.99.3\c\src\librtems++\src

Ok, проведем простой тест :

: RTOS не покупная за много килобаксов для линейки контроллеров

Насчет килобаксов - это зря, support нужен сразу как только напишется первая сотня строк кода, и тут пока два выхода - или есть хорошо изученная и бесплатно поддерживаемая система или энтот саппорт приобретен. rtems по сравнению с ecos/uclinux является более скромной в количестве пользователей, и как я понял Вами еще не применялась. Покупать support, даже если он есть Вы не собираетесь - ставим "-1" по даннному пункту.

: от описанного выше минимума до MPC5200, PPC405

Пересмотрев 16 разных осей под ARM, я отметил одну тенденцию для бесплатных one - обычно они имеют generic порт основных своих ф-ий - т.е. разработчик сам затачивает ось под конкретный девайс и свою среду разработки, также пишет сам все драйвера для него и для bsp. Исключения составляет только ecos (обьяли ребята необьятное) и ethernut - которая имеет довольно стройную архитектуру (аффтару respect за эстетизьм). Похоже что окончательно портировать rtems придется самостоятельно.
Далее - масштабируемость - рост мощности bsp подразумевает более крутые задачи - общая тенденция в мире конгломератов такова, что они масштабируемы до определенного уровня - потом начинаются проблемы. Т.е. оказывается проще добавить памяти и поднять uclinux, чем пытаться вытащить за уши (а это патчи, баги, проблемы с заказчиком и т.д.) в реальный мир многозадачности и разных сервисов встроенную ось.
В общем здесь я бы поставил "-1" - rtems не имеет законченных портов и вопросы масштабируемости неясны.

: простая в освоении

Здесь "+1" - есть доки, примеры, есть mail-list и т.д.

: с возможность работы с крос тулзами из-под виндов

Это имеют все оси - "0"

: IP, FS, POSIX по максимуму.

Нет у них этого по макимуму и быть не может :
- в ip нет RTP и light UDP, которые так необходимы в телефонии
- уверен что mmap и прочая хренотень в FS не поддерживается
- чтобы пройти сертификацию на POSIX нужно много баков заплатить - за linux в свое время заплатили - как тут дело обстоит у rtems ?

"-1"

: долгоиграющая - чтобы жила 10+ лет, и через 10 лет не выглядела жутким анахронизмом

Чтобы данное требование выполнить нужно чтобы ось шла в ногу со временем - появлялись порты под актуальные камни, улучшалась архитектура - т.е. необходимо проследить темпы и качество развития данной оси за последние N лет. И потом прогнозы - это темная лошадка - никто и ничего гарантировать в нашем зыбком мире не может - "0"

"-1" + "-1" + "+1" + "0" + "-1" + "0" - у меня данное решение не набрало нужных баллов, может у Вас есть другие аргументы, охотно послушаем

А в этом нет никакого мазохизма - об этом давно писали и Дэйкстра и Хоар (техника "мониторов Хоара", реализуемая прямо в синтаксисе некоторых языков ... да и рандеву Ada - нечто из этого сорта)... В развитии языков школы Вирта: Oberon, Zenon ... туда, куда она пошла от Pascal/Modula - это даже имеет термин "активный объект" и есть у них целой идеологией...
Можете глянуть здесь, в более общем виде:
http://qnxclub.net/modules.php?name=Forums...wtopic&t=64
http://qnxclub.net/modules.php?name=Forums...wtopic&t=13
А здесь в упрощённой реализации для решения частной задачи:
http://qnxclub.net/modules.php?name=Forums...topic&t=315
http://qnxclub.net/modules.php?name=Forums...topic&t=317

А по поводу С++, да ещё для "низовой" ниши изделий - то это ещё вопрос... за счёт ресурсоёмкости полученного ПО (в сравнении с pure C) - его ещё нужно тщательно прорабатывать в каждом конкретном случае, прежде чем решиться.

Мне пока трудно сказать, но по моему субъективному ощущению скорость и качество ответов на вопросы в лист для RTEMS и eCos сопоставимы.Я пока еще не видел порта eCos, в которым были бы все дрова для конкретного камня. Например потому, что есть "стандартные дрова" - Ethernet, UART - они, как правило, есть; а для того же SPI дрова могут быть сильно разыне - простые; с очередями транзакций - это если несколько процессоов командуют несколькими устройствами на SPI шине и т.д.

Кроме того, бывает еще ПЛИСИны и прочая custom периферия. Так что процесс дровонаписательства осваивать надо по любому.

RTEMS на AT91RM9200 имеет все базовые дрова: сеть, UART, I2C. Все остальное пишется "по месту" без проблем.Абсолютно согласен, для каждой оси есть оптимальный "динамический диапазон" применений. Все от задач зависит - лично для моей линейки контроллеров RTEMS на первый вгляд хватит.

Вероятно, было бы очень круто уметь переписывать керел Линуха при "жесткой оптимизации" конкретных проектов - тогда можно было бы *Linux/*BSD выбрать в качестве стандарта форЁва (размер памяти до 32М меня слабо волнует) - но я такого пока не умею, и сильно не уверен, что когда-то научусь.RT применительно к IP меня (пока?) не колышит. Так что ничего сказать не могу.

Насчет mmap также бессилен ответить - ради интереса задал вопрос в лист.

Сертификация оси меня пока не сильно волнует - для моих задач не просматривается необходимость в ней.

Разумеется, я в очередной раз испытываю смущение от RTAI - Вы успешно "продвигаете" его. И меня подмывает разобраться - а может и правду замечательная штуковина? Точнее, в том, то она замечательная, я не сомневаюсь Я сильно сомневаюсь в том, что смогу в ней разобраться за осмысленное время.

Например, я пока нигде не видел готового кернела на AT91RM9200 с RTAI. Вы говорили, то патч есть довольно давно - но я пока не слышал массовых отзывов о таком. Смотрим сайт https://www.rtai.org/
* ARM (StrongARM; ARM7: clps711x-family, Cirrus Logic EP7xxx, CS89712, PXA25x) Что-то там 9200 не упоминается - очень странно, весьма и весьма популярный контроллер.

Если бы был какой-нибудь гуру под рукой - я, вероятно, взялся бы за освоение RTAI. Но пока я испытываю внутренний страх перед Linix и иже с ним. eCos, RTEMS мне кажутся куда проще и понятнее. Понятно, что это глюки психологии - но ничего не могу с собой поделать.

В принципе можно, конечно, на EP93xx уйти - RTAI для них точно есть, недорогих евал бордов хватает, но Atmel как-то роднее, ColdFire очень перспективно по соотношени. цена/качество ...

В чем вся прелесть eCos и RTEMS - я всегда могу писать код "с оглядкой" на uCOS. Т.е. если мне не нужно ничего особо крутого - я всегда могу сделать downgrade проекта и запустить его под uCOS. В общем-то меня это успокаивает. Если сделать некое подобие OS Abstraction Layer - то можно писать инвариантно по отношению к оси (базовые примитивы мультитаскинга).

У eCos есть Ecoscentric, которая с одной стороны - залог долгого и успешного существования этой ОСи, а с другой стороны, старательно подгребает под себя все самое интересное - те же порты на AT91RM9200 и ColdFire. Я не готов пока купить порт и тулзы у центриков за 2.5 килофунтов.

Резюме:

* Linux, uClinuix, BSD - правильные и замечательные ОСи
* RT при помощи стандартных средств, достижимое в этих осях, будет во многие разы хуже RT eCos, RTEMS.
* RT на уровне кернел хака *nix будет, вероятно, вполне сопоставимо с RT eCos, RTEMS - но я не чувствую в себе сил стать "kernel хакером"
* RTAI - все уже сказал
* я испытываю некоторый сдержанный оптимизм по поводу LPC28xx и еще больший оптимизм по поводу грядущих LPC23хх в PQFP208. Т.е. "мелкопоганистый" BGA LPC28xx сильно портит малину, но с другой стороны 10$ за камень с кешем и 1М FLASH внутри - очень привлекательно (защита и все такое). uClinux, Linux в 1М, вероятно, можно впихнуть - но они будет так обрезаны, что о стандартах там и говорить не придется. В конце концов, можно сделать универсальную "плату ядра" и разориться на ее заказ в Китае (там же можно и долбаный безсвинцовый BGA 0.5 запаять).
* еще больший оптимизм я испытываю по поводу ColdFire - особенно когда MCF5208 выйдет. Я уже много писал на эту тему. А тут RTEMS вне конкуренции - там 68k/ColdFire - самый любимый порт.
* Ну а качестве топового решения меня просто распирает отптимизм от MPC5200B. RTEMS имеет "базовый порт" на 5200 (не Б) - и это хорошая стартовая точка. Горазо лучше, чем отсутствие чего бы то ни было для 5200 в eCos (хотя eCos имеет очень качественный порт PPC405; базовый порт для этого камня есть и в RTEMS). Особенно сейчас, когда на B версию обещаны цены чуть ли не 30$ здесь (слава интелю и AMD, наконец-то отваливших с embedded рынка - понятно, что после этого FreeScale приударила)!

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

* ultralite - наидешевейшие решения - LPC28xx, LPC23xx, цена на уровне "народных" LPC21xx /AT91SAM7S
* lite - MCF5208
* regular - AT91RM9200, MCF старшие
* pro - MPC5200B

Ну а если "наверху" мне чего-то не хватит - всегда могу уйти на MPC5200 Linux - http://www.denx.de мне вседа поможет.

Насчет mmap - это Вы погорячились - его для систем без MMU делают только для удобства портирования - имелось ввиду что полного набора системных вызовов для VFS в embedded варианте не делают.
rtai я не продвигал, а просто сделал на нем несколько проектов и поделился в форуме соображениями по поводу целесообразности применения данного бесплатного продукта. Насчет rtai пачей к rm9200 - нужно Вам спросить у них в mail-list'е - там какие-то ARM движения постоянно происходят - за неимением интереса я за ними не слежу, так помню что народ там бегал с какими-то патчами, что-то тестил.
Удачи в освоении rtems !

Слово "продвигал" я использовал почти как комплимент . Большое спасибо, что обратили внимание на эту интересную технологию.Подписался. Спросил.

А еще есть категория задачи. Я вот стараюсь всегда от задачи плясать.
Что писать думаете, если не секрет? Что там за требования и какая специфика?

На первый взгляд - ничего не обычного. Линейка контроллеров.

* Собрали данные от датчиков - в том числе просреством "концентратора"
* Сняли "фотку". Вероятно, пока JPEG, потом JPEG2K, когда-нибудь и до MPEG4 AVC дорастем.
* записали звук - PCM64, GSM - "крутого" не надо.
* выдали звук - "оповещение"
* записали собранные данные на локальный носитель
* передали отселектированные данные по каналу связи (самые разные каналы - от Ethernet до GPRS)
* провели голосовой диалог с юзером, позвонившим на тлф. вход (DTMF диалог)
* оповестили голосом по телефону.

Просто я хочу, чтобы все версии софта собирались из единого репозитория, и чтобы не было никакой лишней работы - т.е. если у меня есть функция send_mms() - то она едина для всех устройств, и баги в ней фиксятся (или вносятся новые ) в одном месте.

Спасибо за интересный ресурс - теоретические вопросы меня в данный момент не сильно интересуют, а вот более близкие к реальности проблемы - любопытны.
Хотя в основном обхожусь одной ниткой на класс, иногда бывала потребность породить несколько. Но вот безопасность (устойчивость) такого фокуса - хорошо бы продумать применительно к конкретной оси (и C++). А что касается плюсов применительно к встраиваемым приложениям под eCos - вполне приемлимо, утяжеления по отношению к pure С - почти не заметны. А задача, с форточками - к объектности сама стремилась, у меня недостало сил ей препятствовать.

Нашлась хорошая база данных под RTEMS - FastDB

RTEMS port
http://www.rtems.com/ml/rtems-users/2006/a...t/msg00061.html

www.fastdb.org
www.garret.ru/~knizhnik/fastdb.html
knizhnik[псина]garret{точка}ru - autor's mail

Я списался с автором - проект успешно развиается.

Native Win32 тулчейн для RTEMS: окончательная версия готова!

The web page for MinGW tools is here:

http://www.rtems.org/wiki/index.php/MinGW_Tools_for_Windows

The download directory can be directly accessed from here:

ftp://www.rtems.org/pub/rtems/windows/

Туманно... Просматривается что-то типа систем идентификации (от глобальных СОРМ , ФСБ, до пропускные системы, подъездные двери)... непонятна архитектура системы, аппаратная платформа и стоимость решения, на которую ориентируетесь. Тут и Виндовоз может подойти... типа CE... или вообще, что-нибудь типа LabView + (Win/Linux).

А что конкуренты используют?

Нет, все должно быть embedded и необслуживаемо. Так что пЫсюковщина идет лесом.Либо вообще ничего (нет аналогов), либо ненадежные пЫсюковые решения.

Владимир Е. Зюбин, что скажете по поводу

http://electronix.ru/forum/index.php?s=&am...st&p=144275

А по стоимости? Просто "пЫсюковщина" - это непонятный аргумент... есть же разные модификации для платформы... тем паче, что Х86 на половине ПЛК стоит... где-то с досом, а в последнее время просто с Win CE. Есть такая тенденция. Мультимедиа и все-такое прочее для работы в режиме 24х7, вроде как альтератив не много...



А какие требования по надежности?

Я просто хочу отделить мух от котлет и понять, где тут технические аргументы, а где одни эмоции...

Скажу следующее:
nesC мне уже встречался. Как и несколько других диалектов Си, которых не так уж и мало.
nesC разрабатывался как язык проектирования операционных систем (TinyOS), со всеми вытекающими:
асинхронность обработки прерываний, полный доступ ко всему железу, обмен сообщениями. В общем полноценное средство работы с железом.
Язык Рефлекс на это не претендует. Ориентация - на алгоритмы управления, работа ведется в унифицированном пространстве, требуются библиотеки (создающие унифицированное пространство). Синхронность исполнения... ну и т.д.

если кратко, то принципиально разная ориентация языков (nesC и Рефлекс) "разбрасывает" эти языки в разные непересекающиеся области... а в общем nesC - оригинальный язык, с интересным подходом, ориентирован на создание системного ПО, возможно для распределенных архитектур.
Как они сами заявляют
"The nesC language is primarily intended for embedded systems such as sensor networks."
Применительно к Вашей задаче: стека TCP/IP, библиотек для работы с мультимедиа я ничего не нашел. Может и есть. Первое наверняка есть,а вот второе под сомнением.

Спасибо, очень ценно Ваше мнение.

Насколько я понял, весь инструментарий nesC крутится вокруг AVR, посему о мультимедии там говорить не очень приходится.

Что касается основной темы этой ветки - RTEMS и "толстых контроллеров". Мне достаточно трудно описать задачу в терминад пЫсюка, ибо там она потребует больших ресурсов из-за неоптимальной архитектуры.

Я же планирую сделать гибкую конфигурируемую систему, где все RT задачи выполняются действительно RT, лучше всего на специализированных сопроцессорах, а медленные задачи управления крутится под "большой осью".

Например - надо мне снять MPEG4 AVC ролик в 2 минуты, как и кто входил на склад. Ставить DSP? А нафига!!! Смотреть ролик будут off-line, через много часов. Я делаю серию кадров, "полуаппаратно" (DMA продвинутое) загоняю ее на SD карточку (скорости несколько мбайт/сек получаются без проблем, цена на 1Г карточку менее 100$), а затем неспеша программно пережимаю во что угодно. 100 Мгц ColdFire хватит за галаза.

RTEMS привлекательна тем, что с одной стороны это POSIX, и возможость портирования стандартных приложений, а с другой стороны - неплохой RT, гораздо лучше чем у линуха.

Также она привлекательна наличием готовых портов на ColdFire.

Загляните сюда, может покажется интересным:
http://www.exponet.ru/exhibitions/online/s...ignatek.ru.html

там про аудио написано, но, насколько знаю, они и с видео дело имеют, внутри ТэМээСы,
телефон здесь:

Ремель Иван Генрихович, ИАиЭ СО РАН, (383)3307827.

... и, слышал, подобных систем на рынке несколько.

Спасибо!

Рекомендую обратить внимание на DaVinci от тексаса. И сопроцессор и проц для общих дел.
MPEG4 крутит, и ресурсов остается большой вагон и много маленьких тележек (даже с учетом того что на стороне арма стоит уже линукс).

Спасибо за информацию, но я о другом.

DaVinci - взрослая штука во всех отношениях. И тулзы для нее нужны взрослые. И цена на камень (и печатку под его BGA) будет тоже не "недетской". Это здорово, что он все это отправдает.

Кстати, "крутить" - это одно, кодировать - это другое. Для MPEG4 AVС в реальном времение надо монстров типа DM640.

Я же описал совсем другой подход - если допустимо "нереальное" время (например, 1:10, а то и 1:100, то берем http://www.xvid.org/ или http://ffmpeg.sourceforge.net (http://ffmpeg.mplayerhq.hu/), слека хачим (но ОСь должна быть хотя бы отчасти POSIX - иначе хачить устанем, RTEMS самое то!) и получаем результат существенно более простыми средствами.

Для нереального времени можно портировать (спасибо за линки).

Но перенести это на ДСП чтобы кодирование on-line - это нереально за реальные деньги (мое личное мнение).

Давинчи - это продолжение (улучшеная версия) 640 + АРМ9 на борту.
Крутит - это я имел в виду то что он кодирует (H264 BP, D1, 25fps) (загружает ДСП процентов на 40%).
Может и кодировать и декодировать "одновременно" - тогда 90%.
АРМ загружен на 5-15%.

Правильно! Именно, что инструментарий + либы для MEG4* - это 50k$+ как минимум. Соотвественно, единственный выход - сделать перву версию off-line, заработать на ней денег, сделать on-line версию.Спасибо! Я не разбирался детально - полумал, это развитие "простых" омапов.

Кстати, есть достаточно недорогие MPEG4* либы для тримедии (<10k$).