Ro. 0 18 марта, 2005 Опубликовано 18 марта, 2005 · Жалоба Мы вот используем ThreadX. Очень даже и не плохо. Только дорого. <{POST_SNAPBACK}> Зашарь исходники будь патриотом! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
alogvinov 0 18 марта, 2005 Опубликовано 18 марта, 2005 · Жалоба Если кому интересно, пусть посмотрит на ChorusOS. Разработана Sun, распространяется в исходных кодах. Имеется достаточно подробная документация, правда в формате SGML. Ссылка: http://www.experimentalstuff.com/Technologies/ChorusOS/ Сам я с ней не работал. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
v_shamaev 0 18 марта, 2005 Опубликовано 18 марта, 2005 · Жалоба Мы вот используем ThreadX. Очень даже и не плохо. Только дорого. <{POST_SNAPBACK}> Зашарь исходники будь патриотом! <{POST_SNAPBACK}> А в чем патриотизм? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_VM 0 23 марта, 2005 Опубликовано 23 марта, 2005 · Жалоба Мне в своих задачах (в основном управление стремными объектами и обработка сигналов) использовать ОС стремно но порой приходится (не по моей инициативе конечно). Вообще есть такое мнение: Для мелких и средник микроконтроллеров/процессоров (типа AVR, ATMEGA, ADSP21xx) ОС вообще не нужны, это тоже самое, что разрабатывать СУБД на ПЛИС. Если программер ленив по натуре и ему хочется все по быстрому сделать, то какой бы надежной ОС не была, он все равно ошибок понаделает. А для больших микроконтроллеров типа AT91ARM сам производитель пишет бибилиотеки для работы с железом, остается самому добавить только стек сетевых протоколов (как правило полная функциональность не требуется). Страшно мне загружать в MCU мегакод, который должен крутиться месяцами без сбоев и тормозов. Лучше по простому и надежному: фоновая задача, обработчики прерываний, флажки ... Скорость выше и сердцу спокойней :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
COMA 1 29 марта, 2005 Опубликовано 29 марта, 2005 · Жалоба _VM, Вообще есть такое мнение: Для мелких и средник микроконтроллеров/процессоров (типа AVR, ATMEGA, ADSP21xx) ОС вообще не нужны Скажу тебе по большому секрету, что почти всегда, мы все используем ОС типа "супер петля" - бесконечный цикл... ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 56 30 марта, 2005 Опубликовано 30 марта, 2005 · Жалоба Мне в своих задачах (в основном управление стремными объектами и обработка сигналов) использовать ОС стремно но порой приходится (не по моей инициативе конечно). Насчет обработки сигналов однозначно сказать нельзя, а вот управление объектами вполне себе вписывается в концепцию ОС+прикладной код. Вообще есть такое мнение: Для мелких и средник микроконтроллеров/процессоров (типа 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 30 марта, 2005 Опубликовано 30 марта, 2005 · Жалоба dxp :a14: Грамотно и доходчиво! Полностью поддерживаю. Вообще плохо отлаженные прерывания - явление оч. распространенное (сколько космических кораблей из-за этого полегло ;) ), а готовая РТОС - это уже хорошо отлаженная система Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Fast 0 8 апреля, 2005 Опубликовано 8 апреля, 2005 · Жалоба Подскажите, плз, какие RTOS поддерживают процессоры Analog Device? Меня интересует, в частности, BlackFin серия. Нашел, что uClinux и кажется Nucleos OS, а еще? Мне бы многоканальное АЦП + предв. обработка на DSP с записью на хост реализовать, какую OC лучше использовать, чтоб и удобно ПО было писать, и не глючила? скажу лишь, что скорость записи на диск высокая (десятки МБ) и DSP будет нехило нагружен. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Anybody 0 8 апреля, 2005 Опубликовано 8 апреля, 2005 · Жалоба Кину камень в огород AD. Проще взять TMS320, у них есть втроенный таймер 64 бита. Специально для работы RTOS, которая поставляется в пакете Code Composer Studio. Называется сие DSP BIOS :) Ни каких наворов в целом нет, которые тут и не нужны. Тут как я понимаю только задачи менять :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 56 8 апреля, 2005 Опубликовано 8 апреля, 2005 · Жалоба Кину камень в огород AD. Проще взять TMS320, у них есть втроенный таймер 64 бита. Специально для работы RTOS, которая поставляется в пакете Code Composer Studio. Называется сие DSP BIOS :) Ни каких наворов в целом нет, которые тут и не нужны. Тут как я понимаю только задачи менять :) <{POST_SNAPBACK}> И в чем тут камень? :) И почему проще взять TMS320? У АД тоже есть аналогичное поделие - VTK (тоже закрытое). :( А таймеров у АДшных процев тоже хватает. У того же черного фина есть специальный таймер прямо в ядре, который специально предназначен для работы в качетстве интервального таймера ОС. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Anybody 0 8 апреля, 2005 Опубликовано 8 апреля, 2005 · Жалоба Ну не люблю я AD после секса с ADSP-2191 первых ревизий :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 56 11 апреля, 2005 Опубликовано 11 апреля, 2005 · Жалоба Ну не люблю я AD после секса с ADSP-2191 первых ревизий :) <{POST_SNAPBACK}> У ТИ (и любой другой фирмы) картина аналогичная. Если проц свежий, то глюков аппаратных (и в доке) просто море. Это объективное свойтво: чем свежее процессор, чем он сложнее, тем больше в нем ошибок и больше времени требуется на его доведение до ума. Уверен, что Вы это знаете не хуже меня. :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
xyzzy 0 11 апреля, 2005 Опубликовано 11 апреля, 2005 · Жалоба _VM, Вообще есть такое мнение: Для мелких и средник микроконтроллеров/процессоров (типа AVR, ATMEGA, ADSP21xx) ОС вообще не нужны Скажу тебе по большому секрету, что почти всегда, мы все используем ОС типа "супер петля" - бесконечный цикл... ;) <{POST_SNAPBACK}> Угу. while(1) {asm volatile ("halt");} а остальное по прерываниям. :twak: --zzyxy Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rubin 0 13 апреля, 2005 Опубликовано 13 апреля, 2005 · Жалоба И в чем тут камень? :) И почему проще взять TMS320? У АД тоже есть аналогичное поделие - VTK (тоже закрытое). :( А таймеров у АДшных процев тоже хватает. У того же черного фина есть специальный таймер прямо в ядре, который специально предназначен для работы в качетстве интервального таймера ОС. <{POST_SNAPBACK}> А разве DSP/BIOS у TI закрытая??? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 56 14 апреля, 2005 Опубликовано 14 апреля, 2005 · Жалоба А разве DSP/BIOS у TI закрытая??? <{POST_SNAPBACK}> А что, открытая, что-ли? Тогда не подскажете ссылочку на исходники? А то народ тут пытался выцыганить у ТИ сорцы на DSP/BIOS, а те в ответ кукиш показывают. Даже под NDA не дают. Даже лицензионным пользователям композера. Именно такая закрытость и отталкивает многих - не доверяет народ подобным вещам. Ведь даже дело не в модификации кода, а просто имея исходники всегда можно посмотреть, как реализован тот или иной механизм. Чтобы с бОльшим понимаением его использовать (либо не использовать, если он по сути не подходит). А дока не дает полной картины. Тут же речь не о виндоус-подобной системе идет, а о RTOS, которая является (в случае ее использования) органической частью пользовательского приложения, поэтому пользователь и желает знать, что это там в его программе ворочается. VTK, кстати, тоже, заметьте, не архипопулярно - в конетксте черных финов чаще поминается embedded linux, хотя *nix в качестве RTOS - это отдельный вопрос. Наверняка простой вытесняющий мультитаск свитчер + некий минимальный набор средств межпроцессного взаимодействия лучше ляжет практически на любую real-time и dsp задачу. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться