[_i8088_ 0]

Я работал на AVR Mega 128 под операционкой которую мало кто знает:

PROC. Довольно шустрая OS. И мало требует ОЗУ.

http://www.nilsenelektronikk.no

 

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

 

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

[sqrt 0]

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

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

<{POST_SNAPBACK}>

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

[Гость impatt]

Есть ещё операционка реального времени (не кооперативная :) для микроконтроллеров, целиком на С, только переключатель контекстов на ассемблере. Для AVR и ещё чего-то, лицензия BSD (можно встраивать и не публиковать весь проект, в отличии от GPL). Имеет пару планировщиков (на выбор), есть О1 планировщик, есть возможность подключить всякие навороты типа IPC, TCP\IP. Есть примеры, есть дока (скудновата, IMHO).

Называется XMK

Библиотеки С в комплекте нет, я вот думаю где бы взять для ARM. А то есть в инете, но всё под GPL и все хотят поддержку системных вызовов POSIX (или имитируют их присутствие, добавляя килобайт 50 к бинарю для прошивки во FLASH).

Вот, пытаюсь с ней разобраться. Никто не юзал ? Какие отзывы ? И может, есть какие-нибудь С библиотеки, наподобии AVR-Glibc, чтобы обеспечивали маломальские реентрабельные функции С и не желали бы поддержки системных вызовов POSIX со стороны ОС ?

[si21 0]

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

[Гвоздик 0]

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

[si21 0]

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

<{POST_SNAPBACK}>

Не хочу начинать бессмысленный спор, но интересно, чем же микроконтроллер отличается от процессора в вашем представлении? По большому счету, только набором развитой периферии! Современные МК переплевывают CPU 7-5-летней давности.

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

[bmf 0]

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

<{POST_SNAPBACK}>

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

 

Что вы будете делать когда у вас одновременно нужно как бы две подзадачи

одна медленная другая быстрая. Применение OS в данном случае самое простое и эффективное решение.

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

Ethernet или диск- вы будете сидет внутри пока он вас не отпустит. В случае OS вы спокойно в это время делаете другую задачу.

 

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

 

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

[Andy_Mozzhevilov 0]

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

<{POST_SNAPBACK}>

 

Такие посты обычно пишут люди, которые под ОС ни разу не работали, ну либо виртуалы, типа Ольги Ноновой, чтобы народ подбить на кучу излияний в конферениях :)

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

[Olej 0]

1. Тема хорошая задана была: Параметры оценки архитектуры ОС...

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

 

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

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

<{POST_SNAPBACK}>

- что накладывает неизгладимый отпечаток, сравните, например, с:

http://qnx.org.ru/index.php?option=com_min...um=7&topic=1690

 

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

-. Многозадачность (есть, нет, кооперативная, вытесняющая, набор примитивов для cycl.exec и т.д.)

-. Приоритеты задач (стат, динам, несравниваемые и др.)

-. Особенности переключения задач (контекст, стеки и т.д.)

-. Реализация планировщика.

-. Реализация диспетчера.

-. Оценка преимуществ и недостатков методов планирования/диспетчеризации для конкретных задач.

-. Предотвращение инверсии приоритетов (есть, нет, методы)

-. Реализация искл. доступа к ресурсам.

-. Контроль задач (события, таймеры и др.)

-. Запуск системных и доп. процессов (методы для таймеров, ISR и т.д.)

-. Реализация HAL.

-. API - предоставляемые возможности.

-. Доп. средства (GUI, TCP/IP и т.д.)

-. Общая оценка.

<{POST_SNAPBACK}>

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

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

- и только когда все механизмы POSIX - реализуются, а всё ещё не хватает, вот тогда можно думать о каких либо расширениях... но это очень не скоро ;).

 

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

<{POST_SNAPBACK}>

 

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

 

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

<{POST_SNAPBACK}>

 

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

 

4. Но есть ещё другая крайность - святая вера в то, что RTOS чем-то уж очень принципиально отличаются от GPOS (general purpose OS). См. например, здесь:

http://qnxclub.net/files/articles/RemarksO...TheMargins.html

- это частное мнение, но разработчика с опытом многих и многих лет...

 

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

<{POST_SNAPBACK}>

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

Ручной код будетреализовывать то же самое (stdlib) - но только "горбато" и со множеством субъективных допущений автора...

Наблюдаемая иллюзияллюзия надёжности ручного кода объясняется только простотой и примитивностью механизмов и алгоритмов, реализуемых в ручном коде, на порядки проще, чем альтернативные реализации их в OS.

 

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

[Evgeny_CD 0]

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

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

[Olej 0]

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

<{POST_SNAPBACK}>

 

Посмотрите внимательнее: до самого последнего времени они все отчёты, по истечении некоторого времени от новизны - предоставляли свободно, для этого нужно было только пройти регистрацию, которая ни кого и ни к чему не обязывала ;).

Последнее время у них были какие-то реорганизации... :(

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

[bmf 0]

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

Некоторые свободно лежат на сайтах владельцев 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 0]

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

[Evgeny_CD 0]

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

:cheers: Спасибо!

[Olej 0]

Есть очень интересный новый проект 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 для проектов ... мог бы быть серьёзный толк.