[Ro. 0]

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

Только дорого.

<{POST_SNAPBACK}>

 

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

[alogvinov 0]

Если кому интересно, пусть посмотрит на ChorusOS.

Разработана Sun, распространяется в исходных кодах.

Имеется достаточно подробная документация, правда в формате SGML.

 

Ссылка:

http://www.experimentalstuff.com/Technologies/ChorusOS/

 

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

[v_shamaev 0]

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

Только дорого.

<{POST_SNAPBACK}>

 

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

<{POST_SNAPBACK}>

 

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

[_VM 0]

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

 

Вообще есть такое мнение:

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

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

 

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

[COMA 1]

_VM,

Вообще есть такое мнение:

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

 

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

[dxp 65]

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

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

Вообще есть такое мнение:

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

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

 

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

 

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

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

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

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

 

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

<{POST_SNAPBACK}>

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

[CeDeX 0]

dxp

 

:a14:

 

Грамотно и доходчиво!

Полностью поддерживаю.

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

[Fast 0]

Подскажите, плз, какие RTOS поддерживают процессоры Analog Device?

Меня интересует, в частности, BlackFin серия.

Нашел, что uClinux и кажется Nucleos OS, а еще?

 

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

скажу лишь, что скорость записи на диск высокая (десятки МБ) и DSP будет нехило нагружен.

[Anybody 0]

Кину камень в огород AD.

Проще взять TMS320, у них есть втроенный таймер 64 бита.

Специально для работы RTOS, которая поставляется в пакете Code Composer Studio. Называется сие DSP BIOS :)

Ни каких наворов в целом нет, которые тут и не нужны.

Тут как я понимаю только задачи менять :)

[dxp 65]

Кину камень в огород AD.

Проще взять TMS320, у них есть втроенный таймер 64 бита.

Специально для работы RTOS, которая поставляется в пакете Code Composer Studio. Называется сие DSP BIOS :)

Ни каких наворов в целом нет, которые тут и не нужны.

Тут как я понимаю только задачи менять :)

<{POST_SNAPBACK}>

И в чем тут камень? :)

И почему проще взять TMS320? У АД тоже есть аналогичное поделие - VTK (тоже закрытое). :(

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

[Anybody 0]

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

[dxp 65]

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

<{POST_SNAPBACK}>

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

[xyzzy 0]

_VM,

Вообще есть такое мнение:

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

 

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

<{POST_SNAPBACK}>

 

Угу.

 

while(1) {asm volatile ("halt");}

а остальное по прерываниям. :twak:

 

--zzyxy

[rubin 0]

И в чем тут камень? :)

И почему проще взять TMS320? У АД тоже есть аналогичное поделие - VTK (тоже закрытое). :(

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

<{POST_SNAPBACK}>

 

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

[dxp 65]

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

<{POST_SNAPBACK}>

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

 

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