[Evgeny_CD 0]

********************** Где что берется **********************

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 (правда старый вариант, не B), 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

[Harbour 0]

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

 

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

 

1. Есть железо и в него нужно уложиться при любом раскладе.

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

 

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

[Evgeny_CD 0]

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

 

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

* MCF52xx

* LPC28xx

* LH7952x

 

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

 

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

[Evgeny_CD 0]

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

 

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

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

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

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

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

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

[Evgeny_CD 0]

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."

[v_shamaev 0]

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++) нету. А для меня это большой минус. Замечание по поводу возможности открыть в одном классе больше одной нити - весьма забавно. Видимо, стар я уже стал - в голову такой изощренный метод мазохизма не приходил никогда.

[Evgeny_CD 0]

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

Мои познания в С++ пренебрежимо малы. Но там вроде есть нечто на тему

rtems-4.6.99.3.tar.bz2\rtems-4.6.99.3\c\src\librtems++\src

[Harbour 0]

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" - у меня данное решение не набрало нужных баллов, может у Вас есть другие аргументы, охотно послушаем ;)

[Olej 0]

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

 

А в этом нет никакого мазохизма - об этом давно писали и Дэйкстра и Хоар (техника "мониторов Хоара", реализуемая прямо в синтаксисе некоторых языков ... да и рандеву 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) - его ещё нужно тщательно прорабатывать в каждом конкретном случае, прежде чем решиться.

Изменено 12 августа, 2006 пользователем Olej

[Evgeny_CD 0]

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

Мне пока трудно сказать, но по моему субъективному ощущению скорость и качество ответов на вопросы в лист для RTEMS и eCos сопоставимы.

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

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

 

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

 

RTEMS на AT91RM9200 имеет все базовые дрова: сеть, UART, I2C. Все остальное пишется "по месту" без проблем.

Далее - масштабируемость - рост мощности bsp подразумевает более крутые задачи - общая тенденция в мире конгломератов такова, что они масштабируемы до определенного уровня - потом начинаются проблемы. Т.е. оказывается проще добавить памяти и поднять uclinux, чем пытаться вытащить за уши (а это патчи, баги, проблемы с заказчиком и т.д.) в реальный мир многозадачности и разных сервисов встроенную ось.

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

 

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

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

 

Нет у них этого по макимуму и быть не может :

- в ip нет RTP и light UDP, которые так необходимы в телефонии

- уверен что mmap и прочая хренотень в FS не поддерживается

- чтобы пройти сертификацию на POSIX нужно много баков заплатить - за linux в свое время заплатили - как тут дело обстоит у rtems ?

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 мне вседа поможет.

[Harbour 0]

Насчет mmap - это Вы погорячились - его для систем без MMU делают только для удобства портирования - имелось ввиду что полного набора системных вызовов для VFS в embedded варианте не делают.

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

Удачи в освоении rtems !

[Evgeny_CD 0]

rtai я не продвигал, а просто сделал на нем несколько проектов и поделился в форуме соображениями по поводу целесообразности применения данного бесплатного продукта.

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

Насчет rtai пачей к rm9200 - нужно Вам спросить у них в mail-list'е

Подписался. Спросил.

[Владимир Е. Зюбин 0]

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

 

1. Есть железо и в него нужно уложиться при любом раскладе.

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

 

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

 

А еще есть категория задачи. Я вот стараюсь всегда от задачи плясать.

Что писать думаете, если не секрет? Что там за требования и какая специфика?

[Evgeny_CD 0]

Что писать думаете, если не секрет? Что там за требования и какая специфика?

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

 

* Собрали данные от датчиков - в том числе просреством "концентратора"

* Сняли "фотку". Вероятно, пока JPEG, потом JPEG2K, когда-нибудь и до MPEG4 AVC дорастем.

* записали звук - PCM64, GSM - "крутого" не надо.

* выдали звук - "оповещение"

* записали собранные данные на локальный носитель

* передали отселектированные данные по каналу связи (самые разные каналы - от Ethernet до GPRS)

* провели голосовой диалог с юзером, позвонившим на тлф. вход (DTMF диалог)

* оповестили голосом по телефону.

 

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

[v_shamaev 0]

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

 

А в этом нет никакого мазохизма - об этом давно писали и Дэйкстра и Хоар (техника "мониторов Хоара", реализуемая прямо в синтаксисе некоторых языков ... да и рандеву 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) - его ещё нужно тщательно прорабатывать в каждом конкретном случае, прежде чем решиться.

 

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

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