RTOS, Всё по ОС реального времени Опции

[one_man_show]

По просьбам трудящихся создал форум по ОС. Отдельный топик по RTOS, отдельный по обычным ОС. Когда набухнет, можно разнести по разным операционкам, пока в куче.

Есть желающий модерировать форум, уважаемый участник
Evgeny_CD.

[Evgeny_CD]

===== Начало классификатора встраиваемых ОСРВ ========

Код

[Название ОС] RTEMS
[Расшифровка названия]
    Real-Time Executive for Military Systems
    Real-Time Executive for Multiprocessor Systems
[Основной сайт] http://www.rtems.com
[Фирма-разработчик] On-Line Applications Research Corporation
[Сайт фирмы-разработчика] http://www.oarcorp.com
[Лицензия]
    сама ОС - GNU
    компоненты имеют различные лицензии
    http://www.rtems.com/license/index.html
[Поддерживаемые платформы]
    arm - ARM V7 and above
    c4x - Texas Instruments C3x and C4x DSPs
    h8300 - Hitachi H8 family
    hppa1.1 - Hewlett-Packard PA-RISC
    i386 - Intel i386, i486, Pentium and above, AMD Athlon and above
    i960 - Intel i960 family
    m68k - Motorola m680x0, m683xx, CPU32, and Coldfire CPUs
    mips - MIPS ISA Levels 1 and above for 32 and 64 bit CPU models
    no_cpu - Example port to "no cpu"
    or32 - OpenCores OpenRisc32 CPU
    powerpc - IBM and Motorola PowerPC 4xx, 5xx, 6xx, 7xx, 8xx, 74xx, and 75xx
    sh - Hitachi SH1, SH2, SH3, and SH4
    sparc - SPARC V7 and above CPUs
    unix - Synthetic target CPU which allows RTEMS programs to execute natively on Linux, Solaris, FreeBSD, Cygwin, and HPUX.
[Краткая характеристика]
    Разработчики очень любят архитектуру PowerPC
[Статьи]
    http://micro.mephi.ru/motlab/artic/art3/RTEMS.htm - на русском
    http://www.rtems.com/refs.html
[Документация]
    Очень хорошая документация входит в дистрибутив ОС (10М PDF документов).
    !Та документация, на которую ведут ссылки с главной страницы сайта http://www.rtems.com, устарела!

===== Продолжение следует ========

[yes]

про RTEMS нужно заметить, что до недавнего времени она поддерживала только х86 и РРС (может еще какую-то экзотику, но порта для АРМ не было и вообще портов было мало)

так же в старом варианте было достаточно скудно с API
(если API поменялось - то эта другая RTEMS, а если не менялось, то переход от более современной системы вызовет неудовольствие отсутствием сервисов)

я бы советовал смотреть на eCos - sources.redhat.com
более мощный функциональный аналог RTEMS
минус (в сравнении со старым RTEMS) - больший объем кода - труднее разбираться, но есть конфигуратор, которым можно отрезать все лишнее

[KA_ru]

Мы вот используем ThreadX. Очень даже и не плохо.
Только дорого.

[Evgeny_CD]

Мы вот используем ThreadX. Очень даже и не плохо.
Только дорого.

А можно запостить сюда более подробную инфу, я бы ее обработал и включил в каталог?

[KA_ru]

http://www.expresslogic.com/txtech.asp

[IgorKossak]

Что-то не очень красиво получается делать каталог в виде вставки кода, и места много, и ссылки не работают.
Надо бы подумать как это всё систематизировать.
Повторю и здесь вопрос: надо ли перенести в этот форум топики о RTOS из форума по микроконтроллерам?

[AlexandrY]

Никаких преимуществ перед uC/OS не заметил.
Только вот одни недостатки:
Слишком сильная привязка к архитектуре ядра и даже к компилятору, гораздо труднее портировать на другие платформы.
За привязку к компилятору вообще убить мало.
Очень много мелких файлов с непонятными названиями, хотя они там хваляться понятностью наименований. А вот функции они именуют очень длинно, специально наверно чтобы утомить программера.
Переключение контекста хоть и очень быстрое, а все равно медленнее чем табличный способ uC/OS.
Сервисы выделения памяти и таймеров не на высшем уровне, тем более что часто они могу зависеть от задачи и реализуються разработчиком отдельно.
Чета не нашел единого файла со всеми настройками ресурсов операционки как uc/OS.
Их безотвественные заявления о ресурсах нужных стеку, вызывают подозрения в нечестной рекламе. Он же зависит от количества задач.
Единый размер стека для всех задач тоже есть определенная кривизна.
Ну и т.д. Думаю пока хватит...

[dch]

[Основной сайт] http://www.rtems.com

Несколько лет назад, в числе contributors было www.nsg.ru,
упоминание об этом факте было чуть не на первой странице

[AlexandrY]

Переносить бесполезно.
Здесь идет чистая мешанина.
На конфе по микроконтроллерам выступают либо чистые хардваристы либо программеры low-end встраиваемых систем.
А как речь идет про операционки так сразу заводят разговор о Linux, uClinux, eCOS и других тежеловесах которые с low-end системами и рядом не лежали.
Сначала надо классифицировать платформы в связи с которыми идет речь об операционках а потом уж выделять ветки о RTOS.

[Evgeny_CD]

Что-то не очень красиво получается делать каталог в виде вставки кода, и места много, и ссылки не работают.
Надо бы подумать как это всё систематизировать.
Повторю и здесь вопрос: надо ли перенести в этот форум топики о RTOS из форума по микроконтроллерам?

1. Буду делать большой HTML файл и класть в виде вложения. Самое красивое и универсальное.

2. Думаю, было бы хорошо перетащить сюда профильные посты. Но перед этим надо подумать над струтурой топиков в этом форуме. Не стоит все валить в кучу, возможно, стоит иметь по основному топику на каждую ОС. Но пока еще не придумал. Предложения дам на той неделе.

[Evgeny_CD]

Переносить бесполезно.
Здесь идет чистая мешанина.
На конфе по микроконтроллерам выступают либо чистые хардваристы либо программеры low-end встраиваемых систем.
А как речь идет про операционки так сразу заводят разговор о Linux, uClinux, eCOS и других тежеловесах которые с low-end системами и рядом не лежали.
Сначала надо классифицировать платформы в связи с которыми идет речь об операционках а потом уж выделять ветки о RTOS.

Именно классфикаия и есть пока основная цель! Пока пусть народ постит сюда кто что знает, а я буду разгребать.

[lamerok]

А вот для маленьких контроллеров подойдет
CMX-TINY+ - Tiny Version of CMX RTOS

Очень компактная, удобная и быстрая, без ненужных наворотов.

[IgorKossak]

А вот для маленьких контроллеров подойдет
CMX-TINY+ - Tiny Version of CMX RTOS
Очень компактная, удобная и быстрая, без ненужных наворотов.

И без исходников.
А вот для AVR и MSP430 есть очень неплохая scmRTOS.
Применял её под AVR. Обнаружил большие преимущества по сравнению с uCOS по быстродействию и требованиям к оперативной памяти.

[_Sam_]

Вот недавно натолкнулся JacOS, по заверениям авторов требует минимум ресурсов. Описалово на русском, хотя похуже чем у scmRTOS. Исходные тексты прилагаются.

[one_man_show]

Есть еще RTOS OSEK - это та, чьи исходники идут вместе с DXP2004. Там многие примеры для МК сделаны под эту операционку. Её используют в автомобильной промышленности.

[Evgeny_CD]

Есть еще RTOS OSEK - это та, чьи исходники идут вместе с DXP2004. Там многие примеры для МК сделаны под эту операционку. Её используют в автомобильной промышленности.

А можно сразу URL'у на ресурс по этой осине.

[CrazyAlex]

Именно классфикаия и есть пока основная цель! Пока пусть народ постит сюда кто что знает, а я буду разгребать.

Наткнулся на статью в инете "Операционные системы для встраиваемых приложений". http://www.compitech.ru/html.cgi/arhiv/00_04/stat_62.htm
Сделана попытка свести в таблицу требования по памяти и кросссредствам, а главное есть ссылки.

[one_man_show]

Есть еще RTOS OSEK - это та, чьи исходники идут вместе с DXP2004. Там многие примеры для МК сделаны под эту операционку. Её используют в автомобильной промышленности.

А можно сразу URL'у на ресурс по этой осине.

Не вопрос:
OSEK/VDX RTOS

[IgorKossak]

Вот недавно натолкнулся  JacOS, по заверениям авторов требует минимум ресурсов. Описалово на русском, хотя похуже чем у scmRTOS. Исходные тексты прилагаются. 

Кооперативная ОС, потому и ресурсов надо мало.
Кстати, где Вы видели исходники на неё? В распространяемых архивах только хёдеры, предкомпилированные библиотеки и примеры.

[Evgeny_CD]

Вот недавно натолкнулся  JacOS, по заверениям авторов требует минимум ресурсов. Описалово на русском, хотя похуже чем у scmRTOS. Исходные тексты прилагаются. 

Кооперативная ОС, потому и ресурсов надо мало.
Кстати, где Вы видели исходники на неё? В распространяемых архивах только хёдеры, предкомпилированные библиотеки и примеры.

Я связывался с ее автором. Поддержка за полгода 4500р, в таком случае он дает исходники.

[AlexandrY]

OSEK это не RTOS, а стандарт на RTOS типа как POSIX. А то. что в DXP2004 просто реализация под ядро на основе архитектуры I51 и только, причем опутанная кучей дурных формальностей типа компилятора языка конфигурирования ядра RTOS.

[one_man_show]

OSEK это не RTOS, а стандарт на RTOS типа как POSIX. А то. что в DXP2004 просто реализация под ядро на основе архитектуры I51 и только, причем опутанная кучей дурных формальностей типа компилятора языка конфигурирования ядра RTOS.

Внимательно прочитайте первую страницу указанной выше ссылки и первую же страницу спецификации, файл прикладываю.

Прикрепленные файлы

 os221.pdf ( 836.91 килобайт ) Кол-во скачиваний: 201

 

[AlexandrY]

Думаю вы заблуждаетесь. Прочитайте вторую страницу указанного вами файла.
Цитирую: "This document describes the concept of a real-time operating system, capable of multitasking, which can be used for motor vehicles.
It is not a product description which relates to a specific implementation."

[one_man_show]

Можем бесконечно спорить о том, что ЭТО есть и где почитать
Замечу только, что я с этой операционкой работаю и мои зарубежные коллеги называют ЭТО именно ОС.

[AlexandrY]

Вы зря уходите от ответа.

Можем бесконечно спорить о том, что ЭТО есть и где почитать
Замечу только, что я с этой операционкой работаю и мои зарубежные коллеги называют ЭТО именно ОС.

Вопрос совершенно понятен, какую реализацию спецификации OSEK и какого производителя в таком случае вы имеете в виду? Было бы интересно узнать на какой платформе вы ее применяете и с каким компилятором.
Скажем в DXP2004 производитель Altium, компилятор TASKING, но жалко что только под I51, а это уже несколько не актуально.

[one_man_show]

Вы зря уходите от ответа.

И не думал, просто не хочется засорять данный топик ненужной инфой. Я дал конкретную ссылку на OSEK/VDX. Использую данную ОС только под Таскингом для 51. Когда дойдут руки до СервисПак2 от Альтиума с 32-битным процессором, попробую не на 51.
А Вы применяете указанную ОС?

[AlexandrY]

Чес говоря, ваш пост и толкнул меня посмотреть эту OS.
Понравилась своей обстоятельностью и документированностью. Ее структура и объем очень напоминают uC/OS. Но смущает эта утилитка для настройки и привязка к компилятору Tasking. C Tasking-ом я имел дело когда работал с серией C167. Чуть не загубил проект, были большие проблемы при работе с различными моделями памяти, трудно было портировать чужие исходники.

[IchtiAndr]

Вот есть такое:
Nut/OS is Open Source implementation of a Real Time Operating System called Nut/OS and a TCP/IP protocol suite named Nut/Net
Сюда же:
Ethernut is an Open Source Hardware and Software Project for building Embedded Ethernet Devices
http://www.ethernut.de/en/index.html

[IgorKossak]

...TCP/IP protocol suite named Nut/Net...

Кстати, по многим отзывам, это одна из лучших имплементаций TCP/IP для встроенных приложений плюс обилие документации.

[Ro.]

Мы вот используем ThreadX. Очень даже и не плохо.
Только дорого.

Зашарь исходники будь патриотом!

[alogvinov]

Если кому интересно, пусть посмотрит на ChorusOS.
Разработана Sun, распространяется в исходных кодах.
Имеется достаточно подробная документация, правда в формате SGML.

Ссылка:
http://www.experimentalstuff.com/Technologies/ChorusOS/

Сам я с ней не работал.

[v_shamaev]

Мы вот используем ThreadX. Очень даже и не плохо.
Только дорого.

Зашарь исходники будь патриотом!

А в чем патриотизм?

[_VM]

Мне в своих задачах (в основном управление стремными объектами и обработка сигналов) использовать ОС стремно но порой приходится (не по моей инициативе конечно).

Вообще есть такое мнение:
Для мелких и средник микроконтроллеров/процессоров (типа AVR, ATMEGA, ADSP21xx) ОС вообще не нужны, это тоже самое, что разрабатывать СУБД на ПЛИС. Если программер ленив по натуре и ему хочется все по быстрому сделать, то какой бы надежной ОС не была, он все равно ошибок понаделает.
А для больших микроконтроллеров типа AT91ARM сам производитель пишет бибилиотеки для работы с железом, остается самому добавить только стек сетевых протоколов (как правило полная функциональность не требуется).

Страшно мне загружать в MCU мегакод, который должен крутиться месяцами без сбоев и тормозов. Лучше по простому и надежному: фоновая задача, обработчики прерываний, флажки ... Скорость выше и сердцу спокойней

[COMA]

_VM,

Вообще есть такое мнение:
Для мелких и средник микроконтроллеров/процессоров (типа AVR, ATMEGA, ADSP21xx) ОС вообще не нужны

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

[dxp]

Мне  в своих задачах (в основном управление стремными объектами и обработка сигналов) использовать ОС стремно но порой приходится (не по моей инициативе конечно).

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

Вообще есть такое мнение:
Для мелких и средник микроконтроллеров/процессоров (типа AVR, ATMEGA, ADSP21xx) ОС вообще не нужны, это тоже самое, что разрабатывать СУБД на ПЛИС.

Ну, во-первых, есть ОS, а есть RTOS, которые суть подмножество более широкого понятия OS. И с RTOS все несколько не так, как принято считать - типа, ОС - неслабое нагромождение мегакода, непонятно зачем, непонятно как работающего. Почитайте книжку Ж.Лябрусса про uC/OS-II, мнение, скорее всего, изменится.

Во-вторых, применимость OS вообще и RTOS в частности определяется не столько процессором, сколько прикладной задачей. Если есть возможность применять, то ОС (особенно с вытеснением) - большое удобство в работе, способ формализовать огранизацию потока управления программы и детерминировать время реакции на события (в случае выстесняющей).

Если программер ленив по натуре и ему хочется все по быстрому сделать, то какой бы надежной ОС не была, он все равно ошибок понаделает.

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

А для больших микроконтроллеров типа AT91ARM сам производитель пишет бибилиотеки для работы с железом, остается самому добавить только стек сетевых протоколов (как правило полная функциональность не требуется).

А кто сказал, что этот АРМ большой? А вот Филипс делает АРМы (серия LPC) в копрусах LQFP48 (с шагом 0.5мм) и стоимостью меньше десяти зеленых, т.е. почти как какая-нить мегаАВР и заметно меньше упомянутых сигнальников.

Страшно мне загружать в MCU мегакод, который должен крутиться месяцами без сбоев и тормозов. Лучше по простому и надежному: фоновая задача, обработчики прерываний, флажки ... Скорость выше и сердцу спокойней

Осмелюсь предположить, что опасения необоснованы. Программа под RTOS работает на самом деле даже более надежно, т.к. используется проверенный многими реальными проектами код, взаимодействие между частями формализовано и реализовано на основе надежных, проверенных средств (семафоры и прочие средства межпроцессного взаимодействия). Скорость... Смотря, что имееть в виду под скоростью. Если подсчитывать такты от возниконовения запроса на прерывание до получения управления ISR'ом, то тут ОС не рулит. Но если речь идет о времени реакции на события и их обработку (подразумевая, что обработка события - относительно длительный процесс и не может быть размещен целиком внутри ISR), то вытесняющая RTOS порулит любую foreground-background (т.е. бесконечный цикл и ISR'ы) систему.

[CeDeX]

dxp



Грамотно и доходчиво!
Полностью поддерживаю.
Вообще плохо отлаженные прерывания - явление оч. распространенное (сколько космических кораблей из-за этого полегло ), а готовая РТОС - это уже хорошо отлаженная система

[Fast]

Подскажите, плз, какие RTOS поддерживают процессоры Analog Device?
Меня интересует, в частности, BlackFin серия.
Нашел, что uClinux и кажется Nucleos OS, а еще?

Мне бы многоканальное АЦП + предв. обработка на DSP с записью на хост реализовать, какую OC лучше использовать, чтоб и удобно ПО было писать, и не глючила?
скажу лишь, что скорость записи на диск высокая (десятки МБ) и DSP будет нехило нагружен.

[Anybody]

Кину камень в огород AD.
Проще взять TMS320, у них есть втроенный таймер 64 бита.
Специально для работы RTOS, которая поставляется в пакете Code Composer Studio. Называется сие DSP BIOS
Ни каких наворов в целом нет, которые тут и не нужны.
Тут как я понимаю только задачи менять

[dxp]

Кину камень в огород AD.
Проще взять TMS320, у них есть втроенный таймер 64 бита.
Специально для работы RTOS, которая поставляется в пакете Code Composer Studio. Называется сие DSP BIOS
Ни каких наворов в целом нет, которые тут и не нужны.
Тут как я понимаю только задачи менять

И в чем тут камень?
И почему проще взять TMS320? У АД тоже есть аналогичное поделие - VTK (тоже закрытое).
А таймеров у АДшных процев тоже хватает. У того же черного фина есть специальный таймер прямо в ядре, который специально предназначен для работы в качетстве интервального таймера ОС.

[Anybody]

Ну не люблю я AD после секса с ADSP-2191 первых ревизий

[dxp]

Ну не люблю я AD после секса с ADSP-2191 первых ревизий

У ТИ (и любой другой фирмы) картина аналогичная. Если проц свежий, то глюков аппаратных (и в доке) просто море. Это объективное свойтво: чем свежее процессор, чем он сложнее, тем больше в нем ошибок и больше времени требуется на его доведение до ума. Уверен, что Вы это знаете не хуже меня.

[xyzzy]

_VM,

Вообще есть такое мнение:
Для мелких и средник микроконтроллеров/процессоров (типа AVR, ATMEGA, ADSP21xx) ОС вообще не нужны

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

Угу.

while(1) {asm volatile ("halt");}
а остальное по прерываниям.

--zzyxy

[rubin]

[/quote]
И в чем тут камень?
И почему проще взять TMS320? У АД тоже есть аналогичное поделие - VTK (тоже закрытое).
А таймеров у АДшных процев тоже хватает. У того же черного фина есть специальный таймер прямо в ядре, который специально предназначен для работы в качетстве интервального таймера ОС.

[/quote]

А разве DSP/BIOS у TI закрытая???

[dxp]

А разве DSP/BIOS у TI закрытая???

А что, открытая, что-ли? Тогда не подскажете ссылочку на исходники? А то народ тут пытался выцыганить у ТИ сорцы на DSP/BIOS, а те в ответ кукиш показывают. Даже под NDA не дают. Даже лицензионным пользователям композера.

Именно такая закрытость и отталкивает многих - не доверяет народ подобным вещам. Ведь даже дело не в модификации кода, а просто имея исходники всегда можно посмотреть, как реализован тот или иной механизм. Чтобы с бОльшим понимаением его использовать (либо не использовать, если он по сути не подходит). А дока не дает полной картины. Тут же речь не о виндоус-подобной системе идет, а о RTOS, которая является (в случае ее использования) органической частью пользовательского приложения, поэтому пользователь и желает знать, что это там в его программе ворочается. VTK, кстати, тоже, заметьте, не архипопулярно - в конетксте черных финов чаще поминается embedded linux, хотя *nix в качестве RTOS - это отдельный вопрос. Наверняка простой вытесняющий мультитаск свитчер + некий минимальный набор средств межпроцессного взаимодействия лучше ляжет практически на любую real-time и dsp задачу.

[_i8088_]

Я работал на AVR Mega 128 под операционкой которую мало кто знает:
PROC. Довольно шустрая OS. И мало требует ОЗУ.
http://www.nilsenelektronikk.no

Там только ядро и средства синхронизации.

Недостатки - есть ошибки, кажется она не развивается

[Sot]

Мы вот используем ThreadX. Очень даже и не плохо.
Только дорого.

Нельзя ли подробнее? Используете чистое ядро или в связке с FileX, NetX, UsbX?

[impatt]

Есть ещё операционка реального времени (не кооперативная :) для микроконтроллеров, целиком на С, только переключатель контекстов на ассемблере. Для AVR и ещё чего-то, лицензия BSD (можно встраивать и не публиковать весь проект, в отличии от GPL). Имеет пару планировщиков (на выбор), есть О1 планировщик, есть возможность подключить всякие навороты типа IPC, TCP\IP. Есть примеры, есть дока (скудновата, IMHO).
Называется XMK
Библиотеки С в комплекте нет, я вот думаю где бы взять для ARM. А то есть в инете, но всё под GPL и все хотят поддержку системных вызовов POSIX (или имитируют их присутствие, добавляя килобайт 50 к бинарю для прошивки во FLASH).
Вот, пытаюсь с ней разобраться. Никто не юзал ? Какие отзывы ? И может, есть какие-нибудь С библиотеки, наподобии AVR-Glibc, чтобы обеспечивали маломальские реентрабельные функции С и не желали бы поддержки системных вызовов POSIX со стороны ОС ?

[si21]

А кто-нибудь пытался скомпилировать RTEMS не используя gcc-компилятор, а например, ARM Developer Suite/RealView или что-то подобное? Какова сложность/трудоемкость такой подгонки/переделки исходных текстов?

[Гвоздик]

А я согласен с VM насчет ненужности применения ОС в микроконтроллерах. Взгляните на Майкрочип: кучи исходных текстов для работы и с USB, и с Ethernet. Просто надо-то подключить файлы, скомпилировать и все. А в бортовых устройствах все равно надежнее код без всяких ОС, да и отказоустойчивость выше будет. ОС думаю, больше для процессоров подходит, для микроконтроллеров же - это лишнее, не доросли они еще до супервычислений пока.

[si21]

ОС думаю, больше для процессоров подходит, для микроконтроллеров же - это лишнее, не доросли они еще до супервычислений пока.

Не хочу начинать бессмысленный спор, но интересно, чем же микроконтроллер отличается от процессора в вашем представлении? По большому счету, только набором развитой периферии! Современные МК переплевывают CPU 7-5-летней давности.
Кроме того, ОС НЕ СНИЖАЕТ НАДЕЖНОСТИ ИСХОДНОЙ ПРОГРАММЫ/КОДА, все зависит от умений/опыта/рук/настроения/состояния - выберите нужное - программирующего

[bmf]

А я согласен с VM насчет ненужности применения ОС в микроконтроллерах. Взгляните на Майкрочип: кучи исходных текстов для работы и с USB, и с Ethernet...

Исли вам нужен тормоз то да.

Что вы будете делать когда у вас одновременно нужно как бы две подзадачи
одна медленная другая быстрая. Применение OS в данном случае самое простое и эффективное решение.
Тот же USB - вам необходимо обеспечить реакцию на системный вызов за 1ms, в противном случае он может просто не проинициализироваться, из прерывания этого не зделаешь. Выход OS, или отдельный контроллер, только для USB.
Ethernet или диск- вы будете сидет внутри пока он вас не отпустит. В случае OS вы спокойно в это время делаете другую задачу.

Просто вы еще не достаточно осознали преимущества OS и пишете все по старинке в loop. (А скорей всего вы еще не написали не одной задачи с ее использованием)

Насчет надежности - это ваши домыслы - сейчас OS везде. вот например как раз для микроконтроллеров для использования в автомобилях - спецификация automotive electronics OSEK

[Andy Mozzhevilov]

А я согласен с VM насчет ненужности применения ОС в микроконтроллерах. Взгляните на Майкрочип: кучи исходных текстов для работы и с USB, и с Ethernet. Просто надо-то подключить файлы, скомпилировать и все. А в бортовых устройствах все равно надежнее код без всяких ОС, да и отказоустойчивость выше будет. ОС думаю, больше для процессоров подходит, для микроконтроллеров же - это лишнее, не доросли они еще до супервычислений пока.

Такие посты обычно пишут люди, которые под ОС ни разу не работали, ну либо виртуалы, типа Ольги Ноновой, чтобы народ подбить на кучу излияний в конферениях
Можно на эту проблему посмотреть с другой стороны. Некоторые разработчики просто еще не доросли до RTOS (ничего личного). RTOS в их понимании - лишнее нагромождение, причем непонятно как работающее и требующее непозволительно много ОЗУ и ПЗУ. Лечится чтением книг, для начала Лябрусса. Хотя, если взять PIC16 и х51, то использование вытесняющих RTOS для них действительно практически невозможно (PIC16) либо представляет скорее академический интерес для младших моделей в семействах мелких контроллеров.

[Olej]

1. Тема хорошая задана была: Параметры оценки архитектуры ОС...
Только ... заговорили её: пошёл разговор об каких-то реализационных нюансах, которые ... могли бы ещё иметь минимальный смысл, если говорить только об моноядерных ОС, но есть ещё архитектура микроядерная - клиент-серверная (QNX, ... March, Darwin...) в которой большинство всей этой мелочёвки либо не возникает, либо решается автоматически, ... либо просто не возникает в силу принципиального отличия архитектуры (но возникают другие).

2. Вдвойне интересна - потому, что обсуждение возникло в среде разработчиков ... "малых архитектур":

Можно на эту проблему посмотреть с другой стороны. Некоторые разработчики просто еще не доросли до RTOS (ничего личного). RTOS в их понимании - лишнее нагромождение, причем непонятно как работающее и требующее непозволительно много ОЗУ и ПЗУ. Лечится чтением книг, для начала Лябрусса. Хотя, если взять PIC16 и х51, то использование вытесняющих RTOS для них действительно практически невозможно (PIC16) либо представляет скорее академический интерес для младших моделей в семействах мелких контроллеров.

- что накладывает неизгладимый отпечаток, сравните, например, с:
http://qnx.org.ru/index.php?option=com_min...um=7&topic=1690

2. А если говорить об параметрах оценки - то какое к этому всему имеет касательство:

-. Многозадачность (есть, нет, кооперативная, вытесняющая, набор примитивов для cycl.exec и т.д.)
-. Приоритеты задач (стат, динам, несравниваемые и др.)
-. Особенности переключения задач (контекст, стеки и т.д.)
-. Реализация планировщика.
-. Реализация диспетчера.
-. Оценка преимуществ и недостатков методов планирования/диспетчеризации для конкретных задач.
-. Предотвращение инверсии приоритетов (есть, нет, методы)
-. Реализация искл. доступа к ресурсам.
-. Контроль задач (события, таймеры и др.)
-. Запуск системных и доп. процессов (методы для таймеров, ISR и т.д.)
-. Реализация HAL.
-. API - предоставляемые возможности.
-. Доп. средства (GUI, TCP/IP и т.д.)
-. Общая оценка.

- как может многозадачность быть кооперативная или вытесняющая, в не прямой зависимости от "реализации диспетчера", и чем "реализация планировщика" отличается от "реализации диспетчера"?...
- и все эти вопросы давно описаны и стандартизованы, так же как 100% "API и предоставляемых возможностей" POSIX.1003b (расширение реального ремени)... так что можно свести всю эту класификацию к вопросу: "... на сколько % вся ваша ОС соответствует POSIX?"...
- и только когда все механизмы POSIX - реализуются, а всё ещё не хватает, вот тогда можно думать о каких либо расширениях... но это очень не скоро .

А я согласен с VM насчет ненужности применения ОС в микроконтроллерах. Взгляните на Майкрочип: кучи исходных текстов для работы и с USB, и с Ethernet. Просто надо-то подключить файлы, скомпилировать и все.

3. А чем же эта "куча файлов" отличается функционально от ОС, только ... плохой ...

А в бортовых устройствах все равно надежнее код без всяких ОС, да и отказоустойчивость выше будет.

Если предыдущая цитата - это просто заблуждение, то эта уже - преступление .

4. Но есть ещё другая крайность - святая вера в то, что RTOS чем-то уж очень принципиально отличаются от GPOS (general purpose OS). См. например, здесь:
http://qnxclub.net/files/articles/RemarksO...TheMargins.html
- это частное мнение, но разработчика с опытом многих и многих лет...

Кроме того, ОС НЕ СНИЖАЕТ НАДЕЖНОСТИ ИСХОДНОЙ ПРОГРАММЫ/КОДА, все зависит от умений/опыта/рук/настроения/состояния - выберите нужное - программирующего

Использование API OS всегда только повышает надёжность программного кода, даже вне зависимости от кривизны рук... Те же стандарты POSIX обобщают опыт (и "грабли") 30-ти лет, а реализации API, например, QNX, обкатываются и исправляются - 25 лет.
Ручной код будетреализовывать то же самое (stdlib) - но только "горбато" и со множеством субъективных допущений автора...
Наблюдаемая иллюзияллюзия надёжности ручного кода объясняется только простотой и примитивностью механизмов и алгоритмов, реализуемых в ручном коде, на порядки проще, чем альтернативные реализации их в OS.

5. А если, всё же, вернуться к "параметрам и оценкам" - то первейшее дело, определиться с методиками: что и как вы станете сравнивать... К примеру, как это "по-честному" делает Dedicated Systems (www.dedicated-systems.com) - многолетний независимый тестер, в первю очередь RTOS & embedded tools: они в 1-ю очередь публикуют целую "книжку" методик на обсуждение: как мы сравниваем.

[Evgeny_CD]

...К примеру, как это "по-честному" делает Dedicated Systems (www.dedicated-systems.com) - многолетний независимый тестер, в первю очередь RTOS & embedded tools...

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

[Olej]

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

Посмотрите внимательнее: до самого последнего времени они все отчёты, по истечении некоторого времени от новизны - предоставляли свободно, для этого нужно было только пройти регистрацию, которая ни кого и ни к чему не обязывала .
Последнее время у них были какие-то реорганизации...
Если уж ... "ни в какую" - я могу отдельно отослать желающим некоторые самые интересные отчёты... только так, чтоб за одну отсылку, списком (адресов): отчёты достаточно объёмные (30-50-... стр.), pdf - не ужимаются, а у меня трафик ограниченный .

[bmf]

А как бы глянуть на пример хоть одного их полного отчета?

Некоторые свободно лежат на сайтах владельцев OS:
h**p://download.microsoft.com/download/7/2/f/72fef3b0-9545-46a4-8886-a94f265df9c4/EVA-2.9-OS-CE-01-I01.pdf
h**p://download.microsoft.com/download/7/2/f/72fef3b0-9545-46a4-8886-a94f265df9c4/EVA-2.9-TST-CE-x86-01-Iss1.00.pdf
h**p://www.qnx.com/download/download/8123/QNX_Neutrino_620_Evaluation_Report.pdf

[Velund]

А кто нибудь к метроверксовской OSEKturbo приценивался? Что то они темнят насчет цен и условий лицензирования.

[Evgeny_CD]

...Некоторые свободно лежат на сайтах владельцев OS:...

Спасибо!

[Olej]

Есть очень интересный новый проект L4Ka OS: open source микроядерная ОС, выполняемая при поддержке Intel... Я уже писал в другой теме, но событие того заслуживает: http://www.l4ka.org/

Множество поддерживаемых платформ:
- Alpha (21164, 21264)
- AMD64 (Opteron 242, Simics)
- ARM (SA1100, XScale, ARM925T)
- IA32 (Pentium and higher)
- IA64 (Itanium1, Itanium2, Ski)
- MIPS 64bit (R4000, R5000)
- PowerPC 32bit (IBM 750)
- PowerPC 64bit (Power3, Power4)

Там очень хороший темп, проект свежий... , если бы кто из достаточно твёрдо стоящих российских фирм (имеющих некоторый свободный ресурс ) взяли бы за свой tools для проектов ... мог бы быть серьёзный толк.

[ITPuls]

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

[ITPuls]

...да, кстати, кто найдет в себе силы написать что-нибудь путевое - добро пожаловать в автора www.itpuls.com.

[ArtemK]

Кто может сказать что-то хорошее или плохое о freeRTOS?

Предполагается применять ее на ядре ARM7TDMI-S (камень Sharp LH75400).
Наложены жесткие требования к объему ОЗУ и ПЗУ, поэтому и смотрю на freeRTOS.
Может быть подскажете еще что-то? Желательно бесплатное с открытыми исходниками. В данный момент стою перед выбором RTOS и GUI (640x480x4b).