В последнее время прочитал несколько сообщений в русскоязычных конференциях по электронике (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 и т.п. ).

Тут надо пояснить о каких прерываниях идет речь.
В RTOS есть прерывания в контексте RTOS и вне контекста RTOS.
Прерывания "вне контекста" RTOS вообще не видит и на них не влияет. А потому они могут никогда не запрещаться.
Но это не значит, что они не могут взаимодействовать с RTOS.

Друго дело, что писателям RTOS глубоко в лом делать такую фишку поскольку она глубоко аппаратно зависима.

1) Что такое "RTOS" ? Слишком общее название включает и OSEK и VxWorks и QNX. Плохо и непонятно
2) Никакой RT OS не гарантирует RT проект.
2) Маленькому ядру если и нужны прерывания так только от одного тайрмера.
Все остальное на усмотрение разработчика проекта. Ему решать нужно входить после прерывания в скедулер или нет. Да и само прерывание таймера переправлять в ОС придется ручками для каждой борды

Ну эт вы тоже перегнули.
Первые два пункта ликбеза не в тему вообще.

По третьему тоже гигантское заблуждение.
Маленькая RTOS или большая все они решают одну главную задачу - обеспечение параллелизма.
А самая большая проблема параллелизма это с периферией.
Не делать же при живой RTOS программные задержки на ожидании заполнения или освобождения буферов UART, SPI, I2S, DMA и проч.
Все это делается через прерывания и использования в них сервисов RTOS!

По последнему. Если вы получаете фреймворк уже скомпилированный по типу embOS, то никуда не денетесь, а все прерывания пройдут через сепаратор RTOS.
Так же, скажем, и с SDK для Windows CE.

Если бы Вы правильно понимали первые 2 пункта, Вы бы такого не написали...
Есть огромная разница в том как устроены Windows CE или QNX и маленкие ядра, к примеру RTXC.
Последний ничего не знает о периферии и процессоре.... UART, SPI, I2S, DMA и проч. конечно имеют прерывания, но обработчики придется писать .... и будет при этом вызываться планировщик или нет дело девелопера




Не приведи господи с такой ОС поработать

ИМХО, статья несколько лукавая - "смотрите как хорошо в UIA и как не очень хорошо SIA", при этом приводится ряд спорных аргументов против SIA. Но, как ни странно, в целом выводы правильные . UAI имеет тот большой плюс что очень прост в реализации, и просто писать обработчики прерываний в приложениях. И этот подход хорошо подходит для простых OS, где системные структуры (данные с которыми ОС работает при обработке вызова - очереди задач, системные объекты и прочее) достаточно маленькие и простые. Поэтому секции кода с запрещенными прерываниями небольшие и RT страдает несильно.
А теперь рассмотрим ситуацию более сложной системы. У меня, например, есть реальная ситуация когда TNKernel выполняется на CortexM3 в непривилегированном режиме под отдельным специальным супервизором. При этом издержки на tn_interrupt_lock/unlock становяться достаточно заметными (вызываются привилегированные сервисы супервизора через swi), и уже не столь малыми по сравнению с вариантом на SIA. Второй пример (тоже скоро может перестать гипотетическим) - многоядерность. В таком варианте тоже простым interrupt_lock/unlock не обойдешься.
Если брать совсем уж сложные системы - типа Windows/Linux, то они все исповедуют очень развитую модель SIA - DPC/BottomHalf. И делали это они не красоты ради, а потому что выхода просто не было - системные структуры настолько сложны и секции кода их обрабатывающие могут занимать настолько долгое время, что RT был бы совсем уж плох.
Ну а "возвращаясь к нашим баранам" - UIA почти идеален для простых ОС, тут почти без вариантов. Рассматривать вариант SIA, ИМХО, стоит только в том случае если нужен совсем-совсем жестокий RT. Могу сказать в цифрах - я измерял interrupt latency на TNKernel (модель UIA) на lpc1768@100mhz - так максимальное время задержки было примерно 4uS. Оно конечно зависит от того что исполняется в данный момент, при тесте у меня шел активный обмен по UDP echo и сервисы ОС использовались достаточно активно и сторонних прерываний было достаточно. Если кому-то нужен RT более жесткий чем 4uS - то тут явно не процессор и RTOS надо использовать, SIA тут почти не поможет, поэтому все разговоры про SIA в простых ОС - это обычно просто популизм. Да, возможно улучшится незначительно RT - при соблюдении массы условий, но в целом системные вызовы будут работать медленее - так как код будет сложнее, и общее быстродейтсивие вообще может упасть.

Эти пацаны из Express Logic толкают эту свою статью уже лет 6 , если не дольше.
С тех пор наука давно ушла вперед.
И между двумя ихними крайностями есть куча промежуточных решений.
Например та же RL ARM библиотека которая пожалуй покомпактней будет TNKernel может вызывать некоторые сервисы RTOS в незапрещаемых прерываниях.
Т.е. случай напоминающий сегментированную модель прерываний (SIA)
Но строится это на привязке к архитектуре Cortex-M3.

Применение Segmented Interrupt Architecture в малых RTOS - это (ИМХО) просто достаточно
неуклюжая попытка перетащить механизм обработки прерываний из больших OS (в Velocity -из Unix).
Для небольших по своей природе RTOS - это как "авианосец в домашней ванной(с)".

Понятие "малая" RTOS слегка сместилось за последнее время.
Такие RTOS как RTXC, ThreadX, VxWorks, Nucleus и т.д. спокойно нынче размещаются в дешевых чипах на Cortex-M3 или Cortex-M4 даже без внешней памяти.
А в них сегментированные прерывания ключевая фишка. И очень удобная я вам скажу.
Сам их использую вовсю даже в простейших контроллерах узлов оборудования.
Потому что когда у вас в чипе количество периферии генерирующей прерывания переваливает за несколько десятков,
хочешь не хочешь начинаешь искать способы облегчения процедур ISR не отказываясь от сервисов RTOS.
А в этих осях есть четкая градация на легкие и тяжелые ISR. Легкие могут использовать всего один сервис RTOS - это вызов тяжелой ISR.
Но вход в легкие ISR почти такой же быстрый как во FreeRTOS, uCOS и т.д.
А тяжелая ISR может уже использовать почти все сервисы RTOS , которые не приводят к ожиданиям.
Но вход в тяжелую ISR почти повторяет динамическую процедуру создания новой задачи. Т.е. выделение стека, управляющих структур и т.д.

А обязательно использовать именно "тяжелую ISR" (aka DPC/BottomHalf)? Я спокойно выношу всю эту часть в приоритетный поток и вместо приглашения "тяжелой ISR" просто пробуждаю его. "Реальный" реалтайм все равно будет только в легкой ISR, а тяжелые все равно откладываются в очередь.

Ну так у вас значит нет на самом деле легких ISR. Поскольку из реально легкой ISR невозможно передать событие в RTOS напрямую.
А аналогии из десктопных Windows и Линукс здесь не подходят потому как там любые ISR проходят шедулер.
Т.е. они изначально тяжелые даже если их называют top half или fast.

А можно реальный пример такой лёгкой ISR? И как оно взаимодействует с остальным кодом?

http://www.smxrtos.com/articles/techppr/defint.htm



О полном отказе от блокировки прерываний речи не идет , и вдобавок Unfortunately...

Другая интересная статья
http://www.rtos.com/articles/18835
продолжает утввержать, что прерфывания не запрещаются .... При этом скромно молчит о возможностях процессора... или о регистрах типа irq clear (ARM)

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

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

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

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

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

- рекламная

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

Согласен.

Хотел обратить внимание на то, что "Segmented Interrupt Architecture", мякого говоря, неточное название.
Судя по примеру кода в одной из статей, это скорее разделенное обращение к скедулеру, когда статус задач меняется (по семафору ли, другим ли механизмом ) , но скедулер вызывается для запуска первой готовой задачи не сразу, а позднее.
Думаю, что только это может выглядеть как что-то якобы новое....

А по сути минимизация кода ISR и вызов API ядра для дальнейшего запуска(активизации) какой-то задачи есть стандартный подход существующий бог занет сколько времени. Сколько ни ройся в мануале RTXC упоминание о "Segmented Interrupt Architecture" не надешь, зато без всякой рекламы и наукообразия делает ровно то же самое .

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

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

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

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

Несколько замечаний из собственного опытов:
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, что я юзал - коммерческие, и очень толково сделаны).

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


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


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


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


И это есть в TNKernel


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

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

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

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

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

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

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

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

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

Извините, это была опечатка, я имел ввиду обработчик исключения SuperVisorCall - вызывается инструкцией SWI. Когда эта инструкция обрабатывается, то прерывания с более низким приоритетом чем у нее - запрещаются. То есть - явного запрета прерываний нет, а вот неявный - есть.


Это не SIA в терминах данного топика. Вот если бы там был аналог DPC для Windows или BottomHalf для Линукса, и для них был выделен особый уровень приоритета (DISPATCH_LEVEL) - НАД всеми задачами, и подобие очереди - вот это точно SIA.


Она может быть очень удобной и приятной, более того - иногда без нее не обойтись - это единственный способ красиво выйти из непривилегированного режима, например. Но если вдруг понадобится портануться на процессор без SWI - чего тогда делать?


Мне кажется что там очередь есть, посмотрите что isr_evt_set делает и как. Более того - очерель/циклический буфер - это одна из немногих (если вообще не единственная) структур которая позволяет обмениваться данными без взаимной блокировки. Иначе Кейл не смог бы рассказывать нам как он не запрещает прерывания.

Покажите пожалуйста пример такой очереди.

http://www.research.ibm.com/people/m/michael/podc-1996.pdf

Хе-хе, в Keil-е показать не получится. Там используются специальные инструкции эксклюзивного доступа, которые есть у Cortex-M3.
А так Keil для других архитектур использует все те же запрещения прерываний для своих кольцевых буферов.

Присмотрелся, однако, к этой фишке Keil-а с командами эксклюзивного доступа и вижу, что это решение довольно рискованное.
В инструкции на ARMv7-M много связанного с поведением эксклюзивного доступа оставлено на имплементацию, а скажем в доке на тот же STM32 полная тишина про нюансы имплементации эксклюзивного доступа.

Спасибо

Псевдокод из статьи

dequeue(Q: pointer to queue t, pvalue: pointer to data type): boolean
D1: loop # Keep trying until Dequeue is done
D2: head = Q–>Head # Read Head
D3: tail = Q–>Tail # Read Tail
D4: next = head–>next # Read Head.ptr–>next
D5: if head == Q–>Head # Are head, tail, and next consistent?
D6: if head.ptr == tail.ptr # Is queue empty or Tail falling behind?
D7: if next.ptr == NULL # Is queue empty?
D8: return FALSE # Queue is empty, couldn’t dequeue
D9: endif
D10: CAS(&Q–>Tail, tail, <next.ptr, tail.count+1>) # Tail is falling behind. Try to advance it
D11: else # No need to deal with Tail
# Read value before CAS, otherwise another dequeue might free the next node
D12: *pvalue = next.ptr–>value
D13: if CAS(&Q–>Head, head, <next.ptr, head.count+1>) # Try to swing Head to the next node
D14: break # Dequeue is done. Exit loop
D15: endif
D16: endif
D17: endif
D18: endloop
D19: free(head.ptr) # It is safe now to free the old dummy node
D20: return TRUE # Queue was not empty, dequeue succeeded

------------------------
А ну как перед
D19: free(head.ptr) # It is safe now to free the old dummy node
управление передадут какому-нибудь злодею, который сделает head.ptr не валидным( вычистит, а потом положит по этому адресу совсем не то что ожидалось) , а потом обратно ?

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

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

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

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

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

Организовать SIA на примитивах UIA не получится хотя бы потому что на UIA-системах прерывания запрещены во время исполнения обработчика что исключает возможность вложенных прерываний, а вот наоборот - эмулировать UIA на SIA можно без особых проблем, только это не нужно. Например в ранних версиях Linux можно было регистрировать обработчик который вызывается с отключенными прерываниями, сейчас этот флаг тоже формально существует но не рекомендуется

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




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




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

Верно или неверно, я считаю, это с практических позиций - не важно. А, ИМХО, важно то, что, если говорить об армах, то:
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) очепятка вышла

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-приложений. А софт разрабатывается совершенно одинаково.

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



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

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

KDE на порядки сложней чем ваши gsm-станции в которых весь алгоритм строится на конечных автоматах. По поводу "крутых коммерческих ОС" с UIA можете посмотреть доводы епонцев
http://art-linux.sourceforge.net/

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

Тоже из области мифов слегка.
Образы RTOS из потребительской аппаратуры по объемам не уступают доморощенным образам линуксов.
Буквально позавчера пробегала ссылка на китайскую miniOS для MIPS-ов которую суют в журнальные плееры. Ну так ее объем там практически как объем линукса.
А фичей больше при том же объеме, а главное она отлаживается легче, потому как все закоулки оси доступны дешевыми аппаратными отладчиками.
Ну и кто сложнее скажите мне? Оси на MMU не сложные, они просто в большинстве грязно сделаны.
Защиту памяти на самом деле прикрутить к RTOS не так уж и проблематично.
Например я на ARM9 с RTOS с удовольствием включаю защиту адресных пространств интересующих меня участков памяти.
Привилегированный режим ядра вообще фишка стандартная в RTOS.
Защита памяти работает также тупо как и в линуксах, т.е. происходит аборт, но я в отличии от линуксов могу совершенно недорогими средствами проследить весь путь возникновения ошибки по всем извилинам ядра RTOS. Т.е. каждый аборт идет на пользу, а в линуксах бестолку.

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

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

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


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


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

20 тыс строк - это размер голого микроядра, у Linux ядро ~ 200 тыс строк а всего несколько млн - 5 или 8 млн - не помню точно (бОльшую часть кода составляют драйверы).

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

Зачем вы все это пишите? Подозреваете, что мы не знаем осей?
..Ну может быть, ...у каждого свое знание )))

Для сравнения один только бутлодер на моей плате облачного VPN шлюза занимает около миллиона строк.



Совершенно верно.
К слову, накладные связанные с переключением контекста памяти самая главная причина почему этот механизм не применяют в RTOS.

+ кеши

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

Поясняю: господин sasamy написал, что "ОС без ЗАЩИТЫ ПАМЯТИ годятся только для маленьких проектов с крошечным кодом..." Это неверно. Есть отделы которые годами пишут проекты для RTOS без защиты памяти. То что я привёл - это полгода работы отдела (5 чел.) на моей прошлой работе. А вот тот бутлодер о котором вы говорите, что с миллионом строк - вы сами писали? И защищённый (виртуальный) это режим или нет?

Я как раз об этом. А у вас я хочу спросить - в чем же сложность "управления и планирования задачами" в RTOS, там где нет переключений виртуальных пространств?
Повторюсь: мне сейчас понятно одно, что если говорят о SIA для CM3 то это (имхо) - рекламный трюк или бред. Это легковесный процессор для лековесного RTOS.

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

Невероятная сложность может взяться откуда угодно.
Вот тут буквально в соседних ветках обсуждается огромная проблема китайцев.
Они видишь ли хотят урезать объем памяти в GSM модулях до 32M c 64M, но такая беда, что при этом перестает помещаться у них TCP стек.
Вопрос, на кой TCP стеку аж целых 32M? При том том, что любой студент знает, что стеку lwIP нужно ну максимум 200К
Я думаю у китайцев какие-то невероятные сложности которые они сами себе создали.

Или из другой области пример. Читаю анонсы Windows 7 для смартфонов, и с удивлением обнаруживаю, что оказывается она до сих пор однозадачная!
И после этого вы будете говорит о водоразделе и всем таком. Они на Win7 не смогли сделать многозадачность!!!
Это когда еще 10-ть лет назад на Salvo на PIC12 я имел многозадачность в полный рост. Умел управлять лампочкой и кулером одновременно и независимо друг от друга. (шутка, если кто не понял )

Автор книги http://en.wikipedia.org/wiki/Code_Complete
рассказывает например про количестве ошибок в коде - в среднем по индустрии 15-50 ошибок на 1000 строк кода при структурном программировании или смешаной технике, в коде Microsoft детектируется 10-20 ошибок при внутреннем тестировании и примерно 0,5 на 1000 строк обнаруживается в релизах. Применяя специальные подходы в программировании, например в аэрокосмической индустрии ошибки не обнаруживаются даже в коде из 500 000 строк. Вы на чем программировали в этом отделе ? Для примера код windows server 2003 (http://en.wikipedia.org/wiki/Source_lines_of_code) содержит 50 млн строк - можно прикинуть - ошибок там около 25000.

Если мегабиты не мешать с килобайтами, то становится понятно, откуда растут сложности. И стеку-то совсем и не нужны дополнительные 32 мегабита, просто с остальной начинкой он в такой объем уже не помещается.

Круто! Ядро Линукса версий 2.2 со всеми драйверами было меньше...
У нас Chromatography Data System с блэкджеком и шлюхами драйверами для сотни хроматографов, анализатором хроматограмм и редактором хим. формул и централизованным хранилищем данных имеет лишь чуть большее количество строк

CCS 3.3 (среда TI), DSP/BIOS 5.xx. Процессор VC5509a + 16 Mb SDRAM-памяти, работающей на 96 МГц-ах. На плате 2 таких проца + ещё три простых CM3 (Luminary).
Проект - базовая станция транковой связи стандарта APCO-25. (Их развёрнуто 5 шт. в одном из областных центров, удачно прошли испытания в этом мае, 20-50 км радиус - устойчивая связь с автомобилем). В принципе, можно сказать, что полноценная альтернатива моторолы.
Кстати с недавнего времени DSP/BIOS переименован в SYS/BIOS и перенесён на CM3 и ARM9. Народ уже пробует его юзать на этих процессорах (судя по зарубежным форумам).