Группы флагов событий уже упоминались ранее в одной из предыдущих статей (#5). В Nucleus SE они похожи на сигналы, но являются более гибкими. Они предоставляют малозатратный и гибкий способ передачи простых сообщений между задачами.

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

В этой статье мы продолжаем рассматривать разделы памяти ОСРВ.

Nucleus RTOS имеет три вызова API, предоставляющих служебные функции, связанные с пулами разделов памяти: возвращение информации о пуле разделов, возвращение числа пулов разделов в приложении и возвращение указателей на все пулы разделов в приложении. Первые два вызова реализованы в Nucleus SE.

Разделы памяти упоминались ранее в одной из предыдущих статей (#6), где производилось сравнение со стандартной функцией языка C malloc(). Раздел (partition) – это область памяти, получаемая из пула разделов (пула памяти). Разделение памяти предоставляет гибкий способ надежного и детерминированного выделения и освобождения памяти.

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

Продолжаем рассматривать службы ОСРВ, предоставляющие дополнительную информацию о задачах и операциях с ними.

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

В предыдущей статье мы рассматривали различные типы планирования, поддерживаемые ОСРВ, и соответствующие возможности в Nucleus SE. В этой статье рассмотрим дополнительные возможности планирования в Nucleus SE и процесс сохранения и восстановления контекста.

Мы открываем сбор средств на подготовку ОСРВ МАКС к бесплатному массовому использованию.


Новая версия позволит сторонним разработчикам добавлять в систему модули, а лицензия не будет ограничивать коммерческое применение.

Основные принципы работы планировщиков ОСРВ были рассмотрены в статье «Задачи и планирование». В настоящей статье мы рассмотрим возможности, которые предлагает Nucleus RTOS, а также более подробно те, которые предоставляет Nucleus SE.

В этой статье продолжается обзор Nucleus SE

Службы

Nucleus SE предоставляет набор средств, которые можно ожидать от любой ОСРВ.
Во-первых, Nucleus SE содержит довольно простой планировщик, однако, благодаря четырем доступным вариантам, он обеспечивает гибкость. Планировщик поддерживает алгоритмы Run to Completion (выполнение до завершения), Round Robin (карусель), Time Slice (квант времени) и Priority (приоритетное планирование).

В оставшейся части серии статей «Вся правда об ОСРВ» мы подробно рассмотрим, как внедряется и развертывается ОСРВ. Для этого мы рассмотрим конкретную ОСРВ: Nucleus SE. Даже если вы не собираетесь использовать конкретно это ядро или другие, связанные с ним, ядра, понимание того, как оно работает, даст хороший фундамент для работы с любыми ОСРВ.

В предыдущих статьях мы обсуждали функциональность ядра с точки зрения выполняемых задач и взаимодействия между ними. В этой статье мы рассмотрим, что еще может делать ядро, что в значительной степени проявляется в ряде других доступных вызовов API. Мы также ответим на вопрос, что превращает ядро в операционную систему?

В предыдущих статьях мы рассмотрели многозадачную модель, и выяснили, что каждая задача является квазинезависимой программой. Хотя задачи во встраиваемых системах имеют определенную степень независимости, это не означает, что они не «знают» друг о друге. Некоторые задачи будут действительно изолированы от других, но взаимодействие и синхронизация между ними является распространенным требованием. Этот механизм является одной из ключевых функций ОСРВ. Диапазон функций может варьироваться в зависимости от ОСРВ, поэтому в этой статье мы рассмотрим общедоступные варианты.

Идентификаторы задач (Task Identifiers)

Необходимо уметь идентифицировать каждую задачу в системе. Это требование важно и для других объектов ядра, но в задачах есть некоторые нюансы, которые соответствуют теме данной статьи.



Разработчики ОСРВ используют разные подходы к идентификации задач, но можно выделить четыре общие стратегии:

• Задача идентифицируется с помощью указателя (pointer) на свой «блок управления» (“control block”). Указатели всегда уникальны, а также удобны в использовании, поскольку доступ к блоку управления требуется при многих вызовах API. Это подразумевает, что все данные о задаче хранятся в оперативной памяти (RAM), что может быть неэффективно. Указатель обычно занимает около 32 бит памяти.
• Задача может быть определена с помощью произвольного «порядкового числа» (index number). Это значение может пригодиться при предоставлении доступа к записям в определенных таблицах. Такой идентификатор может занимать восемь или меньше бит памяти, в зависимости от ограничений по количеству задач, которые поддерживаются ОСРВ.
• Некоторые ОСРВ разрешают только одну задачу на каждый уровень приоритета и, следовательно, используют приоритет для уникальной идентификации задачи. Это означает, что приоритет задачи не может быть изменен. Этот подход является разновидностью предыдущего подхода.
• Задачи могут иметь имена, которые являются символьными строками (character string). Это может быть полезно для отладки, но вряд ли будет эффективным средством уникальной идентификации задачи. ОСРВ, которые поддерживают именование задач, как правило, имеют дополнительный идентификатор (например, указатель), который используется вызовами API и т. д. Для большинства встраиваемых систем текстовые имена — это накладные расходы; хороший отладчик позволяет называть их локально на хосте.

Мы рассмотрели многозадачность, свойство операционной системы выполнять несколько квазинезависимых программ одновременно. Перед тем, как мы более подробно рассмотрим задачи, необходимо разобраться с терминами.

Мы, вслед за Гауссом, признаем «царский» статус математики, а учитывая, что в нашей компании есть центр компетенции «Алгоритмическое обеспечение», у нас частенько появляются интересные материалы на эту тему: то наши коллеги пишут свои, авторские статьи, то, изучая, что интересного происходит у зарубежных коллег, готовят краткие обзоры и переводы сторонних статей. Вероятно это будет полезно тем, кто разделяет наши интересы, поэтому мы решили этими материалами и знаниями делиться.

Начну издалека. Прошлой зимой довелось мне делать USB-устройство с ядром, размещаемым в ПЛИС. Само собой, очень мне хотелось проверить реальную пропускную способность этой шины. Ведь в контроллере — там слишком много всего наверчено. Всегда можно сказать, что вот тут внесена задержка, или вон там. В случае же с ПЛИС — я вижу блок, прокачивающий данные, вот он сказал мне, что в нём данные есть. А вот я выставил, что всё обработано, и я готов принимать новую порцию (при этом, он уже принимает данные во второй буфер этой же конечной точки). Отлично, ставим готовность с первого же такта и смотрим, что получается, когда USB может «молотить» без остановки.

Вся правда об ОСРВ. Статья #1.

Операционные системы реального времени: введение

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

Заглянув во внутрь ОСРВ, мы посмотрим, как работает планировщик задач. Благодаря многопоточности создается впечатление, что ЦП выполняет несколько операций одновременно. Это не магия, понимание принципов работы планировщика задач доступно даже неопытному инженеру-программисту. Мы поговорим и о других объектах ОСРВ: о взаимодействии между задачами и синхронизации, о режиме реального времени, об управлении памятью и т. д., все будет точно описано и подкреплено примерами кода.

Из любого описания на популярные FPGA известно, что для хранения их конфигураций используются специальные микросхемы – конфигураторы. В комментариях меня поправили, что потихоньку набирают популярность и FPGA, где это не требуется, но пока многие делают разработки именно на классике, где нужен конфигуратор, и с этим надо считаться. Например, для Altera Cyclone используются микросхемы EPCS. Ниже схема от типичной макетной платы с кристаллом семейства Cyclone IV. На ней мы видим конфигуратор EPCS16. Всё бы ничего, но традиционно эти конфигураторы достаточно дороги, поэтому хотелось бы использовать что-нибудь подешевле.

Подробности в длиннющем тексте ниже. Если же очень интересно, но лень читать так много букв, то можно упростить задачу, посмотрев подробное 20-минутное видео.