Теперь, когда инструмент готов, его уже можно и нужно использовать.

Предварительно пара слов про Главный Таймер.

Так сложилось, что моя деятельность связана с операционной системой реального времени (ОСРВ) QNX. Уже несколько лет занимаюсь разработкой как под эту ОС, так и некоторых частей самой системы. Обратил внимание на то, что поиск на хабре выводит немного результатов по запросу QNX, однако, мне кажется, что эта ОСРВ может быть интересна не только специалистам по встраиваемым и высоконадёжным системам, но и более широкой публике. Не секрет, что планшетный компьютер BlackBerry PlayBook производства компании RIM основан на QNX и имеет популярность и у нас.

Немного о QNX

ОСРВ QNX это не клон или дистрибутив Linux или ответвление какой-то другой UNIX-подобной системы. QNX самостоятельная UNIX-подобная операционная система реального времени, основанная на микроядре и передаче сообщений. Современные версии QNX имеют поддержку стандартов POSIX (и сертифицированны по ним). Первая версия QNX вышла в далёком 1981 году. С тех пор утекло достаточно много времени и поколения QNX сменяли друг друга: QNX2, QNX4 и, наконец, QNX 6 (или QNX Neutrino). Старичок QNX2 и сейчас ещё используется, хотя его расцвет пришёлся на 80-е годы прошлого столетия. Надёжная и более современная ОСРВ QNX4 могла конкурировать на десктопе с Windows в середине 90-х

Поскольку мой первый небольшой обзор операционной системы реального времени QNX показал, что среди жителей Хабра есть к ней интерес, то я решил продолжить цикл заметок. Мне кажется, что стоит немного рассказать о системной архитектуре QNX6. Думаю, что нелишне дать определение тому, что такое микроядро, и какие задачи оно решает. По ходу повествования будут также развенчаны два мифа, связанные с QNX. Но сначала…

Немного о POSIX

С выпуском каждой новой версии QNX (а надо отметить, что первая версия ОСРВ QNX появилась теперь уже в далёком 1981 году), разработчики использовали накопленный ранее опыт и делали систему лучше, в том числе и удобнее для разработчиков. Именно поэтому QNX Neutrino поддерживает стандарты POSIX 1003.1, например, управление потоками (threads), расширения реального времени (Realtime Extensions), дополнительные расширения реального времени (Additional Realtime Extensions) и профили прикладных окружений (Application Environment Profiles, AEP).

Зачем я об этом говорю?

Продолжение цикла заметок об операционной системе реального времени QNX. В этот раз я хотел бы рассказать о планировании потоков в QNX6^*. Как уже известно читателям (которые ознакомились с предыдущей заметкой цикла), микроядро QNX6 управляет потоками, а не процессами. И именно микроядро осуществляет загрузку контекста того потока, который должен получить управление в следующий момент. Выбор потока, который будет выполняться процессором (т.е. активно использовать процессорное время) и есть планирование потоков.

Когда происходит планирование потоков

Микроядро QNX Neutrino не работает постоянно, а получает управление только в случае системных вызовов, исключений и прерываний. Также микроядро во время своей работы выполняет планирование потоков. Отсюда можно сделать верный вывод, что операция планирования потоков происходит не сама по себе, а по какому-то событию.

Продолжение цикла заметок об операционной системе реального времени QNX. В этот раз я хотел бы рассказать о межзадачном взаимодействии в QNX Neutrino (мы будем рассматривать QNX 6.5.0). В ОСРВ существует широкий набор механизмов межзадачного взаимодействия — от специфичного для QNX обмена сообщениями до знакомых разработчикам UNIX и POSIX сигналов и разделяемой памяти. И хотя большая часть заметки будет посвящена обмену сообщениями, но особенности использования сигналов, сообщений POSIX и разделяемой памяти будут также описаны. А дочитавшие до конца получат две плюшки к чаю.

Понимание принципа обмена сообщениями является необходимым для системного программиста QNX, т.к. этот механизм играет фундаментальную роль в ОСРВ. Многие привычные и знакомые разработчикам функции операционной системы являются лишь надстройками и реализованы при помощи обмена сообщениями (например, read() и write()).

Здравствуйте. В короткой серии постов я постараюсь описать возможности, и подходы работы с одной из наиболее популярной и развивающейся РТОС для микроконтроллеров – FreeRTOS. Я предпологаю базовое знакомство читателя с теорией многозадачности, о которой можно почитать в одном из соседних постов на Хабре или ещё где-то.
Ссылки на остальные части:
FreeRTOS: межпроцессное взаимодействие.
FreeRTOS: мьютексы и критические секции.

Очередное продолжение цикла заметок об операционной системе реального времени QNX. Сегодня я бы опять хотел рассказать о межзадачном взаимодействии, но только об одном определённом механизме — Persistent Publish/Subscribe (PPS, устойчивая служба публикации/подписки). Сразу хочу отметить, это новый вид взаимодействия в QNX Neutrino, который появился только в версии 6.5.0. Технология PPS реализована не в микроядре, и за работу этого механизма отвечает специальный менеджер с говорящим названием pps.

Служба PPS оказалась настолько надёжной, удобной и простой в использовании, что применяется в новых решениях и продуктах, таких как, например, Smart Energy, QNX Car и даже планшет BlackBerry PlayBook.

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

Эта история началась в 1997 году. Но, чтобы задать нужную атмосферу, давайте быстро перенесемся в 2010 год и посмотрим снимок загруженности ЦПУ моего компьютера с четырёхядерным процессором:



При рассмотрении этого снимка бросаются в глаза две вещи. Первое, по-видимому у моего компьютера 8 ядер, а не 4. Это потому что каждое яро поддерживает одновременную мультипоточность; т.е. оно может выполнять две задачи одновременно. В результате операционная система видит каждое ядро не как один, а как два процессора.

Второе, каждое ядро показывает краткие, но интенсивные всплески загрузки процессора. Здесь это явление может иметь два объяснения:

Закончив изучение Таненбаума и ковыряние ядра Linux решил, что надо заняться чем-то дельным. По личным мотивам решил переделать ядро minix3 под планирование в жёстком реальном времени. Множество существующих алгоритмов планирования ввели меня в уныние, тем более, что хочется сделать ОС максимально универсальной и гибкой. Зацикленность на клиент-серверной модели привели к идеи о вынесении из ядра ОС механизмов планирования и разделение процессов на группы, управляемые: каждая своим планировщиком (в режиме ядра оставить только обработку deadline).
Основная проблема, которая стала очевидной сразу же — это выбор математической модели для построения алгоритма планирования. Очевидно, что подход разделения общего ресурса можно рассмотреть в аналогии с сетевыми протоколами разделения общего физического пространства.

Здравствуйте. Данная статья описывает одну из возможных реализаций паттерна Handler для FreeRTOS, предназначенного для обмена сообщениями между потоками. Статья предназначена в первую очередь для людей, использующих операционные системы в проектах для микроконтроллеров, энтузиастов DIY и людей изучающий ОСРВ и микроконтроллеры.
Предполагается, что читатель знаком с основными терминами, относящимися к ОСРВ, такими как очередь и поток. Более подробно ознакомиться с FreeRTOS можно в постах qdx FreeRTOS: введение и FreeRTOS: межпроцессное взаимодействие.
Те, кто участвовал а проектах для микроконтроллеров, используя FreeRTOS, возможно, сталкивался с тем, что стандартный API достаточно скуден, что приводит к необходимости написания дополнительного кода, который во многом повторяется. В моем случае ощущался недостаток инструментов для взаимодействия между потоками, а именно отсутствие унифицированной системы обмена сообщениями. Обычно для обмена инфомацией между потоками и синхронизации используются те или иные формы очередей. При этом тип информации, содержащейся в очереди, каждый раз разный, что снижает возможность повторного использования кода.
Использование унифицированной формы сообщения часто позволяет объединить несколько потоков в один Worker Thread, который обрабатывает полученные сообщения в порядке очереди.

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

Вы будете поражены! Всё, что показано тут – сама операционная система, графическая оконная подсистема, браузер, стек TCP/IP, менеджер файлов, игры и т.д. – разместились на одной загрузочной дискете размером всего 1.44 Мб. Никакого CD или жёсткого диска. И, как можно увидеть, демо может даже загружать и запускать программы (даже графические драйверы!), и все это на лету. Я бы сказал, что это круто!

Привет, Хабр!
Сегодня я расскажу о такой интересной штуке как операционная система реального времени(ОСРВ). Не уверен, что это будет интересно для бывалых программистов, но, думаю, новичкам понравится.

Что такое ОСРВ?

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

В последнее время все более активно развивается тематика встроенных (embedded) систем и многие крупные компании такие как Google, Microsoft, Intel вкладывают огромные ресурсы в исследования и разработки в данной области. Взять, например, проект Майкрософт по созданию специализированной ОС для умных домов homeos или процессоры от Intel для встроенных решений Intel Quark, а о различных исследовательских проектах от Google по робототехнике и говорить не стоит, они и так на слуху.

Подобные системы всегда имели свои особенности: ограниченность вычислительных ресурсов, различные процессорные архитектуры, порядок байт и многое другое. Всё это накладывает отпечаток на процесс разработки встроенного ПО. Несмотря на то, что в последнее время для создания встроенных систем все чаще применяются принципы и технологии из области “обычных” десктопных систем, сам процесс остается специфичным. Поэтому считается, что порог вхождения при разработке системного и встроенного ПО очень высокий. Для подготовки хороших специалистов в этой области на Мат-Мехе СПбГУ организовали исследовательский проект по созданию ОС реального времени для встроенных применений Embox, в котором активную роль играют студенты.



В четверг, 27 ноября, в 20:00 в бизнес-инкубаторе «Ингрия» состоится встреча CodeFreeze с Антоном Бондаревым, техническим руководителем проекта Embox. В докладе будет раскрыты аспекты разработки встроенного ПО на примере этой ОС.

Недавно я посетил конференцию разработчиков операционных систем OS Day. Организаторами были Дмитрий Завалишин, автор ОС Фантом, и ИСП РАН. Это уже вторая конференция, и на этот раз она проходила совместно с РИФ. Оба эти мероприятия были приурочены к официальному открытию города Иннополис, в котором, собственно, всё и происходило.

Я расскажу только о мероприятиях OS Day, поскольку сам в большинстве из них участвовал.

Отдавая должное гостеприимному Иннополису, я скажу, что по моим ощущениям, результаты гораздо заметнее, чем в Сколково. Стройка идёт очень активно, уже вовсю работает университет, и вообще жизнь в городе действительно есть, что не может не вселять надежду на светлое будущее.

Надеюсь, что долгожданное продолжение цикла заметок об операционной системе реального времени QNX. В этот раз я бы хотел рассказать о Qnet — собственном сетевом протоколе QNX. Сразу уточню, что помимо родной сети Qnet, в QNX поддерживается стек протоколов TCP/IP, работа с которым в общем-то должна быть знакома администраторам Unix-подобных систем. Поэтому в заметке сначала немного расскажу о сетевом администраторе io-pkt, а потом более подробно о протоколе Qnet. По ходу повествования нас также ждут четыре лирических и одно техническое отступления.

Что такое Qnet?

Сеть QNX представляет собой группу соединённых между собой целевых систем, каждая из которых работает под управлением ОСРВ QNX Neutrino. В такой сети любая программа имеет доступ к любому ресурсу на любом узле (node, именно так называются отдельные компьютеры в сети). В качестве ресурса может выступать файл, устройство или процесс (в том числе обеспечивается и запуск процессов на другом узле). При этом целевые системы (те самые узлы) могут представлять собой компьютеры различных архитектур — x86, ARM, MIPS и PowerPC (текущая реализация Qnet работает в том числе и в cross-endian среде). Но словно этого мало, любое POSIX-приложение, портированное в QNX (для переноса зачастую требуется только пересборка) без всякой доработки будет обладать перечисленными выше способностями работы в сети Qnet. Заинтригованы, как это получается?

Всем привет! В данной статье я бы хотел поделиться опытом создания драйверов для платформ серии stm32. Идея заключается в том, чтобы в ОС Embox, не приходилось создавать драйвера для каждой серии платформ STM32F3, STM32F4 и так далее. Ведь кроме того, что это занимает время, новый код неизбежно будет содержать новые ошибки.

Добрый день!

Потоки… Переключение контекстов… Базовая сущность ОС. И конечно, при разработке библиотек и приложений мы всегда полагаемся на то, что реализация потоков безошибочна. Поэтому было неожиданно найти грубую ошибку в переключении потоков для STM32 на ОСРВ Embox, когда уже продолжительное время работали и сеть, и файловая система и многие сторонние библиотеки. И мы даже успели похвастаться о своих достижениях на Хабре.

Я бы хотел рассказать про то, как мы делали переключение потоков для Cortex-M, и тестировали на STM32. Кроме того, постараюсь рассказать о том как это сделано в других ОС — NuttX и FreeRTOS.

Здравствуйте!

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

Я расскажу об особенностях работы этой ОСРВ. Если о чём-то другом, то только потому, что без этого будут непонятны особенности.

Ниже я расскажу об особенностях ОСРВ вообще, и об особенностях ОСРВ МАКС в частности. Представлю ее архитектуру.

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

Я продолжаю выкладывать главы «Книги знаний» ОСРВ МАКС. Первая часть была общей. Сегодня вторая часть, посвященная ядру и приоритету задач.

Содержание (опубликованные и неопубликованные статьи):

Часть 1. Общие сведения
Часть 2. Ядро ОСРВ МАКС (настоящая статья)
Часть 3. Структура простейшей программы
Часть 4. Полезная теория
Часть 5. Первое приложение
Часть 6. Средства синхронизации потоков
Часть 7. Средства обмена данными между задачами
Часть 8. Работа с прерываниями

Задача

Как уже упоминалось, задача в ОСРВ МАКС является аналогом потока в ОС общего назначения. Одновременно в системе может исполняться произвольное число задач (в рамках доступных ресурсов, разумеется). В ОС общего назначения на этом можно было бы прекратить теоретизировать и переходить к практике, но в случае с ОС реального времени программист должен быть уверен, что он сделал всё верно и задачи будут гарантированно получать столько процессорного времени, сколько им требуется. А чтобы всё сделать верно, необходимо знать кое-какую теорию. Поэтому рассмотрим работу задач более подробно.

Добрый день! Не секрет, что стандартные примеры, работающие из коробки, — штука неплохая: загрузил на плату и наслаждайся. Это удобно для быстрого ознакомления. Но затем, если мы намерены сами что-то создать, нужно разбирать код примера, читать документацию, писать свой код, долго отлаживаться… Хочется этот этап как-то упростить. По этой причине, я хотел бы рассказать о том, как мы сделали интеграцию стандартных примеров из библиотеки STM32Cube в Embox.