Вся правда об ОСРВ. Статья #1.
Операционные системы реального времени: введение
Эта серия статей посвящена тщательному изучению всех аспектов операционных систем реального времени (ОСРВ). Статьи ориентированы на разработчиков, которым любопытно узнать, как работают ОСРВ и как ими пользоваться. Отправной точкой станет рассуждение о системах реального времени в общем, далее речь пойдет о том, как ОСРВ могут упростить их реализацию и сделать полученный код более надежным.
Заглянув во внутрь ОСРВ, мы посмотрим, как работает планировщик задач. Благодаря многопоточности создается впечатление, что ЦП выполняет несколько операций одновременно. Это не магия, понимание принципов работы планировщика задач доступно даже неопытному инженеру-программисту. Мы поговорим и о других объектах ОСРВ: о взаимодействии между задачами и синхронизации, о режиме реального времени, об управлении памятью и т. д., все будет точно описано и подкреплено примерами кода.
Для разработчика ключевым аспектом ОСРВ является API, набор вызова процедур, предоставляющий доступ к функционалу ОСРВ. В серии буду представлены статьи на эту тему, посвященные тому, как устроен API, какие стандарты доступны и как перейти с одного API на другой.
Ниже список тем, которые мы рассмотрим в ближайшее время:
Цикл статей не привязан к какой-то определенной операционной системе реального времени, большая часть материала применима к общедоступным вариантам реализации ОСРВ. По мнению автора, использование готовой, коммерческой ОС с существующей поддержкой – самый надежный и наиболее продуктивный способ работы. Одна из статей будет посвящена детальному рассуждения на тему «сделать vs купить» и другим методологиям выбора ОСРВ.
Однако, чтобы объяснить внутреннее устройство ОСРВ, используются примеры кода реального продукта – Nucleus SE.
Источник: http://www.embedded.com/design/operating-systems/4442729/Introducing--RTOS-Revealed
ОСРВ: Структура и режим реального времени
Структура программы и режим реального времени
Эта серия статей о встраиваемых системах и, в частности, о программном обеспечении, работающем во встраиваемых системах. Начнем с определения. Что же такое встраиваемая система? В 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). Действия обработчика прерываний в основном достаточно короткие, выполняющие только критически важные задачи и отмечающие участки основного цикла для завершения работы при первой же возможности. Трудности могут возникнуть, когда понадобится распределять работу между основным циклом и обработчиком прерываний (а также между несколькими разработчиками).
Для максимальной гибкости приложения понадобится его разделение на несколько отдельных, относительно самостоятельных программ (назовем их задачами или потоками), которые будут выполняться в многопоточном режиме. Небольшие обработчики прерываний также могут быть включены в систему, но будут в основном уведомлять о задачах или вызывать действие. Чтобы добиться этого, нужна операционная система или, по крайней мере, ядро. Применение многопоточности не только обеспечивает гибкое распределение функциональных возможностей в программном обеспечении, но и облегчает распределение работ между разработчиками.
Что такое реальное время?
Ранее я писал, что многие встраиваемые приложения работают в режиме реального времени. В данном контексте принято говорить об операционных системах реального времени, а не о простой ОС. Определимся с терминологией.
«Операционная система реального времени — это система, в которой корректность вычислений зависит не только от логической корректности вычислений, но также от времени, за которое будет достигнут результат.
Если не выполняются временные ограничения системы, считается, что произошел системный сбой».
Важной особенностью подобной системы является ее предсказуемость или, как чаще говорят, детерминизм.
Операционная система реального времени необязательно очень быстрая, «реальное время» не всегда означает «реально быстрое время». Это означает, что любое необходимое действие будет выполнено своевременно. То есть, достаточно быстро, но в то же время и не слишком быстро (то есть, достаточно медленно).
ОСРВ (при правильном использовании) обеспечивает очень точный контроль за распределением времени процессора на выполнение задач и, следовательно, делает приложения полностью детерминированными. Единственное, что может испортить эту картину, – это прерывания. Есть ОСРВ, которые полностью контролируют прерывания. Их работа заключается в том, чтобы управлять обслуживанием прерываний в рамках работы планировщика задач. Несмотря на то, что это должно было бы приводить к предсказуемому поведению, этот механизм достаточно сложно устроен и заключает в себе высокие накладные расходы.
Большинство ОСРВ просто позволяет обработчику прерываний «красть» время у задачи, запущенной в момент прерывания. Это, в свою очередь, вынуждает программиста писать код обработчика прерывания как можно короче. В результате имеем допустимую погрешность реального времени. Единственная сложность состоит в выполнении вызовов служб ОСРВ в рамках задачи-обработчика. Некоторые вызовы могут быть вполне безобидными, в то время как другие станут причиной переключения контекста при возврате из прерывания. Такая ситуация должна быть специально улажена, что возможно с помощью различных ОСРВ.
Источник: https://www.embedded.com/design/operating-systems/4442900/Program-structure-and-real-time
Когда мы работали над нашей собственной операционной системой реального времени ОСРВ МАКС (ранее уже публиковал статьи о ней), наша команда «наткнулась» на блог Колина Уоллса (Colin Walls), эксперта в области микроэлектроники и встроенного ПО компании Mentor Graphics. Статьи показались интересными, переводили их для себя, но, чтобы не «писать в стол» решили опубликовать. Надеюсь, они будут вам также полезны. Если так, то дальше планируем опубликовать все переведенные статьи серии.
Об авторе: Колин Уоллс уже более тридцати лет работает в сфере электронной промышленности, значительную часть времени уделяя встроенному ПО. Сейчас он – инженер в области встроенного ПО в Mentor Embedded ( подразделение Mentor Graphics). Колин Уоллс часто выступает на конференциях и семинарах, автор многочисленных технических статей и двух книг по встроенному ПО. Живет в Великобритании. Профессиональный блог Колина: http://blogs.mentor.com/colinwalls, e-mail: colin_walls@mentor.com
Статья 3 опубликована здесь.
Операционные системы реального времени: введение
Эта серия статей посвящена тщательному изучению всех аспектов операционных систем реального времени (ОСРВ). Статьи ориентированы на разработчиков, которым любопытно узнать, как работают ОСРВ и как ими пользоваться. Отправной точкой станет рассуждение о системах реального времени в общем, далее речь пойдет о том, как ОСРВ могут упростить их реализацию и сделать полученный код более надежным.
Заглянув во внутрь ОСРВ, мы посмотрим, как работает планировщик задач. Благодаря многопоточности создается впечатление, что ЦП выполняет несколько операций одновременно. Это не магия, понимание принципов работы планировщика задач доступно даже неопытному инженеру-программисту. Мы поговорим и о других объектах ОСРВ: о взаимодействии между задачами и синхронизации, о режиме реального времени, об управлении памятью и т. д., все будет точно описано и подкреплено примерами кода.
Для разработчика ключевым аспектом ОСРВ является API, набор вызова процедур, предоставляющий доступ к функционалу ОСРВ. В серии буду представлены статьи на эту тему, посвященные тому, как устроен API, какие стандарты доступны и как перейти с одного API на другой.
Ниже список тем, которые мы рассмотрим в ближайшее время:
- Структура программы и режим реального времени
- Операционные системы реального времени
- Задачи и планирование
- Взаимодействие между задачами и синхронизация
- Другие сервисы операционной системы
- Nucleus SE
- Планировщик
- Задачи
- Разделы памяти
- Сигналы
- Группы флагов событий
- Семафоры
- Почтовые ящики
- Очереди
- Каналы
- Системное время
- Программные таймеры
- Прерывания
- Диагностика и проверка ошибок
- Инициализация и запуск
Цикл статей не привязан к какой-то определенной операционной системе реального времени, большая часть материала применима к общедоступным вариантам реализации ОСРВ. По мнению автора, использование готовой, коммерческой ОС с существующей поддержкой – самый надежный и наиболее продуктивный способ работы. Одна из статей будет посвящена детальному рассуждения на тему «сделать vs купить» и другим методологиям выбора ОСРВ.
Однако, чтобы объяснить внутреннее устройство ОСРВ, используются примеры кода реального продукта – Nucleus SE.
Источник: http://www.embedded.com/design/operating-systems/4442729/Introducing--RTOS-Revealed
Вся правда об ОСРВ. Статья #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). Действия обработчика прерываний в основном достаточно короткие, выполняющие только критически важные задачи и отмечающие участки основного цикла для завершения работы при первой же возможности. Трудности могут возникнуть, когда понадобится распределять работу между основным циклом и обработчиком прерываний (а также между несколькими разработчиками).
Для максимальной гибкости приложения понадобится его разделение на несколько отдельных, относительно самостоятельных программ (назовем их задачами или потоками), которые будут выполняться в многопоточном режиме. Небольшие обработчики прерываний также могут быть включены в систему, но будут в основном уведомлять о задачах или вызывать действие. Чтобы добиться этого, нужна операционная система или, по крайней мере, ядро. Применение многопоточности не только обеспечивает гибкое распределение функциональных возможностей в программном обеспечении, но и облегчает распределение работ между разработчиками.
Что такое реальное время?
Ранее я писал, что многие встраиваемые приложения работают в режиме реального времени. В данном контексте принято говорить об операционных системах реального времени, а не о простой ОС. Определимся с терминологией.
«Операционная система реального времени — это система, в которой корректность вычислений зависит не только от логической корректности вычислений, но также от времени, за которое будет достигнут результат.
Если не выполняются временные ограничения системы, считается, что произошел системный сбой».
Важной особенностью подобной системы является ее предсказуемость или, как чаще говорят, детерминизм.
Операционная система реального времени необязательно очень быстрая, «реальное время» не всегда означает «реально быстрое время». Это означает, что любое необходимое действие будет выполнено своевременно. То есть, достаточно быстро, но в то же время и не слишком быстро (то есть, достаточно медленно).
ОСРВ (при правильном использовании) обеспечивает очень точный контроль за распределением времени процессора на выполнение задач и, следовательно, делает приложения полностью детерминированными. Единственное, что может испортить эту картину, – это прерывания. Есть ОСРВ, которые полностью контролируют прерывания. Их работа заключается в том, чтобы управлять обслуживанием прерываний в рамках работы планировщика задач. Несмотря на то, что это должно было бы приводить к предсказуемому поведению, этот механизм достаточно сложно устроен и заключает в себе высокие накладные расходы.
Большинство ОСРВ просто позволяет обработчику прерываний «красть» время у задачи, запущенной в момент прерывания. Это, в свою очередь, вынуждает программиста писать код обработчика прерывания как можно короче. В результате имеем допустимую погрешность реального времени. Единственная сложность состоит в выполнении вызовов служб ОСРВ в рамках задачи-обработчика. Некоторые вызовы могут быть вполне безобидными, в то время как другие станут причиной переключения контекста при возврате из прерывания. Такая ситуация должна быть специально улажена, что возможно с помощью различных ОСРВ.
Источник: https://www.embedded.com/design/operating-systems/4442900/Program-structure-and-real-time
Когда мы работали над нашей собственной операционной системой реального времени ОСРВ МАКС (ранее уже публиковал статьи о ней), наша команда «наткнулась» на блог Колина Уоллса (Colin Walls), эксперта в области микроэлектроники и встроенного ПО компании Mentor Graphics. Статьи показались интересными, переводили их для себя, но, чтобы не «писать в стол» решили опубликовать. Надеюсь, они будут вам также полезны. Если так, то дальше планируем опубликовать все переведенные статьи серии.
Об авторе: Колин Уоллс уже более тридцати лет работает в сфере электронной промышленности, значительную часть времени уделяя встроенному ПО. Сейчас он – инженер в области встроенного ПО в Mentor Embedded ( подразделение Mentor Graphics). Колин Уоллс часто выступает на конференциях и семинарах, автор многочисленных технических статей и двух книг по встроенному ПО. Живет в Великобритании. Профессиональный блог Колина: http://blogs.mentor.com/colinwalls, e-mail: colin_walls@mentor.com
Статья 3 опубликована здесь.
