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

Сообщение отредактировал kikos - May 19 2011, 09:50

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

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

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

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




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

Сообщение отредактировал kikos - May 19 2011, 12:06

ИМХО, статья несколько лукавая - "смотрите как хорошо в 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)

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



Сообщение отредактировал kikos - May 23 2011, 10:06

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

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

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

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

- рекламная

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

Согласен.

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

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


Сообщение отредактировал kikos - May 24 2011, 08:02