"Тормозные" RTOS и запрещение прерываний Опции

[yuri_t]

В последнее время прочитал несколько сообщений в русскоязычных конференциях по электронике (Electronix, Caxapa)
о том, что есть замечательные варианты повышения быстродействия RTOS - "без блокировки прерываний вообще,
без spin-lockов, без циклов"(цитата) .

На эту тему замечу:

1) Системы с запрещением прерываний на время изменения системных данных надежно работают в любых проектах
и с любыми CPU.

2) Системы без запрещения прерываний на время изменения системных данных можно разделить на две категории

- системы, которые работают только в проекте автора (как правило, единственном) - здесь без комментариев

- Segmented Interrupt Architecture - системы, в которых прерывания не запрещаются, а просто останавливается
переключатель контекста. Если во время прерывания появляется условия, требующие переключения контекста,
то эти условия помещаются в специальную очередь и обрабатываются вне прерываний.
Такой подход кажется привлекательным на первый взгляд, но на практике имеет столь серьезные недостатки,
что мне известно только 2 коммерческих RTOS (CMX, Velocity) использующих такой подход. Для тех, кому
интересны детали, рекомендую статью W.Lamie (автор ThreadX RTOS) "Pardon the Interruption: Two Approaches to
RTOS Interrupt Architectures"

В общем, если вы не хотите получить случайные, совершенно непонятные баги и проклинать тот день, когда решили
связаться с операционной системой - используйте RTOS с запрещением прерываний (VxWorks, pSOS, ThreadX/Nucleous,
TNKernel, FreeRTOS, scmRTOS и т.п. ).

[yuri_t]

Статьи Ralph Moore и David Kliedermacher я читал (и не только их).

Здесь (ИМНО) две вещи

- техническая

об этом хорошо написал VslavX в этом топике

- рекламная

Например, собрался инженер покупать RTOS - a их на рынке несколько десятков и все совсем не дешевые.. Какую
выбрать? А тут ему ребята из компании, у которой RTOS имеет Segmented Interrupt Architecture и говорят: " У нас -
продвинутая архитектура, а у других - каменный век" и далее в таком же духе..
К чести производителей коммерческих RTOS, таких компаний очень мало, но "умы смущают©" - ведь большинство
инженеров не связаны непосредственно с разработкой RTOS и, следовательно, не посвящены в тонкие детали
дизайна таких систем.

[sasamy]

А тут ему ребята из компании, у которой RTOS имеет Segmented Interrupt Architecture и говорят: " У нас - продвинутая архитектура, а у других - каменный век"

И ведь они совершенно правы

[kikos]

И ведь они совершенно правы

не так давно в России кто-то запатентовал "бутылку стеклянную" ... и был бы "прав" до сих пор, если бы автора не занесло потребовать от пивных компаний отчислений за использование его изобретения. Тут его патент и кансельнули...

Сообщение отредактировал kikos - May 25 2011, 07:15

[sasamy]

не так давно в России кто-то запатентовал "бутылку стеклянную" ... и был бы "прав" до сих пор, если бы автора не занесло потребовать от пивных компаний отчислений за использование его изобретения. Тут его патент и кансельнули...

Вы об этом ?
http://electronix.ru/forum/index.php?showtopic=69735

только я не понял какое отношение патенты имеют к типу обработки прерываний в ОС

[evg123]

Несколько замечаний из собственного опытов:
1) На Cortex-M3 (Luminary) я использовал Keil-овскую RTOS "RTL"; 2) на DSP TMS320VC5509a - техасовскую DSP/BIOS.

В первом случае: a)keil декларирирует, что RTL не запрещает прерываний, что хотите, то и делайте. б) RTL предоставляет ряд механизмов: семафоров, "сигналы" (ихнее собственное понятие), с помощью которых ISR может взаимодействовать с шедьюлером RTOS.
Можно использовать как UIA так и SIA - архитектуры. Я пользовался как тем так и другим. Но официально KEIL рекомендует пользоваться SIA-подходом. Они говорят, что "у нас есть замечательный механизм сигналов; вы пишете ISR, который просто выставляет сигнал, а какая-то высокоприоритетная задача его ожидает и отрабатывает действие, в этом случае не необходимости иметь высокоприоритетные/низкоприоритетные прерывания - так как ISR выполняют только установку бита сигнала, который ловится "фактическим обработчиком прерывания" - задачей, которая ожидает этот сигнал. И этот фактический обработчик прерывания - он уже имеет приоритет". Это - они говорят - наиболее правильный подход. Т.е. SIA в чистом виде. Этим способом я пользовался. Т.е. ISR-обрабочик SPI у меня просто устанавливал сигнал, и дальше высокприоритетная легковесная задача "делала своё дело". Передача сигнала операционкой RTL делается очень быстро. (Можно посмотреть спецификации этой RTOS - они есть в документации - я на вскидку здесь их не приведу). Второй вариант: ISR обработки SPI при приёме данных может формировать небольшой массив из байт (например 32 байта) и по готовности массива отправить сигнал в высокоприоритетную задачу-обработчик, которая берёт этот массив и кдадёт его в почтовый ящик для следующей по ходу задачи. То есть ISR уже не тупая, а более "интеллектуальная". Т.е. возможны гибкие решения. И главное, что всё работает быстро.

Во втором случае DSP/BIOS - мощная RTOS, (кейловская RTL - это малютка по сравнению с ней). а) DSP/BIOS может по своему усмотрению запрещать прервания.
б)даёт ряд механизмов, из которых ISR может взаимодействовать с операционкой - в частности: семафоры (которые могут ожидаться задачами с определёнными приоритетами); вызовы программных прерываний SWI - software interrupts; выделение памяти из специальных memory pool-ов и отправка их в "очереди" или "почтовые ящики" (это стандартные "системные" объекты RTOS) - тут обилие всяческих вариантов. Т.е. можно с легкостью построить как SIA так и UIA - модель. в)Есть также изумительная абстракция драйвера. Кто-то со стороны может написать определённым образом "оформленный" модуль - "драйвер", и вы можете его подключить к своей программе и общаться с устройством на уровне "пакетов". Послал пакет/получил пакет. И всё. Но по сути тут вот что: вы из контекста задачи кладёте в некую "скрытую", организованную на memory pool-е, очередь и из контекста вашей задачи запускаете устройство в работу (например SPI или McBSP). Прерывание (ISR) этого устройства из контекста прерывания разгребает эту очередь (т.е., например отправляет все её пакеты). Если очередь переполнена (вы пытаетесь положить больше пакетов, чем позволяет её максим. длина), то ваша задача "засыпает", и проснётся только после того, когда такая возможность появится. Это порисходит всё внутри RTOS, а вы пользуетесь примитивным стандартным вызовом функции драйвера - "отправить очередной пакет".

Мой лично вывод - RTOS должна позволять и то и это (и SIA и UIA). А если нет, то что-то тут не так. (Но те RTOS, что я юзал - коммерческие, и очень толково сделаны).

[VslavX]

Несколько замечаний из собственного опытов:
1) На Cortex-M3 (Luminary) я использовал Keil-овскую RTOS "RTL";
...
В первом случае: a)keil декларирирует, что RTL не запрещает прерываний, что хотите, то и делайте.

Может быть "RTX" имелся ввиду?
Когда они пишут что не запрещают прерывания - то лукавят, конкретно в порту для CM3 используется исключение SVC. Ессно, при вызове обработчика инструкцией SVC приоритет прерываний снижается до фактического запрета. Да, очереди событий они сделали прикольные, но - жрут память, и беспомощны перед переполнением. Я точно не помню, но там кажется только один единственный сервис может быть вызван из ISR - "положить событие в очередь".

Можно использовать как UIA так и SIA - архитектуры.

Нет, насколько я понял RTX не поддерживает SIA в понимании данного топика.

Я пользовался как тем так и другим. Но официально KEIL рекомендует пользоваться SIA-подходом. Они говорят, что "у нас есть замечательный механизм сигналов; вы пишете ISR, который просто выставляет сигнал, а какая-то высокоприоритетная задача его ожидает и отрабатывает действие, в

Это стандартная практика, я много лет пользуюсь ей в TNKernel, но к SIA это не имеет никакого отношения, ИМХО.

Во втором случае DSP/BIOS - мощная RTOS, (кейловская RTL - это малютка по сравнению с ней). а) DSP/BIOS может по своему усмотрению запрещать прервания.
б)даёт ряд механизмов, из которых ISR может взаимодействовать с операционкой - в частности: семафоры (которые могут ожидаться задачами с определёнными приоритетами); вызовы программных прерываний SWI - software interrupts; выделение памяти из специальных memory pool-ов и отправка их в "очереди" или "почтовые ящики" (это стандартные "системные" объекты RTOS) - тут обилие всяческих вариантов.

Это все есть (кроме SWI который есть не на всякой архитектуре и вообще особо не нужен, и даже вреден если Вы пишете мультиплатформенный софт) и в TNKernel, которая ни разу не SIA.

пакетов, чем позволяет её максим. длина), то ваша задача "засыпает", и проснётся только после того, когда такая возможность появится. Это порисходит всё внутри RTOS, а вы пользуетесь примитивным стандартным вызовом функции драйвера - "отправить очередной пакет".

И это есть в TNKernel

Но те RTOS, что я юзал - коммерческие, и очень толково сделаны).

Ага, TNKernel тоже... ну - Вы поняли , за исключением того что она свободная, и даже свободней чем, скажем, софт под GPL

[evg123]

Может быть "RTX" имелся ввиду?

Да, точное название RL-RTX.

...конкретно в порту для CM3 используется исключение SVC...

Я режим SVC отключал сразу еще до запуска RTX, так как у меня сразу выбрасывалось исключение (не помню точно что, но что-то типа "в режиме пользователя что-то где-то запрещено"). Сейчас я уже не вспомню, почему отказался от преимуществ использования SVC, тогда он меня сильно напрягал.

Нет, насколько я понял RTX не поддерживает SIA в понимании данного топика.

Я так понял, что SIA (по статье http://www.rtos.com/articles/18835) - это возможность обработки критических секций вне ISR. Так это как раз то о чём я и говорю: прерывание только генерирует сигнал ( isr_evt_set(...) ), задача-обработчик (типа "ISR2" в контексте упомянутой статьи) - получает управление, обрабатывает данные в критических секциях - используя mutex-ы или замки на ресурсы - и вот вам и решение - никакие прерывания запрещать в теле самой ISR не надо - она только генерирует сигнал. И никакие прирывания в задаче-обработчике запрещать не надо - она пользуется mutex-ами, замками и прочей стандартной байдой для защиты критических секций данных. Чем не SIA? Или я что-то не догоняю?

Это все есть (кроме SWI который есть не на всякой архитектуре и вообще особо не нужен, и даже вреден если Вы пишете мультиплатформенный софт) и в TNKernel, которая ни разу не SIA.

SWI - в DSP/BIOS - крайне удобная вещь. Это нечто промежуточное между стандартным "аппаратным прерыванием" и "задачей". Очень выгодно использовать, чтобы сделать аппаратное прерывание - действительно лёгким. Аппаратное прерывание выполняет своё элементарное действие и перед возвратом вызывает SWI - программное прерывание, которое, в свою очередь, запустится, как только все аппаратные прерывания отработаются. Этот как раз именно то самое "ISR2" в вышеупомянутой статье.

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

В RL-RTX нет очереди событий - это битовая маска. Событие - это установить бит - как семафор, только быстрее.
Кроме этого из прерываний можно:отправлять и получать данные в почтовый ящик (это то, что Вы, наверное, имели в виду), устанавливать семафор, и определить идентификатор задачи, которую это прерывание прервало.

[AlexandrY]

Я так понял, что SIA (по статье http://www.rtos.com/articles/18835) - это возможность обработки критических секций вне ISR.

Я думаю вы не поняли. ISR2 по идеологии сегментированных прерываний не может быть обычной задачей.
Т.е. должна иметь отличную от задач управляющую структуру. Чтобы ISR2 не могла быть идентифицирована как задача, и чтобы ее не могли приостановить, прервать, удалить, понизить приоритет другие обычные задачи.
В Keil-е нет настоящей модели SIA, там есть только задачи и обычные ISR.

Как фича ISR2 появляется только в сравнении с Keil-oм толстых осях. Где реально крутятся многие десятки задач. О некоторых из которых вы даже не подозреваете ибо они не вами написаны. И вам нужен надежный механизм разруливания проблем ограниченного процессорного времени.

Думаю в DSP/BIOS подобия ISR2 также нет, (поправьте если ошибаюсь), поскольку DSP от TI не выполняют роль процессоров приложений с кучей функциональности им там для этого всегда ARM в подмогу дают

[evg123]

Я понимаю, что я немного не в тему, но всё равно, раз уж влез, то продолжаю:

Я думаю вы не поняли. ISR2 по идеологии сегментированных прерываний не может быть обычной задачей.
Т.е. должна иметь отличную от задач управляющую структуру.

Я не вижу, зачем нужны такие навороты для CM3. Это слабый процессор и, я считаю, совсем не предназначен для таких наворотов. А что качается самой идеи сегментированного прерывания - то она легко организуется как указано выше - на высоко-приоритетной задаче. Программист сам всегда знает, для чего какая задача у него предназначена. Он выделяет задачу, назначает ей высокий приоритет, и сам организует "механизм" сегментированного прерывания - то что keil'овцы и рекомендуют делать в своих офиц. дпокументах.
А что касается Cortex A8 - там как бы тоже всегда был выбор: Linux - open source - пожалуйста, Linux Montavista (softreal-time) - пожалуйтса, RTLinux (hard realtime) - пожалуйста, MentorGraphics Nucleus ( QNX-архитектура "микроядра" но для армов) - пожалуйста. В этих условиях новой операционке со "спец фичей" не очень-то легко отвоевать себе позиции.

Думаю в DSP/BIOS подобия ISR2 также нет, (поправьте если ошибаюсь)...

Механизма, чтобы отправить изменения системных данные в очередь и отложить их изменение в како-то специфичном системном потоке - такого точно нет.
В DSP/BIOS есть три вида контекстов: контекст аппаратного прерывания, контекст программного прерывания и контекст задачи. Программное прерывание - то же что и аппаратное, но не привязано ни к какой аппаратуре и их вектора расположены в таблице векторов после всех векторов аппаратуры, и приоритет, соответственно ниже всех аппаратных. Вызываются ассемблерной инструкцией. Программных прерываний может быть много. То есть спец. контекста "ISR2" - нет. Но по сути - "ISR2" - этим может стать именно программное прерывание. Оно может (при желании) быть непрерываемым, неизменяемым в плане приоритета и.т.д. Я тут вижу полную аналогию со статьёй. Вот только у меня законный вопрос: что будет, если низкоприоритетная задача захватит "замком" критические данные, а ISR2 как раз захочет их изменить? Зависать-то она не имеет права. Т.е. ISR2 должна быть всё-таки приоритетной задачей или нужно предусмотреть стандартную "борьбу" с "инверсией приоритетов", которой в DSP/BIOS нет (по крайней мере раньше не было). В данном случае - это мож. быть - повысить приоритет "замка", и автоматически - задачи, которая его захватила.

...им там для этого всегда ARM в подмогу дают

Масса процессоров типа 6424, 6477 (трёхядерник), 6618 (4 ядра - базовая станция GSM/или полноценная радиорелейка на одном кристалле) - предназначены для работы с громадным числом задач обработки радио/видео/голоса причём с жесточайшими требованиями по реал-тайму. Там ВСЕГДА присудстуют как задачи с низкими, так и задачи с высокими приоритетами. И работают они с большим объёмом периферии (большое число стандартных многоканальных и специфических интерфейсов, есть даже SATA, 64 DMA-канала). Да и уменя в одном из проектов в DSP/BIOS крутилось около 70 задач. Если ж брать OMAP/DaVINCI, то ARM там нужен только для одной цели - прикрутить дисплей с оконной оболочкой KDE или WinCE - т.е. дать пользователю (который держит в руках наладонник, видеокамеру или прибор УЗИ - привычный интерфейс. Для этого DSP- совершенно не приспособлены.

Мне кажется что там очередь есть, посмотрите что isr_evt_set...

К сож. нет keil-а под боком, чтобы посмотреть. Но на 99.9% уверен, что очереди нет. У каждой задачи есть специальное "системное" слово на 16 бит, и каждой задаче можно передать 16 событий (по биту на каждое событие). isr_evt_set() - по-просту устанавливает соответствующий бит в этом слове задачи и специальным механизмом программирует вызов "шедьюлера" сразу по выходу из прерывания. "Шедьюлер", по вызове тот-час же передаёт этой задаче управление.

[AlexandrY]

Я не вижу, зачем нужны такие навороты для CM3. Это слабый процессор и, я считаю, совсем не предназначен для таких наворотов.

Это неверно, CM3 пришел на смену вариантам ARM9 без MMU. А это очень сильные приложения включая бортовые компы.

MentorGraphics Nucleus ( QNX-архитектура "микроядра" но для армов) - пожалуйста.

Про нуклеус вы я вижу не в курсе. Можем обсудить в другой ветке если интересует.

Масса процессоров типа 6424, 6477 (трёхядерник), 6618 (4 ядра - базовая станция GSM/или полноценная радиорелейка на одном кристалле) - предназначены для работы с громадным числом задач обработки радио/видео/голоса

6618 - довольно примитивный проц с точки зрения богатства приложений. Один UART, один SPI, отсутствие чего либо относящегося к HMI, нет MMU.
Это масштабируемый коммуникационный шлюз и не более. Конечно он может поддержать и 100 и больше задач. Но это однотипные задачи, ну может разделенные на несколько функциональных доменов. Сюда SIA точно не нужно, все делается простым клонированием задач.
Т.е. пример явно не в тему.

[evg123]

Это неверно, CM3 пришел на смену вариантам ARM9 без MMU. А это очень сильные приложения включая бортовые компы.

Верно или неверно, я считаю, это с практических позиций - не важно. А, ИМХО, важно то, что, если говорить об армах, то:
1) есть ARM-процессоры c MMU: ARM9 (99% -- разве что кроме LPC29xx), ARM-CA8, CA10 (который анонсирован и сейчас в разработке) и
2) есть ARM-процессоры без MMU: ARM7, CM3, LPC29xx.
Первые (c MMU) - имеют характеристики: тактовая - от 200 МГц и выше; динамическая память DDR2 и выше; обилие переферии; (упор или только) BGA-корпуса, количество ног 300 и выше; сложные операционки типа Linux-embedded, поддерживающие страничную память или на худой конец - виртуальное адресное пространство.
Вторые (без MMU) - имеют характеристики: тактовая - до 120 МГц; статическая память SRAM (единственный CM3, поддерживающий SDRAM ("DDR1"), который я сейчас знаю - это LM3S2B93 ), бедная переферия; (упор или только) TQFP-корпуса, количество ног 150 и ниже; простые операционки типа RTX, ucLinux и т.д. - все задачи крутятся в общем адресном пространстве.
CM3/CM4 - это развитие второй ветки, CA10 - это развитие первой ветки.

Про нуклеус вы я вижу не в курсе. Можем обсудить в другой ветке если интересует.

Я имел в виду QNX нейтрино (спутал Nucleus и Neitrino) очепятка вышла

6618 - довольно примитивный проц с точки зрения богатства приложений.
Один UART, один SPI, отсутствие чего либо относящегося к HMI, нет MMU.

http://focus.ti.com/docs/prod/folders/prin...320tci6618.html (чтобы мы имели в виду одно и то же)
Этот проц решает исключительно сложную задачу. (Он специально заточен под её решение).
MMU у них у ВСЕХ нет - без него всегда обходились. И HMI им не нужен.
А попробуйте ка на арме сделать базовую станцию GSM? Как вам такое приложение? Покруче текстового редактора в KDE будет с точки зрения real-time а?
Вопрос не в том, что это обработка сигналов. А в том что это 4 полноценных 1.25 ГГц-овых ядра, в которых крутятся сотни совсем НЕ однотипных задач (написаные под, ИМХО, крутую ось). "Однотипно" только то, что они относятся тем или иным боком к "обработке сигнала". А во всём остальном это задачи с разными приоритетами, которые обмениваются между собою очередями данных, выставляют семафоры, ставят замки, и т.д. Это происходит в жесточайшем риалтайме - и, кстати без малейшего намёка на SIA. Средства взаимодействия между ядрами - стандартные - общие области памяти, аппаратные семафоры, атомарные инструкции, защищённый обмен сообщениями между задачами с использованием аппаратных средств и т.д. То же самое делают любые задачи в любой ОСи, например в Linux-е. С точки зрения любой ОСи - она вообще не знает что такое "обилие разноплановых приложений" - она лишь разгребает семафоры, переключает приоритеты, реагирует на события - ну, вы поняли, к чему я
А что касается виртуальной памяти - в DSP это и не надо. Всё должно быть заранее отлажено, прежде чем базовая станция выйдет на рынок. Виртуальная память - что она, собственно такое? Возможность ликвидировать процесс, если он себя плохо ведёт, не повредив при этом другие процессы. И всё. По принципу "если ты дурак - то чего другие от тебя должны страдать". Больше я тут не вижу ничего. В DSP этого не требуется, но с другой стороны, операционка должна, задействовать такие аппаратные ресурсы и обрабатывать такое число событий, которые и CA8 не снились.
Посмотрите на переферию 6477 - это тоже, самое только вы сможете поиметь "богатство" DSP-приложений. А софт разрабатывается совершенно одинаково.

[AlexandrY]

Верно или неверно, я считаю, это с практических позиций - не важно. А, ИМХО, важно то, что, если говорить об армах, то:
1) есть ARM-процессоры c MMU: ARM9 (99% -- разве что кроме LPC29xx), ARM-CA8, CA10 (который анонсирован и сейчас в разработке) и
2) есть ARM-процессоры без MMU: ARM7, CM3, LPC29xx.

Это то к чему? В смартфоне задач меньше крутится чем в сетевом принтере. О сложности управления и планирования задачами ничего эта классификация не говорит.

Этот проц решает исключительно сложную задачу. (Он специально заточен под её решение).
MMU у них у ВСЕХ нет - без него всегда обходились. И HMI им не нужен.
А попробуйте ка на арме сделать базовую станцию GSM? Как вам такое приложение? Покруче текстового редактора в KDE будет с точки зрения real-time а?

Да не решает он никакую сложную задачу. Все там делается тупым наращиванием количества задач.
Что там сложного в базовой станции то? Парсить пакеты десятка протоколов да распихивать их по буферам. Ну параллельно демодулировать по мелочи. Не будь их протоколы засекречены и хардваре продаваться по NDA то тут бы все делали эти станции, уверяю вас.
Каждая DSP задача довольно легко профилируется, потому что каждая из них довольно короткая. Потом их длительности суммируют и смотрят критерий 0,7. И все, больше там делать нечего!
А главное, задачи этого монстра не меняются всю его жизнь! Он должен только в среднем поддерживать дикую производительность, держать ее гарантировано во что бы то ни стало у него задачи нет. Потому и про SIA там не знают.

А вы попробуйте медиапоток декодировать на экран, чтоб все было синхронно и видео, и аудио (многоканальное) и анимация и без фликера и на проце за 10 баксов и транспортном канале с изменяющейся полосой пропускания. Эт вам не базовая станция какая-нибудь.

[evg123]

Это то к чему? О сложности управления и планирования задачами ничего эта классификация не говорит.

Одни должны управляться простыми ОСями, другие сложными. Что такое ось? Это два кита: а)система управления задачами (процессами) и б)файловая система. Для embedded-приложений первой категории (с MMU и сложной переферией) для того чтобы полностью задействовать потенциал CPU необходима ОСь типа Linux, WinCe или другая подобная им, поддерживающая виртуальную адресацию. Это объёмная ось просто ввиду наличия MMU и связанной с ним переферией (поддержка защищённого режима выливается в большой круг задач: поддержка таблиц дескрипторов первого и второго уровней; поддержка TLB-кэширования; поддержка контекста для аппаратных прерываний). Т.е. аппараное прерывание - это что? Это сохранение контекста задачи, переход в режим ядра, включение контекста данного аппаратного прерывания, по отработке - передача управления планировщику, который захочет - восстановит прерванный процесс, а не захочет - то запустит другой процесс, который находился в ожидании. А процесс восстановления контекста - это довольно долгое и хлопотное дело - режим то защищённый. Такую ось с кондачка не напишешь - их всего-то на целый мир две-три штуки: Linux и всё что на её основе, WinCe и возможно QNX ( там микроядро тоже частично поддерживает защищённый режим - хотя я глубоко не лез). Такая ось тянет за собой и развитую файловую систему, без которой она по-просту не загрузится (удалённо, с флэши или ещё откуда). Естественно диспетчеры задач там сложные - слишком много всего надо делать, чтобы их переключать.
Для второй категории (без MMU), ИМХО, основой оси является диспетчер задач. В файловой системе как необходимом элементе оси надобности нет. Там в сравнении с первыми -- простейшие таблицы контекстов задач и простейшие условия активации задач. Там, по определению, не может быть ничего сложного. Теперь что такое планирование? Это активация задачи в соответствии с приоритетом и условием активации (по принципу задача имеет высокий приоритет но ждёт семафора; семафор поступил - задача активируется, а всё что работает сейчас - приостанавливается). И всё. Что такое диспетчер задачи - это на ассемблере написанная функция - короткая (см. исходники RTL-я), которая активируется по системному таймеру или после аппаратного/ программного прерывания). Она просматривает эти контексты и различные условия активации задач - не появилось ли что-то новое, что требует запустить вот эту задачу, а текущую приостановить. И всё.
Нового тут придумать невозможно. Разве что сделать поддержку какого-нибудь хитрого режима супервизора (но я уверен - это не есть жизненно важная фича). Какие системные данные? Где? Мне сейчас понятно одно, что если говорят о SIA для CM3 то это (имхо) - рекламный трюк или бред (ввиду вышеописанного).

Да не решает он никакую сложную задачу.
Что там сложного в базовой станции то?

Здрасти! Если вы когда-нибудь сталкивались с книгой Б.Скляр "Цифровая связь" - то будьте уверены: все 1000 (или около того) страниц запихано в этот CPU.
Эта ось позволяет организовывать очереди, семафоры, пайп-лайны, замки; поддерживает три абстракции драйверов (в зависимости от типа приложения), три вида контекстов задач; стандартные средства для работы с динамической памятью (стандартный heap); ряд специальных средств работы с памятью (типа memory pool); средства для обеспечения взаимодействия между ядрами. Раз это всё есть, значит это кому-то надо? По крайней мере, перечисленное (это не всё а только основное) позволяет реализовать приложение ИМХО покруче в плане "сложности управления и планирования задачами", чем бортовой комплекс на арме без mmu, про который вы говорите. Да вы сами сравните возможности той системы с тем, что я сейчас привёл.

А вы попробуйте медиапоток декодировать на экран, чтоб все было синхронно и видео, и аудио (многоканальное) и анимация и без фликера и на проце за 10 баксов и транспортном канале с изменяющейся полосой пропускания. Эт вам не базовая станция

Согласен - за 10 баков базовую станцию не построить. Разве какой-нить наладонник. (шутка).

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

20 тыс строк - для embedded проекта это много или мало? Для сравнения Qt4.7 - где-то порядка 500 тыс. строк.

Защиту памяти на самом деле прикрутить к RTOS не так уж и проблематично.
Например я на ARM9 с RTOS с удовольствием включаю защиту адресных пространств интересующих меня участков памяти.

Вы что, сами делаете двухуровневые таблицы дескрипторов?

[LightElf]

Вы что, сами делаете двухуровневые таблицы дескрипторов?

Ну зачем страшными словами ругаться? Защита памяти и виртуальная память - мягко говоря не одно и то же. Сложные таблицы дескрипторов нужны для организации виртуальной памяти. Используя MMU только для организации защиты областей можно получить массу бонусов копеечной ценой. Например защита от переполнения стека, защита таблицы векторов прерываний от случайной модификации и т.д.

[kikos]

Используя MMU только для организации защиты областей можно получить массу бонусов копеечной ценой. Например защита от переполнения стека, защита таблицы векторов прерываний от случайной модификации и т.д.

+ кеши