Основным требованием при разработке Nucleus SE была высокая степень совместимости с основным продуктом RTOS компании Mentor — Nucleus RTOS. Nucleus SE поддерживает определенную часть функционала Nucleus RTOS, которая неоднократно обсуждалась в предыдущих статьях, но в этой статье я постараюсь собрать все ключевые отличия в одном месте.
Эта статья была задумана как краткий справочник для всех, кто планирует перейти с одного ядра на другое или находится в процессе выбора ядра для конкретного проекта.
Помимо ограниченной или упрощенной функциональности по сравнению с Nucleus RTOS, Nucleus SE также был разработан с упором на максимальную эффективность использования памяти и широкие возможности настройки.
Важной частью этого подхода является масштабируемость.
Многие функции ядра можно активировать или отключить по мере необходимости.
Очевидно, что отключение функциональности в конкретной реализации увеличивает ее несовместимость с Nucleus RTOS. В Nucleus RTOS можно создать систему с неограниченным количеством объектов ядра, единственным ограничением здесь является количество доступных ресурсов (то есть памяти).
Nucleus SE имеет ограничение в шестнадцать объектов каждого типа; в системе может быть от одной до шестнадцати задач и от нуля до шестнадцати объектов каждого типа (почтовые ящики, очереди и т.п.
).
Хотя этот предел можно увеличить, потребуются значительные усилия, поскольку Nucleus SE широко использует возможность хранения индекса объекта в полубайте (четыре бита).
Кроме того, при наличии более шестнадцати задач планировщик приоритетов, скорее всего, станет очень неэффективным.
Приложение, функциональность которого сильно страдает от этих ограничений, не подходит для Nucleus SE; в этом случае Nucleus RTOS — гораздо более подходящий выбор.
Предыдущие статьи серии: Статья №31. Диагностика и проверка ошибок ОСРВ Статья №30. Процедуры инициализации и запуска Nucleus SE Статья №29. Прерывания в Nucleus SE Статья №28. Программные таймеры Статья №27. Системное время Статья №26. Каналы: вспомогательные службы и структуры данных.
Статья №25. Каналы передачи данных: введение и базовые услуги Статья №24. Очереди: вспомогательные службы и структуры данных Статья №23. Очереди: введение и базовые услуги Статья №22. Почтовые ящики: услуги поддержки и структуры данных Статья №21. Почтовые ящики: введение и базовые услуги Статья №20. Семафоры: вспомогательные службы и структуры данных Статья №19. Семафоры: введение и базовые услуги Статья №18. Группы флагов событий: вспомогательные службы и структуры данных Статья №17. Группы флагов событий: введение и основные услуги Статья №16. Сигналы Статья №15. Разделы памяти: сервисы и структуры данных Статья №14. Разделы памяти: введение и основные службы Статья №13. Структуры данных задач и неподдерживаемые вызовы API Статья №12. Сервисы для работы с задачами Статья №11. Задачи: настройка и знакомство с API Статья №10. Планировщик: дополнительные возможности и сохранение контекста Статья №9. Планировщик: реализация Статья №8. Nucleus SE: внутреннее устройство и развертывание Статья №7. Nucleus SE: Введение Статья №6. Другие услуги ОСРВ Статья №5. Межзадачная связь и синхронизация Статья №4. Задачи, переключение контекста и прерывания Статья №3. Цели и планирование Статья №2. ОСРВ: структура и режим реального времени Статья 1. ОСРВ: введение.
Планировщик
Как и все современные ядра реального времени, Nucleus RTOS имеет очень гибкий планировщик, который обеспечивает несколько уровней приоритета (с неопределенным количеством задач на каждом уровне приоритета), а также предоставляет возможность выбора планировщика Round Robin и Time Slice. Nucleus SE намного проще и предлагает четыре планировщика, которые необходимо выбрать во время сборки: «Выполнение до завершения», «Радиальный перебор», «Временной интервал» и «Приоритет».Вы не можете комбинировать разные планировщики (то есть составного планировщика не существует).
Например, вы не можете выбрать комбинацию планировщиков Time Slice и Priority. Кроме того, планировщик приоритетов позволяет вам назначать только одну задачу каждому уровню приоритета, то есть существует столько уровней приоритета, сколько задач.
Приоритет задачи устанавливается во время сборки и больше не меняется (как и временной интервал, если выбран планировщик Time Slice).
API-вызовы
Интерфейс прикладного программирования (API) — это видимое «лицо» операционной системы.Неудивительно, что именно здесь различия между Nucleus RTOS и Nucleus SE наиболее очевидны.
API Nucleus SE отличается от API Nucleus RTOS. Однако API Nucleus SE тщательно разработан с учетом возможности переносимости в фрагмент API Nucleus RTOS. Обладатели лицензионной Nucleus RTOS могут получить «оболочку» (заголовочный файл, содержащий макросы #определять ), который выполнит передачу практически напрямую.
Поскольку API Nucleus SE можно назвать «подмножеством» API Nucleus RTOS, из этого следует, что некоторые вызовы API отсутствуют. Это действительно так и является неизбежным результатом критериев проектирования Nucleus SE. Некоторые вызовы API просто не имеют смысла, поскольку они включают в себя несуществующую функциональность, а другие вызовы были исключены для упрощения реализации некоторых объектов ядра.
Все это подробно описано в следующих разделах данной статьи.
Общие функции API
В Nucleus RTOS есть функции API, которые являются общими для нескольких различных типов объектов ядра или даже для всех типов объектов.Некоторые из них были реализованы в Nucleus SE, хороший пример такой функции — сброс.
Другие функции неприменимы к реализации объектов ядра в Nucleus SE. Создание и удаление В Nucleus RTOS все объекты ядра являются динамическими, они создаются и удаляются по мере необходимости.
Поэтому для этого существуют вызовы API. В Nucleus SE все объекты статичны (они создаются во время сборки), поэтому такие вызовы API не нужны.
Возврат указателей на объекты Основной идентификатор (дескриптор) объектов ядра в Nucleus RTOS — это указатель на управляющий блок объекта, который назначается при создании объекта.
Следовательно, существует также набор вызовов API, которые возвращают список указателей на объекты каждого типа.
Поскольку Nucleus SE использует простой индекс для идентификации объектов ядра, в таких вызовах нет необходимости.
Программа может опросить ядро, чтобы узнать, сколько экземпляров объекта определенного типа настроено (используя вызов типа NUSE_Mailbox_Count() ); если это значение равно н , индексы объектов этого типа будут иметь значения от нуля до n-1 .
Трансляция данных Некоторые типы основных объектов Nucleus RTOS (например, почтовые ящики, очереди и каналы) предоставляют вызов сервисного API для трансляции данных.
Это позволяет отправлять данные каждой задаче, которая ожидает данные от объекта.
Эта функция была удалена из Nucleus SE для простоты, поскольку доступ к данным таких объектов всегда выполняется в контексте конкретной задачи, которая затем освобождает объект. Следовательно, для реализации перевода потребуется дополнительный механизм флагов.
Уникальные возможности API объектов
Многие объекты ядра имеют вызовы API, которые уникальны для определенного типа объектов и различаются в Nucleus RTOS и Nucleus SE. Задания Поскольку планировщик Nucleus RTOS значительно сложнее планировщика Nucleus SE, некоторые функции API не нужны:- Изменение позиции прерывания задачи — не поддерживается в Nucleus SE.
- Изменение приоритета задачи.
В Nucleus SE приоритет задачи назначается во время настройки и не может быть изменен.
- Изменение временного интервала задачи — в Nucleus SE значение временного интервала является общим для всех задач и задается при настройке.
- Завершение задачи.
Nucleus SE не поддерживает состояние задачи «выполнено».
Следовательно, соответствующие функции API также не нужны.
Сигналы Nucleus RTOS поддерживает обработчики сигналов — программы, которые запускаются (аналогично обработчикам прерываний) при изменении сигналов задачи.
Эта функция была удалена из Nucleus SE, поэтому вызовы API для управления сигналами и создания обработчика сигналов не требуются.
Прерывания Nucleus SE использует подход к прерываниям невмешательства, просто предоставляя возможность выполнять некоторые вызовы API из обработчика прерываний.
Следовательно, некоторые вызовы API Nucleus RTOS, определяющие, как ядро должно обрабатывать прерывания, не поддерживаются.
Диагностика Nucleus SE имеет очень скромные диагностические услуги, следуя своему «сдержанному» стилю разработки, ограниченному (необязательной) проверкой параметров и выводом кода версии продукта.
Поэтому вызовы API Nucleus RTOS, связанные с ведением журнала истории и безошибочным подтверждением, не поддерживаются.
Драйверы Nucleus RTOS имеет четко определенную формальную структуру драйверов и несколько функций API, связанных с управлением драйверами.
Nucleus SE не имеет такой структуры, поэтому нет необходимости в соответствующих вызовах API.
Функциональность вызова API
Некоторые аспекты функциональности Nucleus SE, реализованные в упрощенном виде, приводят к отличиям от Nucleus RTOS. Некоторые из них влияют на то, как используются вызовы API и доступные сервисы.
Таймауты
При использовании Nucleus RTOS часто возникают ситуации, когда вызов API может приостановить задачу, ожидающую доступа к ресурсу: задача блокируется.Эта приостановка задачи может быть неявной (то есть до тех пор, пока ресурс не станет доступен) или может быть указано значение тайм-аута.
Nucleus SE в качестве опции предоставляет блокировку вызовами API, однако можно использовать только неявную приостановку (т. е.
вызов может использовать только NUSE_SUSPEND или NUSE_NO_SUSPEND , а не значение тайм-аута).
Эту функцию можно легко добавить в Nucleus SE.
Процедура приостановки
При создании нескольких типов объектов в Nucleus RTOS можно назначить порядок приостановки.Это последовательность, в которой несколько заблокированных задач будут возобновлены по мере появления ресурсов.
Доступны два варианта: FIFO, first in first out (первым пришел — первым вышел), при котором задачи возобновляются в том же порядке, в котором они были заблокированы; или по приоритету, при котором задача с наивысшим приоритетом всегда возобновляется первой.
Nucleus SE не предлагает такого выбора.
Он реализует только порядок по приоритету.
На самом деле правильнее говорить по индексу задачи, поскольку порядок приостановки можно применять не только при использовании планировщика Priority, но и при использовании планировщиков Round Robin и Time Slice.
Уникальная функциональность объектов
В некоторых случаях были необходимы изменения функциональности, связанные с определенными типами объектов.Обработчики сигналов Как упоминалось выше, реализация сигналов в Nucleus SE не поддерживает процедуры обработки сигналов.
Настройки таймера приложения Таймер имеет начальную продолжительность/продолжительность начального запуска и продолжительность перезапуска, а по завершении может дополнительно выполнять заданную пользователем функцию.
Эта функциональность поддерживается как в Nucleus RTOS, так и в Nucleus SE. Однако Nucleus SE, в отличие от Nucleus RTOS, не позволяет изменять описанные выше параметры при вызове API-функции сброса.
Кроме того, вся поддержка процедур завершения таймера в Nucleus SE не является обязательной.
Флаги событий Nucleus RTOS имеет возможность «поглощать» флаги событий.
Это означает, что флаги, соответствующие критериям, указанным в задаче, сбрасываются.
Данный функционал не поддерживается в Nucleus SE, так как возможность поиска совпадений по критериям нескольких задач существенно увеличивает сложность системы.
Измерения данных
Два критерия проектирования Nucleus SE: сохранение простоты и минимизация использования памяти привели к определенным различиям в размерах элементов данных по сравнению с Nucleus RTOS. Стоит отметить, что Nucleus RTOS обычно использует такие данные, как без подписи , который, скорее всего, 32-битный.в то время как Nucleus SE использует рационализированные типы данных, например.
U32 , U16 , U8 и так далее.
( Примечание переводчика: На мой взгляд автор прав в отношении 8-битных систем.
В современных системах регистры по-прежнему 32-битные, поэтому отсечение старшей части тратит память на код и такты на его выполнение, а данные при хранении в памяти по-прежнему выравниваются по 32 битам, иначе производительность системы снизится.
Так что такой подход не дает победы современным системам, но вполне может проиграть из-за добавленных компилятором команд, отсекающих старшую часть.
).
Почтовые ящики
В Nucleus RTOS в почтовом ящике хранится сообщение, состоящее из четырех беззнаковых элементов данных.В Nucleus SE в почтовом ящике хранится элемент данных типа АДРЕС .
По моему мнению, почтовые ящики часто используются для передачи адреса (указывающего на конкретные данные) от задачи к задаче.
Очереди
В Nucleus RTOS очередь обрабатывает сообщения одного или нескольких элементов данных типа без подписи .Очередь также можно настроить для обработки сообщений переменной длины.
В Nucleus SE очередь обрабатывает сообщения, состоящие из одного элемента данных типа АДРЕС .
На мой взгляд, очереди используются аналогично почтовым ящикам.
Кроме того, в Nucleus RTOS общий размер очереди (то есть общее количество беззнаковых элементов, которые можно поместить в очередь) указывается как беззнаковое значение.
В Nucleus SE это значение имеет тип U8 .
Следовательно, очередь может содержать меньше данных.
Каналы передачи данных
В Nucleus RTOS канал обрабатывает сообщения размером в один или несколько байтов; канал также можно настроить для обработки сообщений переменной длины.В Nucleus SE канал обрабатывает сообщения, состоящие из одного или нескольких элементов данных типа U8 .
Размер сообщения задается во время настройки для каждого канала.
Кроме того, в Nucleus RTOS общий размер канала (то есть общее количество байтов, которые могут поместиться в канал) указывается как значение типа неопаленный .
В Nucleus SE это значение имеет тип U8 и представляет количество сообщений (в вызове API NUSE_Pipe_Information() ).
Следовательно, канал может хранить меньше данных.
Группы флагов событий
В Nucleus RTOS группа флагов событий содержит 32 флага; в Nucleus SE их количество уменьшено до восьми.Этот размер был выбран потому, что вероятные целевые процессоры Nucleus SE могут эффективно обрабатывать 8-битные данные.
При этом не составит труда изменить количество флагов в группах флагов событий, обрабатываемых Nucleus SE.
Сигналы
В Nucleus RTOS каждая задача имеет набор из 32 сигнальных флагов.В Nucleus SE сигналы не являются обязательными, и каждая задача имеет набор из 8 флагов.
Этот размер был выбран потому, что вероятные целевые процессоры Nucleus SE могут эффективно обрабатывать 8-битные данные.
При этом не составит труда изменить количество флагов в наборах сигнальных флагов, обрабатываемых Nucleus SE.
Разделы памяти
В Nucleus RTOS количество и размер разделов имеют тип без подписи .В Nucleus SE количество разделов является параметром типа.
U8 , а размер раздела U16 .
Это приводит к некоторым ограничениям на размер разделов и пулов.
Таймеры
В Nucleus RTOS таймеры (как таймеры приложений, так и таймеры сна задач) работают со значениями типа без подписи .В Nucleus SE они типа U16 .
Этот тип был выбран потому, что вероятные целевые процессоры Nucleus SE могут эффективно обрабатывать 16-битные данные (а восьми бит явно недостаточно для использования таймера).
При этом изменить размер таймеров в Nucleus SE не составит труда.
В следующей статье мы рассмотрим, как Nucleus SE можно использовать в проекте встроенного программного обеспечения.
Об авторе: Колин Уоллс работает в электронной промышленности более тридцати лет, уделяя большую часть своего времени встроенному программному обеспечению.
В настоящее время он работает инженером-программистом в компании Mentor Embedded (подразделение Mentor Graphics).
Колин Уоллс — частый докладчик на конференциях и семинарах, автор многочисленных технических статей и двух книг по встроенному программному обеспечению.
Живет в Великобритании.
Профессиональный Блог Колина , электронная почта: [email protected]. Теги: #Программирование микроконтроллеров #Системное программирование #OSRW #RTOS #встроенное ПО #вызовы сервисных API
-
Имперфект
19 Oct, 24 -
Турбина
19 Oct, 24 -
Автомобильная Аудиосистема С 62 Динамиками
19 Oct, 24 -
Переход С Windows На Linux. Были Ли Попытки?
19 Oct, 24 -
Вышел Релиз-Кандидат Django 1.5
19 Oct, 24
