Собираем плату на арме и появился вопрос, что лучше использовать как ось?
Есть поддержка у:
Gentoo (на сайте про это почти ничего нет, последние обновления аж в 2005 году)

Debian
Нашел несколько документов. Все ставят toolchain и qemu.

Эти системы на ядре 2.6 используются чаще всего
по доке http://www.opennet.ru/base/sys/linux_xscale.txt.html , очень древняя дока. Написана в 2004...
патчи к ядру ftp://ftp.arm.linux.org.uk/pub/armlinux/s...l-patches/v2.6/ датированы 2004 годом, где тогда брать более свежие..

FreeBSD
"Поддержка всё ещё минимальна, и покрывает только процессор, шину PCI-X, Ethernet-адаптеры em(4), а также таймер и UART.
Обеспечивается минимальная поддержка процессора StrongARM 1100, однако только в границах тех функций, что эмулирует Simics: CPU, UART и часы."
http://www.freebsd.org/ru/platforms/arm.html
Очень негусто.

NetBSD
Тут вообще непонятно, как собирать. Разве что через qemu.

Какие вообще есть утилиты?

uclinux
Уже изначально версия под микроконтроллеры.. Но каковы особенности и через что собсно надо собирать систему под себя?

А вообще, копаясь в инете, у меня сложилось впечатление, что в 2004-05 годах тема была актуальна, а потом ее просто все забросили.. Одно старье.

Лично я выбрал Gentoo.
То что "последние обновления аж в 2005" - вы немножко не правы
Gentoo обновляется каждый день.

То что архивы стадии (stage1,2,3) не обновлялись, это не страшно.
emerge world - и у вас самый свежий gentoo

Забыли RTEMS.

Насчет FreeBSD нужно смотреть сюда http://www.embeddedfreebsd.org/, и у NetBSD дела с АRMом точно не хуже.

И есть еще eCOS

А где почитать, как ставить именно арм-версию?
Какие надо ставить портажи?


RTEMS users have built the toolset on many host operating systems but the RTEMS Project provides pre-built toolset binaries for the following development hosts:
GNU/Linux in RPM format
Cygwin as bzip'ed tar files
Solaris as bzip'ed tar files
In addition, FreeBSD provides "ports" for the RTEMS toolsets as part of their standard collection.

Интересная штука.. Надо будет попробовать.


http://www.embeddedfreebsd.org/building.html
NanoBSD, TinyBSD, m0n0wall. Это не совсем фря, а ее "отпочкования". Хоть и близкие к оригиналу..

Нету отзывов по линукс-версиям, там все так грустно? Генту не совсем линух, он сам себя ставит как нечто среднее между линухом и BSD.

А какие есть варианты сборки? Я так понимаю, если собираем особую версию ядра, единственный вариант -- зашить ядро с новой системой в устройство и только там запускать. Можно запустить в qemu, там собрать и отладить. Так?

Чего-чего, а Линукс-версий полнО. OpenWRT, Midge etc (MIPS), FloppyFW (x86). Под АРМ меньше значительно. Насчет запуска под qemu сейчас сильно интересуюсь.

Какая вообще разница между ОС реального времени и обычными? Что проще и надежнее?

ОС реального времени должна обеспечивать заранее известное время реакции на прерывание.
Windows и Linux не являются системами реального времени, так как могут заниматься своими процессами сколь угодно долго. Кроме того, Windows и Linux являются необозримыми системами, то есть даже опытный программист может никогда не разобраться в причине неработоспособности его программы под Linux.
ОС для встроенных систем следует применять только в случае крайней необходимости, например при использовании протоколов FTP/TCP/IP. При этом стоит использовать обозримые ОС с короткими исходными текстами, например uCOS-II.
Гарантию надёжности ОС вам не даст никто.
Почитайте лицензионное соглашение на любую ОС, даже бесплатную (обычно это соглашение никто не читает).
Там написано, что авторы ОС не отвечают за:
- потерю данных
- любой прямой и косвенный ущерб
- повреждение оборудования
- потерю коммерческой выгоды
и оказание технической поддержки пользователю/покупателю не влияет на ответственность авторов ОС.

Многие производители используют линух, тот же длинк в точках доступа.. Поэтому и есть альтернативные прошивки.
Получается, CiscoIOS тоже реального времени?

Cisco вовсю используют ядро QNX =) Камни у инх 64bit RISC (от pcm sierra, broadcom может еще какие...)
А что касается оси, то сам пытаюсь выбрать что-нибудь на AT91.

Начинаем пользовать uClinux. Собирается из под Linux. Собрать ядро из под Windows нахожу затруднительным. Расчитана на работу в процах без MMU. Ядро 2.4 само весит около метра. 2.6 - еще не пользовал, но в требованиях указан минимальный размер озу - 2 Мб.

Господа, а что-нибудь кроме RTOS и uCOS можете посоветовать на AT91?

Из свободных - eCos. Наиболее развитая из свободных средних осей - по количеству платформ, по масштабируемости и переносимости идеологии.

Ситуация с поддержкой AT91RM9200 несколько изменилась:

The FreeBSD/arm port has grown support for the Atmel AT91RM9200. Boards based on this machine are booting to multiuser off either NFS or an SD card. The onboard serial ports, PIO, ethernet and SD/MMC card controllers are well supported. Support for the SSC, IIC and SPI flash parts in the kernel will be forthcoming shortly.

In addition to normal kernel support, the port includes a boot loader that can initialize memory and boot off IIC eeprom, SPI DataFlash, BOOTP/TFTP and SD memory cards.

The port will be included in forthcoming commercial products.
Open tasks:

1. Add support for other members of the AT91 family of arm9 processors.
2. Finish support for AT45D* flash parts.
3. Finish support for USB ports
4. Write support for USB Device functionality

Взято отсюда: http://www.freebsd.org/news/status/report-...tmel-AT91RM9200

Все это так, но хочется дополнить. Win embedded реального времени все же есть, и зовеЦЦо она Windows CE.NET. А для линукс, я так понял, существует модуль превращающий (а вернее дополняющий) ядро в RTOS...

Советую eCos. Полно готовых портов. Простенькая ось и есть над чем поработать. Есть свой загрузочный модуль RedBoot, куча драйверов и др.

Soft-RT можно и на linux и winCE. Все зависит от задачи (и от выбранного камня). Если графика, сеть и прочие прелести не нужны - проще все сваять с нуля . Hard-RT с рюшечками (см. выше)- только с использованием доп.железа (FPGA и пр.). Если я не прав - коллеги поправят

TN Kernel
www.tnkernel.com

Есть ещё вариант - Unison RTOS
http://www.rowebots.com/
Доступна шаровая версия, но только в виде библиотеки

Извините за вопрос, а АРМ то какой ежели 7-й дак к нему из вашего списка, на сколько мине не изменяет склероз только uclinux подойдет, так как в 7-ке нету менеджера управления памятью, что и реализовано в оной. ежели 9-й то тогда милости просим к остальным, я на AT9260 ставил дебиан, ничего системка, правда для этого проца тяжеловатая, поэтому я тогда остановился на связке ядро линукса+busyBox - легковесная штука, грузится быстро, выполняет все что нужно + опыт по созданию работающей ОС с 0

Кто-нибудь пробовал испытывать Realtime патчи для linux? Интересует именно четкая работа с переферией, прерываниями (spi, i2c).
Я накладывал, но вываливалось kernel panic при работе с нестандартным драйвером, поэтому пока что отложил

А чем патчили если не секрет? Теми патчами что превращают ядро в ветку RT? Или чо другое есть? Или имеются в виду модули и либы а-ля posix-1b?

И что не так с SPI? Вот у Вас на компе PCI как на не RT системе работает? ЧОтко? Вся эта возня с RT-OS это "борьба" с планированием - т.е. постановкой процессов на выполнение/завершение. В жизни количество процессов стохастично, а время их запуска асинхронно. В обычных системах постановка большого количества задач на выполнение или обработка одной очень ресурсоемкой может вызвать неопределенную задержку. Система тормозит. А в RT-толко определенную. Система тормозит, но не более чем... . Все это для пользовательской части - обычных программ. В ядре правда несколько другие законы.

Тупой способ сделать RT в линуксе в условиях заводской лаборатории это написать драйвер аппаратного таймера(свой - чтобы точно понимать как он работает - я, например, не редко не могу понять чужой код с лету), а-ля вотчдог. Выбрать максимальный интервал затормаживания. Выбрать критичные к задержкам задачи. Вотчдог шлет сигналы по-ядру. Процесс в пространстве ядра (сделанный как драйвер - будет неивысший приоритет - никакими ренайсами не достижимый) читает структуру runqueue для каждого запущенного процесса. Как только время задержки относительно нашего таймера для критичных задач превышает 0.75 максимального времени, всем второстепенным программам шлется SIGKILL . Как вариант, если есть время листать книжки замазанными машинным маслом руками, длительная борьба с перепланированием - nice/renice или прямо в ядре вызовом соответствующей функции (Бовет-Чезати ст.347).

Но я сделал еще проще - и еще гораздо тупее. . У меня на платке точно известно количество задач. Я попробовал - ничего не тормозит. . Единственная связь - Ethernet. Шлю только UDP пакеты. В ноут по "проводу" 1м длинной . Это даже сервером не назовешь. Если у Вас Web-сервер - то, например, попробуйие отрабатывает ли он 20 соединений при максимальной нагрузке. Если да то поставьте ограничение на 10 - точно отработает. Вот и весь RT-Linux в домашних условиях . Недостаток такого подхода - далеко не 100%-ное выжимание ресурсов из процессора/памяти.

Просвещайтесь
http://www.ibm.com/developerworks/ru/libra...eal-time-linux/
а то у Вас какое-то однобокое понимание вопроса. Да - soft real time в Linux уже очень давно в основной ветке, я например всегда приимтивные ядра собираю.

а на каком?

Спасибо за ответ развернутый.
Патчили этим http://www.kernel.org/pub/linux/kernel/projects/rt/
После наложения патча в конфигурации ядра кроме CONFIG_PREEMPT появляется CONFIG_PREEMPT_RT.
После можно использовать утилиту "chrt" для изменения Realtime-приоритета процессу (либо использовать системные функции при компиляции). chrt помогает и без накладывания RT-патча.

Вообще задача такая: нужно получать прерывания от внешнего источника (с частотой 800 Гц ) и по ним обращаться к SPI, проделывать необходимые вычисления, обращаться к /dev/ttyS0. Работает но время между прерываниями болтается. В любом случае должен быть драйвер (для обработки прерывания) ввиде какого-то /dev/myinterrupt + пользовательский процесс в системе.