можно ли написать приложение реального времени для ос windows
Операционные системы реального времени для начинающих
Привет, Хабр!
Сегодня я расскажу о такой интересной штуке как операционная система реального времени(ОСРВ). Не уверен, что это будет интересно для бывалых программистов, но, думаю, новичкам понравится.
Что такое ОСРВ?
Зачем она нам нужна?
На то есть довольно много причин.
Во-первых ОСРВ поддерживает многозадачность, приоритеты процессов семафоры и многое другое.
Во-вторых она очень легкая и почти не требует ресурсов.
В-третьих все вышесказанное мы можем получить практически на любом железе (например, FreeRTOS запускается даже на 8-битных AtMega).
Ну и в-четвертых: просто поиграться и получить удовольствие.
Обзор 3 известных ОСРВ.
Внимание: дальше идет мое личное мнение.
FreeRTOS
Одна из самых популярных ОСРВ на сегодняшний день. Портирована на огромное количество железа. Оффициальный сайт.
Плюсы
Минусы
1)Довольно-таки сложный процесс портирования на новое железо.
Вывод: Это действительно профессиональная ОСРВ с хорошей документацией. Будет хороша для новичка, если на его железо уже есть порт.
KeilRTX
До последнего времени эта ОСРВ была коммерческой, но недавно стала открытой. Работает только на архитектуре arm. Оффициальный сайт.
Плюсы
1)Бесплатная
2)Легко портируется на новое железо( в пределах архитектуры arm).
3) Есть различные библиотеки: графика, интернет и другое.
Минусы
1)Работать на в Keil с ней практически нереально
2) Немного урезанный функционал
3) Поддерживается только arm.
4)(на личном опыте) Проигрывает многим ОСРВ по скорости.
Вывод: идеально подойдет для новичка и мелких проектов.
Мощная коммерческая ОСРВ. Сайт.
Плюсы
Минусы
1)Коммерческая.
2) Сложна в использовании.
Вывод: назвать ее ОСРВ для новичка можно с большой натяжкой.
Другие интересные ОСРВ
RTLinux ОСРВ на основе обычного Линукса.
QNX ОСРВ на основе Unix.
Особенности разработки с использованием ОСРВ
Ну во-первых надо понять следующее: ОСРВ- это не Windows. Его нельзя установить. Эта система просто компилируется с Вашей программой.
При написании программ с ОСРВ не используются функции в обычном их понимании. Вместо функций используются процессы( или таски).Отличие в том что процессы, в отличии от функций, являются бесконечными циклами и никогда не заканчиваются(если только кто-то или он сам его не убъет — то есть выгрузит из памяти).
Если включено несколько процессов, то ОСРВ переключает их, выдавая машинное время и ресурсы по очереди. Вот тут то и возникает понятия приоритета процесса- если двум процессам единовременно нужно машинное время, то ОСРВ даст его тому, у кого приоритет больше.
В ОСРВ есть специальные функции задержки- чтобы время зря не пропадало на время задержки одного процесса выполняется второй.
Теперь поговорим о такой вещи как семафор- эта такая штука, которая управляет доступом процесса к ресурсам приложения. Для каждого ресурса есть маркер — когда процессу нужен ресурс — он его забирает и пользуется данным ресурсом. Если маркера нет, то процессу придется ждать, пока его вернут. Приведу пример: разные процессы отправляют информацию по одному UART. Если бы не было семафора, то они бы отправляли байты по очереди и получилась бы неразбериха. А так первый процесс взял маркер на UART отправил сообщение и отдал второму( и так — до бесконечности).
Дополнительные библиотеки ОСРВ.
Часто ОСРВ предлагают различные библиотеки для работы, например, с графикой, интернетом и т.д. Они действительно удобны и не стоит брезгать их использовать. Однако, помните, что без ОСРВ, для которой они написаны, они работать не будут.
Вот примеры:
Для RTX графика интернет Файловая система
Во второй( и, наверное, последней ) части мы поговорим о мьютексах, буферах сообщений и попрактикуемся в их использовании.
Вся правда об ОСРВ от Колина Уоллса
Вся правда об ОСРВ. Статья #1.
Операционные системы реального времени: введение
Эта серия статей посвящена тщательному изучению всех аспектов операционных систем реального времени (ОСРВ). Статьи ориентированы на разработчиков, которым любопытно узнать, как работают ОСРВ и как ими пользоваться. Отправной точкой станет рассуждение о системах реального времени в общем, далее речь пойдет о том, как ОСРВ могут упростить их реализацию и сделать полученный код более надежным.
Заглянув во внутрь ОСРВ, мы посмотрим, как работает планировщик задач. Благодаря многопоточности создается впечатление, что ЦП выполняет несколько операций одновременно. Это не магия, понимание принципов работы планировщика задач доступно даже неопытному инженеру-программисту. Мы поговорим и о других объектах ОСРВ: о взаимодействии между задачами и синхронизации, о режиме реального времени, об управлении памятью и т. д., все будет точно описано и подкреплено примерами кода.
Для разработчика ключевым аспектом ОСРВ является API, набор вызова процедур, предоставляющий доступ к функционалу ОСРВ. В серии буду представлены статьи на эту тему, посвященные тому, как устроен API, какие стандарты доступны и как перейти с одного API на другой.
Ниже список тем, которые мы рассмотрим в ближайшее время:
Однако, чтобы объяснить внутреннее устройство ОСРВ, используются примеры кода реального продукта – Nucleus SE.
Вся правда об ОСРВ. Статья #2
ОСРВ: Структура и режим реального времени
Структура программы и режим реального времени
Эта серия статей о встраиваемых системах и, в частности, о программном обеспечении, работающем во встраиваемых системах. Начнем с определения. Что же такое встраиваемая система? В 1986 году, когда я писал первую книгу на эту тему, такого термина еще не существовало. Использовались понятия «выделенная система» или «микросистема», но они, конечно, не отражали всей сути. Через несколько лет в обиход вошло слово «встраиваемая», и все специалисты стали активно его использовать.
Вернемся к определению встраиваемой системы. В попытках объяснить друзьям и семье, над чем я работаю, я пришел к следующему объяснению: встраиваемая система – любой электронный прибор, в котором есть процессор, но который обычно не принято описывать как компьютер.
Операционная система (ОС) всегда стоит на компьютере; в современных встраиваемых системах применяются только некоторые виды ОС. Несмотря на то, что использование ядра преобладает в высокопроизводительных (32- и 64-разрядных) системах, можно извлекать выгоду и из его применения в маломощных устройствах. В центре внимания этих статей – операционные системы, как в общем, так и со спецификой внедрения.
Зачем вообще использовать операционную систему?
Давайте разберемся, почему операционные системы применяются в принципе. Существует много объяснений, некоторые из них зависят как от человеческого фактора, так и от технических характеристик. Помню историю. В одном из наших офисов был кухонный уголок, где можно было сварить кофе. На двери висела табличка с надписью: «Пожалуйста, не закрывайте дверь». Под ней кто-то написал: «Почему нет?», на что кто-то другой ответил: «Потому что». Очень укороченный вариант фразы «потому что мы говорим вам поступать именно таким образом». По тем же соображениям операционные системы применяются в некоторых системах, просто потому что так нужно делать.
Другое объяснение кроется в использовании десктопных приложений. С чего вы начнете, если будете писать программное обеспечение для ПК или Mac? Вы включите компьютер, запустите Windows/Linux или macOS и начнете программировать. Наличие операционной системы – это заданное условие, и оно предоставляет ряд полезных сервисов. Навряд ли вы вздумаете начать с нуля, программируя «голое» железо. Поэтому неудивительно, если инженер, у которого есть опыт написания ПО, но для которого встроенное ПО в новинку, будет рассчитывать на наличие операционной системы в разрабатываемой им системе.
Стоит отметить ключевой аспект десктопной ОС, о котором знают пользователи, — пользовательский интерфейс (англ. User Interface, UI). Спросите у кого-нибудь, что такое Windows, и вам ответят, что это окна, меню, диалоговые окна, иконки, но вряд ли упомянут файловую систему, межпрограммную коммуникацию и способность взаимодействовать с другими системами. В этом основное отличие десктопной от встраиваемой системы: в последней может и не быть пользовательского интерфейса, а если он и есть, то он достаточно незамысловатый. Это первое из многих ключевых отличий:
Во-первых, существует выполнение программ в стиле DOS, когда программы выполняются поочередно.
Каждая программа запускается, реализуется и завершается. Мы используем, скажем, программу 1, затем программу 2, затем, возможно, сделаем перерыв, обратимся к программе 3, а потом снова вернемся к программе 2. Второе использование программы 2 начинается заново: запуск не начинается с того места, где мы остановились до этого (кроме тех случаев, когда приложение само не предоставляет такую возможность).
После DOS многое усложнилось, так как Windows стала обычным делом. Выполнение программ в стиле Windows подразумевает запуск нескольких программ в многопоточном режиме.
В таком режиме создается впечатление, что программы работают одновременно, и этой иллюзией управляет Windows. Сначала запускается программа 1, затем в то же время начинает работу программа 2, затем программа 3. Программа 2 завершается, программы 1 и 3 все еще работают. Программа 3 завершается, остается только программа 1. Позднее возобновляется программа 2, а программа 1 завершается, остается только программа 2. Это реалистичный ход событий при использовании Windows обычным пользователем. Операционная система распределяет ресурсы таким образом, чтобы все программы корректно использовали процессор. Это также обеспечивает простую коммуникацию между программами (например, буфер обмена) и управляет пользовательским интерфейсом.
Некоторым портативным устройствам требуется больше гибкости, чем может предложить DOS, но с учетом ограниченных ресурсов, требуются более низкие, чем у Windows, накладные расходы. В итоге, имеем выполнение программ в стиле iOS, а именно:
Программы запускаются поочередно, но их состояние автоматически сохраняется, чтобы можно было продолжить с этого же места при закрытии. Например, запускается программа 1, затем приостанавливается для использования программы 2, затем, например, устройство на какое-то время выключается. При возобновлении загружается программа 3 (состояние программы 2 сохранилось автоматически), а потом пользователь возвращается к программе 2, продолжая работу в ней. Я понимаю, что модель выполнения iOS приложения гораздо сложнее, чем описанное выше, тем не менее, это описание — лишь краткое изложение первичного восприятия пользователя.
Большинство встроенных приложений не соответствует ни одной из вышеперечисленных моделей. Как правило, устройство запускает программу при включении питания и продолжает работать только с этим ПО неопределенное количество времени. Структура подобного кода должна быть тщательно продумана.
Модели встраиваемых программ
Десктопные системы практически все одинаковые. С точки зрения прикладной программы, все персональные компьютеры с Windows идентичны. Встраиваемые системы уникальны: каждая отличается от других. Отличия могут быть техническими: тип процессора, объем памяти, количество периферийных устройств. Приоритетные аспекты приложений также могут отличаться скоростью выполнения, потреблением энергии, защищенностью и надежностью. Могут быть и коммерческие отличия, влияющие на ценообразование: объемы производства и выбор между заказным или стандартным аппаратным обеспечением.
Эти различия имеют большое значение для разработчиков встраиваемого ПО. Например, выбор инструментов для разработки (компиляторы, отладчики и т. д.) зависит от вида процессора. На выбор операционной системы или даже само решение применить ее в принципе влияют многие факторы. Структура ПО (программная модель) должна быть тщательно подобрана для каждого отдельно взятого встроенного приложения.
В зависимости от требований приложения, встраиваемое ПО может обладать различными структурами разного уровня сложности, например:
Простейший вид – замкнутая структура, в которой происходит повторное выполнение одной и той же последовательности действий. Если приложение достаточно простое, чтобы его можно было внедрить подобным образом, это идеальный вариант: простой код надежен и понятен. Однако подобная структура крайне чувствительна к части кода, которая может занимать слишком много времени работы процессора, то есть некоторые команды выполняются так долго, что задерживают выполнение других задач приложения. Кроме того, эта модель плохо масштабируется: улучшение кода может стать проблемой, поскольку дополнения могут повлиять на производительность старого кода.
Если требуется что-то посложнее, можно попробовать разместить некритичную по времени часть кода в основном цикле, а чувствительную ко времени — в обработчике прерываний (англ. Interrupt Service Routines, ISR). Действия обработчика прерываний в основном достаточно короткие, выполняющие только критически важные задачи и отмечающие участки основного цикла для завершения работы при первой же возможности. Трудности могут возникнуть, когда понадобится распределять работу между основным циклом и обработчиком прерываний (а также между несколькими разработчиками).
Для максимальной гибкости приложения понадобится его разделение на несколько отдельных, относительно самостоятельных программ (назовем их задачами или потоками), которые будут выполняться в многопоточном режиме. Небольшие обработчики прерываний также могут быть включены в систему, но будут в основном уведомлять о задачах или вызывать действие. Чтобы добиться этого, нужна операционная система или, по крайней мере, ядро. Применение многопоточности не только обеспечивает гибкое распределение функциональных возможностей в программном обеспечении, но и облегчает распределение работ между разработчиками.
Что такое реальное время?
Ранее я писал, что многие встраиваемые приложения работают в режиме реального времени. В данном контексте принято говорить об операционных системах реального времени, а не о простой ОС. Определимся с терминологией.
«Операционная система реального времени — это система, в которой корректность вычислений зависит не только от логической корректности вычислений, но также от времени, за которое будет достигнут результат.
Если не выполняются временные ограничения системы, считается, что произошел системный сбой».
Важной особенностью подобной системы является ее предсказуемость или, как чаще говорят, детерминизм.
Операционная система реального времени необязательно очень быстрая, «реальное время» не всегда означает «реально быстрое время». Это означает, что любое необходимое действие будет выполнено своевременно. То есть, достаточно быстро, но в то же время и не слишком быстро (то есть, достаточно медленно).
ОСРВ (при правильном использовании) обеспечивает очень точный контроль за распределением времени процессора на выполнение задач и, следовательно, делает приложения полностью детерминированными. Единственное, что может испортить эту картину, – это прерывания. Есть ОСРВ, которые полностью контролируют прерывания. Их работа заключается в том, чтобы управлять обслуживанием прерываний в рамках работы планировщика задач. Несмотря на то, что это должно было бы приводить к предсказуемому поведению, этот механизм достаточно сложно устроен и заключает в себе высокие накладные расходы.
Большинство ОСРВ просто позволяет обработчику прерываний «красть» время у задачи, запущенной в момент прерывания. Это, в свою очередь, вынуждает программиста писать код обработчика прерывания как можно короче. В результате имеем допустимую погрешность реального времени. Единственная сложность состоит в выполнении вызовов служб ОСРВ в рамках задачи-обработчика. Некоторые вызовы могут быть вполне безобидными, в то время как другие станут причиной переключения контекста при возврате из прерывания. Такая ситуация должна быть специально улажена, что возможно с помощью различных ОСРВ.
Когда мы работали над нашей собственной операционной системой реального времени ОСРВ МАКС (ранее уже публиковал статьи о ней), наша команда «наткнулась» на блог Колина Уоллса (Colin Walls), эксперта в области микроэлектроники и встроенного ПО компании Mentor Graphics. Статьи показались интересными, переводили их для себя, но, чтобы не «писать в стол» решили опубликовать. Надеюсь, они будут вам также полезны. Если так, то дальше планируем опубликовать все переведенные статьи серии.