Есть плата процессора используемая в составе контроллера формата MicroPC. Нужно определиться с наиболее подходящей реал-тайм ОСью. Процессор класса Pentium 300 мГц, RAM 32 Мб, HDD - CompactFlash 512 Мб, СОМ, Ethernet, VGA, USB. При старте стартует BIOS который запускает систему с CompactFlash. ОСь должна позволять писать-отлаживать программу на целевой плате. Т.е. На этоту плату процессора поставил ОСь, компилятор, подключил клаву и пишу. Причём при отладке должен ставить точки останова, трассировать по шагам. Т.е. работать как за обычной ЭВМ. Графический режим не нужен. Достаточно консоли. Посоветуйте что выбрать.
1. При беглом взгляде на реал-тайм ОСи понравилась eCOS. Но так и не понял можно ли на неё поставить компилятор предназначенный для Линукс? Или для неё монитор с клавой ругательные слова? Везде пишут только как сильно можно её урезать. А писать прямо на ней можно?
2. WinCE симпатична тем что думаю не будет шока как от Линукс. Наверняка много ДОКи и форумов в инете.
3. Линукс, ну тут вариантов просто тьма, самому не разобраться. Пугает полное не понимание чего и как. Но т.к. многие идут в этом направлении, пытаюсь изучать. Начал с Ubuntu.
4. BlueCat Linux, ничего не знаю о ней кроме этого описания. Вроде не реал-тайм.
5. uCOS увидел на этом сайте, но не понял для каких процессоров она. В инете вообще о ней ничего неслышно.

Линукс и WinCE не являются операционными системами реального времени.
uCOS описан здесь: http://micrium.com/page/products/rtos

Хм....WinCE вроде таки является ОСРВ.

Согласен,WinCE является ОСРВ.

http://www.microsoft.com/windowsembedded/e...ce/default.mspx

DOS

Интересно, а с чем связано требования писать код непосредственно на целевой системе?

Для прояснения ситуации советую почитать Building Embedded Linux System. Написано очень просто и понятно. Для "въехать" самое оно. А дальше уже самому будет понятно что делать и куда развиваться.

А что, она уже поддерживает многопоточность и релтайм?

Сечас всё под DOSом и есть. Есть потребность в развитии "что бы не отстать". Под DOSом проблемы с файловой системой, вызвал функцию записать кусок файла и твоя прога стала колом пока всё реально не запишеться. Т.е. не умеет писать файл в фоновом режиме, а мне только сообщить об окончании для получения новой порции. Также есть вопросы по Ethernet и ТСР драйверу, пока использую пакетный драйвер+ТрумплетТСР. Но под новые процессора можно пакетника и не найти (в комплекте идут драйвера только под операционки).

Удобство отладки!!! Сейчас так и делаю, да и мощность позволяет. Система представляет собой контроллер в виде корзины со слотами. В него вставляется плата процессора и куча плат ввода-вывода и связных RS232/RS485. Процессор должен опрашивать все эти платы постоянно, обмениваться по связи в несколько направлений одновременно. Т.е. я хочу сказать что в программу поступает куча внешних сигналов и при отладке нужно ставить точки останова на события от внешних воздействий и трассировать по шагам.
Про uCOS и еCOS так и не ответили, можно ли прямо на них писать? Или это для оч встраиваемых систем, и писать только на компе?

Если брать конкретно Linux, то там можно на целевой платформе запустить GDB сервер (отладчик) и дальше уже не быть привязанным клавиатурой к вашему целевому устройству.Тоже самое и относительно компиляции программ - программа собирается на "большом" компьютере, далее по какому-то из интерфейсов (например ethernet) заливается на целевую платформу.


Скорее всего что нет.

Это просто Вы не умеете их в фоне писать. Может просто научиться???

Не процессоры, а контроллеры. Реально новых давно уже нет, массовых тем более немного, а накрайняк из похожих ваяются. Я, например, уже за последние годы интеловский десятилетней давности уже раза 3 PID добавлял . Пакетник штука простая.

Вы не поверите, но это умеет c 80x годов досовский борлондячий отладчик правда только по RS232.

Внимательно слушаю, научите. Я уже доходил до того что писал файл по секторам вызывая BIOS а не DOS. Как ещё быстрее не знаю. Файловая система FAT-16, носитель CompactFlash, подключен через IDE порт.

Не понял, пакетник под каждый контроллер ведь свой. Иначе как он знает как с этой микрухой работать? Да и этот ТСР драйвер под DOS отавляет желать лучшего, может есть другие, подскажите?

Знаю. Причём пользовался. Честно говоря, работать можно но только от без выходности.

Тогда какие остаются варианты из реал-тайм клонов Линукса, посоветуйте из чего смотреть. Писать драйвера наверно придётся. Т.к. нужен прямой доступ к платам, которые установленны в ISA слоты.
Ещё хочу спросить есть ли в еCOS текстовый или графический экран?

uCOS - глухой embedded, никаких 'компиляторов на ней' нет и не предвидется

eCOS - аналогично. В eCOS есть встроенный gdb stub - поддерживает удаленную отладку через RS232 или Ethernet.
Экран в eCOS есть, текстовый точно, насчет графики не в курсе, вроде тоже что то есть.
Update: есть 'Microwindows' (NanoGUI)

eCOS черезвычайно сильно конфигурируемая система - можно из всего, что в ней есть выбрать то, что надо и настроить, как надо

NB. eCOS это не Linux, у них ВООБЩЕ нет ничего общего!

Общее у них POSIX совместимость. Так и Linux это совсем не Unix, а только совместим по вызовам API.
Вот про удаленную отладку через Ethernet если можно подробнее. Понимаю так: на Таргеге стартует ОСь и запускает сервис который ощается по Ethernet с Хостом(компом). На компе я в чём то пишу и отлаживаю, и это как будто моя прога работает на Таргете. Это мне тоже подходит. Главный вопрос - на компе я должен писать и отлаживаться в строго определённой (для каждой ОСи) проге, или могу использовать любой сторонний компилятор генерящий код для данной ОСи? Нужна такая ОС которая позволяет отлаживаться на чужом компиляторе.

Неа. У eCOS есть подсистема совместимости (читай эмуляции) posix, но его родное API - не posix, а нечто совершенно свое

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

eCOS заточена под gcc и gdb.

Если этот 'чужой' компилятор поддержит расширения gcc, а 'чужой' отладчик сможет работать с gdb stub'ом - то ради бога Боюсь только, что врядли найдется второй такой компилятор и отладчик

Советую всё-таки присмотреться к Linux.
Всё что вам нужно в Linux есть.

Есть кросс-компиляторы, мощнейший консольный отладчик GDB, эмуляторы... Да что еще нужно для ваших целей?
Остается 1 вопрос - реал-тайм.. в этом вопросе советую разобраться что есть реал-тайм, жесткие и мягкие ОСРВ, и когда их применяют... Скорее всего на 99% вам подойдет Linux, не смотря на формальную не риал-тайм.
Updated: посмотрите реал-тайм фреймворк для Linux - Xenomai

Понял что eCOS не подходит. Это для более встраиваемых. Выбывает из списка кандидатов.

Вот это врядли. Он сделан как обычный компилятор для компов. Написал на нём и внём же запустил на отладку. Вот если бы на хосте появлялся монитор таргета и я запускал в нём компилятор. Короче просто удалённый рабочий стол по сети.

Присматриваюсь, и жду от вас рекомендаций в выборе конкретного дистрибутива - RTLinux, FreeLinux, RTAI.... Хотя ещё в кандидатах WinCE, как более знакомая и понятная ОСь. Выбираю.

Нужен квант времени (период через который программа получает управление повторно) не более 100 мкс. А оптимально 20-40 мкс. Поэтому думаю нужен реал-тайм. А жесткие или мягкие ОСРВ незнаю, главное обеспечить времянку.

Планирую пользоваться именно Free_Pascal. Т.к. знаю только его, и уже написана прога но для ДОСа.

Multiuser DOS...

Даю демонстрашку... REAL/32

Оригинал поддерживает до 64 задач в реал-тайме. Могу дать, правда весит он разумеется больше. Поддерживает сеть,
NTFS, и много-много чего. Последняя модификация 2004 года.

Будут вопросы, спрашивайте... Недавно открывали в задачах несколько ChessMaster 2000 и "стравливали" их между собой
ставя ставки...

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

Под досом все ресурсы в наших руках. Такие проблемы решаются без труда. Зато работать с USB, Ethernet трудновато.
Есть еще ДОС 2000, якобы военная. Она работает в защищенном режиме. Free Pascal, к примеру, в защищенном режиме с трудом 50000 прерываний в секунду (не сложных) еле отрабатывал, а в реальном режиме -200000, невзираяя на дисковые операции.

От DOSа всё таки пытаюсь уйти. Это не только из-за файловых операций но и поддержка современных инет протоколов, веб-сервер. С USB вооще пока не умею работать. Обрабатывать прерывания планирую драйвером плат. В контроллер можно установить до 4х 8ми портовых RS232/485 плат, скорость портов до 115 кбит. Но обычно плат не более 2х, и работаем на 19200. Итого максимум это ~320т прерываний. В реале думаю не более ~32т прерываний. Других источников прер вроде нет. Ethernet вроде их не требует. Сейчас всё это написано для ДОСа на Борланд Паскале, и обработка прер тоже в виде ассемблерных вставок. Всё летает.
Давайте сконцентрируемся на Линуксе. Пока из претендентов это RTAI, Xenomai и RTLinux. Что ещё предложете из вариантов. Прошу также опишите основные особенности и отличия от других. Как я вычитал RTAI и Xenomai вышли из одного проекта. В чём разница между ними?

Я конечно подозреваю, что вы должны были это сами давно найти, но вдруг

http://rt.wiki.kernel.org/index.php/Main_Page

Хм, а FIFO у них отсутствуют как класс?

Ныне редкая из этих плат имеет FIFO менее 128 байт

Да, "глубокие" познания .

Сдается мне реальное время Вам ни нафиг не нужно.... Берите Windows + @$$##$ Делфи с коллекцией левых "компонентов" и
не морочьте голову ни себе ни людям.

Есть, размером 16 байт. Там стоят стандарнтные UART 16554. Плата RS

Имел в виду что прерывания сторонним обрабатываются сторонним драйвером, например пакетным для ДОС. Поэтому в моей программе не требуется обрабатывать прерывания от сети. Ну выразился не точно.

"Проект Xenomai начался в августе 2001. В 2003 он был объединён с проектом RTAI. В конечном счёте проект RTAI/fusion стал независимым от RTAI в 2005 году под названием Xenomai." Источник Wiki
Уважаемый Гуру, Вы бы лучше не пинали новичков, а помогли добрым словом. Ведь Первый шаг он трудный самый. Я вот спросил в чём разница между RTAI и Xenomai. Пока никто не расписал плюсы-минусы и особенности каждой. И подскажите хороший русский сайт по RTAI и Xenomai.

Хорошого русского сайта, я полагаю, вы не найдете. Советовал бы вам посмотреть mailing-list'ы на наличие рускоязычных разработчиков, и тогда уже вести конкретную переписку с конкретными гуру в этих вопросах.
Посмотрите прикрепленный PDF, там как раз идет сравнение RTAI и Xenomai.
Мне самому эта тема интересна, но пока как хобби, поэтому конкретных советов, пожеланий, дать, к сожалению, не могу..
Но я бы не советовал не разобравшись с Линуксом как таковым лезть в такие дебри... Нужно для начала хорошенько набить себе руку в самой системе Linux, пересборке ядра, тонкой настройке, ramfs, патчи, диффы и так далее.. С ходу разобраться сложновато будет, ИМХО.. Хотя, русские лёгких путей не ищут
И на последок, всё-таки призадумайтесь над словами, уважаемого zltigo, нужно ли вам реальное время, классифицируется ли ваша задача как задача, результат выполнения которой зависит не только от алгоритма, но и от времени... Ибо не стоит забывать, что ОС работающая на супер-быстром камне еще не означает RTOS, и в тоже время обычная операционка на камне с приличном запасом быстродействия (относительно конечно задачи) на 90% (ИМХО с потолка ) перекрывает все возможные приложения (кажущаяся необходимость в RTOS)... Подумайте, нужно ли Вам реальное время на самом деле...

Возможно и не нужно. Тогда посоветуйте, на какие дистрибутивы обратить внимание? Нужен Линукс для встраиваемых систем, но с возможностью работать непосредственно на нём. Графика не нужна, консольного режима хватит. И желательно без лишних заморочек с правами доступа (root-user), только 1 пользователь и ему всё можно. А точнее вообще без этой политики. С моленьким временем загрузи, желательно не более 10 сек.

Тогда берите Kubuntu. будете осваиваться с ней, писать программы, отлаживаться. к тому времени поймёте как из любого линукса сделать то, что вам нужно.

P.S. ещё про QNX забыли.

Без "этой" политики Вам нужен MS-DOS В Linux права доступа - базовое понятие, никуда от него не денешься. (хотя Вы просто не понимаете, какой это огромный плюс, а не минус)
Время загрузки обеспечивается тонкой настройкой системы, её служб.. откуда будете грузить ядро (XIP для ускорения).. параметров сборки самого ядра.


Почему именно Kubuntu?
В данном случае человеку не требуется десктоп-менеждера, поэтому Gnome, KDE, не принципиально.
Вообще-то Kubuntu тяжеловата для embedded-приложения, да и не нужна там. Если уж брать, то Debian (хотя он тоже весьма тяжел)

Kubuntu, это потому, что там KDE. Пользователям Windows с ней немного проще знакомиться. Зачем окошки? что-бы полноценно за этим девайсом ещё и работать на момент написания программ. Согласитесь без Интернета с линуксом трудновато. Сразу бросать человека на консоль негуманно. Хорошая IDE тоже иксов требует. Человек будет по форумам лазать и т.д. А когда разберётся с линуксом, то снесёт Иксы [censored] =) Снести иксы с Кубуны так-же просто как и с Дебиана и любого другого дистрибутива.

Человек написал . Вы на "это" хотите современный десктопный дистрибутив ставить? Есть достаточно широкий выбор linux-дистрибутивов, обрезанных по самое немогу. Например вот. А вообще google -> "minimalistic linux".

Единственное, я не понимаю почему стоит задача именно на том-же девайсе и работать?
Может быть это требование так-же легко уйдет как и реалтайм?
По большому счёту это только усложняет задачу...... Давайте работать на мощной машине, а на таргет загружать приложение, запускать, отлаживать удалённо.
Процесс можно автоматизировать ведь до "одной кнопки".
Дистриб....... А я вам слакварь порекомендую. Дело в том, что он как девайс без корпуса - замыкай чё хош.
Та-же убунта патченная перепатченная....не то это. Честное слово, совсем не то! Хотя да, можно из любого линуха собрать чё надо - полностью согласен.
Ядро наверное лучше брать ванильное и если и допиливать что-то - то точно знать что где и как, чем из убунты чужие патчи для поддержки новомодных лэптопов выковыривать...
В слаке ваниль ядро. Также плюс в том, что отсутствие пакетного менеджера позволяет легко творить чё хош )

Поправьте, если мои рассуждения ошибочны.

Требуется - тот-же пакетный драйвер вызывает Ваш обработчик прерывания из своего обработчика дважды на каждый принятый фрейм.

Вообще я предлагаю не на этом "минималистичном девайсе" программное обеспечение разрабатывать а на полноценном ПК. А перенести это программное обеспечение на "минималистичный девайс" после окончания цикла разработки. Вот и все пироги. А то может ещё для AVR на AVR программы писать?

Ну AVR это совсем эмбедед.

Ничего не понял. Прошу Вас писать по русски. Я новичёк в Линуксе, и терминами не владею.

Удобство. Писать и отлаживать буду на стороннем компиляторе. Насколько я знаю "запускать и отлаживать удалённо" можно только в конкретной среде для каждой ОС. Для eCOS свой удалённый отладчик, для других свой. Сейчас работаю под ДОС. Пишу на таргете ДОСовским компилятором. Вот если какая ОС позволит работать своим компилятором удалённо, но я слабо в это верю.

Убунта только для освоения Линукса. Вот тут я и выбираю кандидатов для таргета.

Раз их не выкинуть, ладно. Но нафига они в контроллере? На нём несколько человек не будут работать. Точнее никто.

XIP это опять для оч встроенных. Такой принцип мы сами делали, когда код оставался в ПЗУ, а сегмент данных перенаправляли на ОЗУ. И проц работал прямо по ПЗУ. Здесь всё как в РС, запускается БИОС а затем грузится система с CompactFlash.

Как раз таки читал что наоборот. Гном легче будет виндавозникам, потому и поставил Убунту.
Кто нибуть пробовал BlueCat Linux? Что это за зверь?

Если совсем минимальная система нужна, то посмотрите на Gentoo. ВСЁ собирается из исходников, ключи компилятора для сборки могут быть заданы с учетом в том числе и железа (в других дистрибутивах ключи при сборке для некоторой средней конфигурации). НО это долго и нетривиально!

Ванильное ядро - это то, которое доступно с сайта kernel.org т.е. это то, что собственно и есть линукс в чистом виде. Далее, разные дистрибутивостроители добавляют свои патчи, которые улучшают совместимость/скорость и т.д. Яркий пример патченного ядра - ядро убунту. Там едва ли не самое запатченное ядро. Не думаю, что для контроллера это хорошо. Слакварь использует ванильное ядро и исповедает так сказать классический unix way. Что, как мне кажется, очень хорошо для тюнинга под ваш таргет.

Удобство....хм. не вижу никаких особых удобств в том, чтобы работать на машине с ограниченными ресурсами.
По-моему это удобство немного надуманное и кажущееся....хотя, вам там виднее конечно..
Другие ОС? Я думал линукс уже выбран.

Предлагаю: ставим на таргет дистрибутив(самосборный, либо допиленный), удовлетворяющий требованиям по скорости загрузки и "реалтаймности" ядра. Обеспечиваем работу всего оборудования таргета(драйверы). т.е. готовим систему к тому, чтобы только скормить ей Ваше приложение и она начала выполнять свои функции. Это первый этап, который практически не потребует программирования(ну может только чуток и то сомневаюсь).
Второй этап:
Организуем процесс удалённой загрузки/запуска вашего приложения и его отладки.
А разработкой занимаемся на нормальной мощной машине с доступом в инет, нормальным разрешением и двумя гигами оперативки.
При этом режим работы таргета получается даже ближе к боевым. Сборка проекта на корэ2 будет в любом случае происходить веселее чем на вашем контроллере.

Но это моё ИМХО. Возможно удалённая отладка будет не так удобна, как хотелось-бы. Признаюсь, я лично никогда такие фокусы не проделывал.
А ещё нужно хорошо подумать какая именно отладка нужна? Может быть будет вообще достаточно тестового вывода в консоль/файл....
Также не удивлюсь, если окажется, что само приложение можно процентов на 95 обкатать на другой машине, подсовывая софтине отладочные данные. Тогда при отладке на таргете Вам по сути придётся только контролировать правильно ли контроллер работает с аппаратурой.....
Просто я не знаю сложности вашей задачи. Так, просто рассуждаю..... )))

sigmaN
Хочу Вас поблагодарить за наводку на Slackware. Это похоже то что надо. Очень понравилась их идеология. Особенно отсутствие зависимостей. Уже поставил Slackware в консольном режиме, изучаю. Гораздо понятней чем Убунту. Хорошо описана и документированна. Это хорошо так как нужно будет её сильно обрезать, для работы в контроллере. Также присматриваюсь к Slax. Пока не совсем понятна разница. Slax это просто урезанная аварийная ОС? Или если её поставить на винт то будет полноценная. Обрезать ОСь под контроллер Вы бы рекомендовали на основе Slackware или Slax?