Когда нам нужна операционная система для разработки встраиваемых систем?

Я написал много чистого кода для процессоров PIC и x86. Может кто-нибудь сказать мне, как и когда мне нужна операционная система? И наоборот, с каким приложением или ситуацией можно справиться или без операционной системы?

Мое эмпирическое правило заключается в том, что вы должны учитывать операционную систему, если продукт требует одного или нескольких из следующих элементов: стек TCP / IP (или другой сложный сетевой стек), сложный графический интерфейс пользователя (возможно, один с объектами графического интерфейса, такими как окна и события). ) или файловая система.

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

По мере увеличения требований к программному обеспечению супер-цикл усложняется. Когда программных требований так много, что супер-цикл становится слишком сложным или не может удовлетворить требования системы в реальном времени, тогда пришло время рассмотреть другую архитектуру.

Архитектура RTOS позволяет разделить требования к программному обеспечению на задачи. Если все сделано правильно, это упрощает реализацию каждой задачи. А с помощью приоритизации задач ОСРВ может упростить выполнение требований в реальном времени. Однако ОСРВ не является панацеей. RTOS увеличивает общую сложность системы и открывает для вас новые типы ошибок (таких как взаимоблокировки). В качестве альтернативы ОСРВ можно рассмотреть и архитектуру конечного автомата на основе событий (например, QP ).

Если ваш продукт имеет сеть, сложный графический интерфейс и файловую систему, то вы можете быть в состоянии рассмотреть полнофункциональные операционные системы, такие как VxWorks, Windows или Linux. Полнофункциональные операционные системы будут включать драйверы для низкоуровневых деталей и позволят вам сосредоточиться на своем приложении.

Это действительно зависит от вашего определения «встроенной системы». Могут быть люди, которые утверждают, что если это не голое программирование, оно не встроено (что исключает ваш вопрос), но я бы не согласился с этим - я бы сказал, что любая система, предназначенная для выполнения только одной функции, то есть, чтобы запускать только одно конкретное «приложение», можно было бы назвать встроенную систему.

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

Тем не менее, просто откупиться от готовых модулей ввода / вывода, подключить их в стойку ПК и нагнетание конфигурацию в GUI может не квалифицироваться как встроенные системы проектирования для некоторых. Для чуть менее стандартной ситуации рассмотрите пользовательский контроллер процессов с ПЛИС, для которого вы хотите сделать некоторую необычную регистрацию данных. Вы можете встроить процессорную систему с мягким ядром (с существующим BSP) и запустить Linux в реальном времени, чтобы запустить сетевой стек (для вашей регистрации, NTP и т. Д.) И делать все остальное в логике.

Мое (очень расплывчатое) практическое правило: если вам нужно более одного потока управления (скажем, по крайней мере, одно устройство, которое включает протокол или конечный автомат плюс что-то еще), то некоторые из программ OSish сделают вашу жизнь проще

Старый вопрос, но я все равно прокомментирую.

Даже если у вас нет сетевых стеков или чего-то подобного, в момент, когда вам нужен планировщик задач, так как у вас достаточно процессов во встроенном приложении, вы можете рассмотреть RTOS. Написание простого многозадачного планировщика, основанного на таймере, не так сложно, но необходимо убедиться, что застрявший процесс не заблокирует остальную часть приложения, и на это может уйти некоторое время. Вам необходимо внедрить систему приоритетов с каким-то условием для остановки процессов в очереди, если они еще не завершены.

RTOS также предоставляет такие вещи, как защита памяти и тому подобное, что значительно упрощает отслеживание некоторых распространенных ошибок в C-коде, но простые микроконтроллеры просто могут не справиться со сложной защитой памяти. Например, MSP430 позволяет разделять код и данные на высоком уровне, но нет точного контроля доступа к памяти.

Операционная система фактически устраняет разрыв между аппаратным и прикладным программным обеспечением (через драйвер устройства). Другими словами, он обеспечивает платформу относительно высокого уровня для программиста, что в конечном итоге снижает сложность кода. И далее, операционная система предоставляет сильную и гибкую платформу для выполнения приложений.