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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Думаю вы заблуждаетесь. Прочитайте вторую страницу указанного вами файла.
Цитирую: "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."

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

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



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

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

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

Вот есть такое:
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

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

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

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

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

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

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

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

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

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

_VM,


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

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

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

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


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

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


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

dxp



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

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

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

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

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

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

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

Угу.

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

--zzyxy

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

[/quote]

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

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

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

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

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

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

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

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

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

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