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

Если кому интересно, пусть посмотрит на 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 задачу.