FreeRTOS возможно и не требует MMU и Memory Protectrion модулей, но Linux уже не встанет.
FreeRTOS разрабатывалась в те времена, когда рядовому разработчику дотянуться до микропроцессора (не MCU, а MPU) было очень трудно. Да и SDRAM память в 32 мегабайта стоила прилично. А многозадачности хотелось. Сегодня можно свободно купить lpc31xx за гроши (менее $5) и поставить туда SDRAM от Hynix на 32 мегабайта за $1.5! И на этом железе можно свободно развернуть и Linux (если главное требование — скорость и стоимость разработки) и полноценный вариант FreeRTOS со всеми защитами памяти и пр. (если требуется ОСРВ) или ещё, что душеньке угодно. И главное — это будут полноценные ОС, процессы которых не могут случайно залезть в ядро и преврать жизнь разработчика в АД.
Я для себя, как для разработчика embedded систем, давно решил: ОС нужна только тогда, когда надо защитить одну ветвь выполнения от другой. В любом другом случае можно по-быстрому наклепать систему параллельно выполняемых задач и на этом успокоиться (хотя такое нужно редко). В качестве примера приведу случай из практики. Мы разрабатывали для стороннего заказчика аппаратную платформу (АП). Под АП подразумевается собственно железка (А) и уровень аппаратных абстракций (П, или, правильнее, — HAL). HAL нужен для того, чтобы программисты заказчика могли писать задачи для железки не зная её архитектурных особенностей. Для них мы предоставляем Си-шный интерфейс к железке, выраженный очень простыми и понятными терминами.
Когда уже казалось, что проект сдан, стали поступать многочисленные жалобы от них. Якобы наша железка ведет себя не стабильно. Отчасти это в том проекте и было так, процессор (только что вышедший) оказался редкостным Г, но были и другие причины: в своих программах разработчики заказчика, сидя в достаточно стесненных условиях (рамы мало, скорость процессора не велика), вели себя так же, как на полноценном ПК. Удобней передать в стек 15 КБайт данных — передам. Рекурсивная функция — пожалуйста. В итоге стек начал переполняться и программа начинала выкидывать фокусы (работа превратилась в морской бой, при пуске устройства никогда не знаешь заранее, что отвалится). Прикручивание тормозящей все и вся защиты стека дало мало: есть же ещё разыменования указателей и много других способов залезть куда не надо. Из-за их ошибок происходило повреждение памяти, где находился наш код HAL и после этого происходили самые невероятные вещи. Намучились мы тогда здорово…
В следующем проекте мы специально выбрали микропроцессор (MPU) и написали свою маленькую ОС с защитой памяти ядра (ядром являлся наш HAL) и системными вызовами. Получилась ОС с одной задачей, ядро — HAL, задача — прикладная задача заказчика. Ни одного сообщения, подобного тому, которое получали по прошлому проекту, в этот раз не было. Вот тогда мы поняли, зачем в действительности нужны операционные системы в embedded…
FreeRTOS возможно и не требует MMU и Memory Protectrion модулей, но Linux уже не встанет.
FreeRTOS разрабатывалась в те времена, когда рядовому разработчику дотянуться до микропроцессора (не MCU, а MPU) было очень трудно. Да и SDRAM память в 32 мегабайта стоила прилично. А многозадачности хотелось. Сегодня можно свободно купить lpc31xx за гроши (менее $5) и поставить туда SDRAM от Hynix на 32 мегабайта за $1.5! И на этом железе можно свободно развернуть и Linux (если главное требование — скорость и стоимость разработки) и полноценный вариант FreeRTOS со всеми защитами памяти и пр. (если требуется ОСРВ) или ещё, что душеньке угодно. И главное — это будут полноценные ОС, процессы которых не могут случайно залезть в ядро и преврать жизнь разработчика в АД.
Я для себя, как для разработчика embedded систем, давно решил: ОС нужна только тогда, когда надо защитить одну ветвь выполнения от другой. В любом другом случае можно по-быстрому наклепать систему параллельно выполняемых задач и на этом успокоиться (хотя такое нужно редко). В качестве примера приведу случай из практики. Мы разрабатывали для стороннего заказчика аппаратную платформу (АП). Под АП подразумевается собственно железка (А) и уровень аппаратных абстракций (П, или, правильнее, — HAL). HAL нужен для того, чтобы программисты заказчика могли писать задачи для железки не зная её архитектурных особенностей. Для них мы предоставляем Си-шный интерфейс к железке, выраженный очень простыми и понятными терминами.
Когда уже казалось, что проект сдан, стали поступать многочисленные жалобы от них. Якобы наша железка ведет себя не стабильно. Отчасти это в том проекте и было так, процессор (только что вышедший) оказался редкостным Г, но были и другие причины: в своих программах разработчики заказчика, сидя в достаточно стесненных условиях (рамы мало, скорость процессора не велика), вели себя так же, как на полноценном ПК. Удобней передать в стек 15 КБайт данных — передам. Рекурсивная функция — пожалуйста. В итоге стек начал переполняться и программа начинала выкидывать фокусы (работа превратилась в морской бой, при пуске устройства никогда не знаешь заранее, что отвалится). Прикручивание тормозящей все и вся защиты стека дало мало: есть же ещё разыменования указателей и много других способов залезть куда не надо. Из-за их ошибок происходило повреждение памяти, где находился наш код HAL и после этого происходили самые невероятные вещи. Намучились мы тогда здорово…
В следующем проекте мы специально выбрали микропроцессор (MPU) и написали свою маленькую ОС с защитой памяти ядра (ядром являлся наш HAL) и системными вызовами. Получилась ОС с одной задачей, ядро — HAL, задача — прикладная задача заказчика. Ни одного сообщения, подобного тому, которое получали по прошлому проекту, в этот раз не было. Вот тогда мы поняли, зачем в действительности нужны операционные системы в embedded…