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

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

Сообщение отредактировал sasamy - May 31 2011, 23:39

Тоже из области мифов слегка.
Образы 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. Народ уже пробует его юзать на этих процессорах (судя по зарубежным форумам).