TNeo: тщательно протестированная РТОС для Cortex-M0/M0+/M3/M4/M4F, PIC24/dsPIC, PIC32MX. Опции

[dimonomid]

Представляю новое ядро реального времени: TNeo. Как можно догадаться из названия, изначально она основана на TNKernel, но в итоге код был переписан почти полностью (потому что оригинальный код, по моему мнению, далек от совершенства), написаны подробные юнит-тесты, исправлены ошибки и добавлено много новых фич.

Список найденных и исправленных ошибок в TNKernel 2.7 можно посмотреть тут: http://dfrank.bitbucket.org/tneokernel_api...implement__bugs

Код TNeo написан аккуратно и тщательно, документирован очень подробно. Документация генерируется автоматически посредством doxygen, таким образом, легко поддерживать документацию в актуальном состоянии:

• html
• pdf

Список новых возможностей:

* Dynamic tick (опционально): если системе нечего делать, эта опция позволяет действительно ничего не делать (уйти в sleep), и даже не просыпаться каждую миллисекунду для обработки системного тика. Подробнее: http://dfrank.bitbucket.org/tneokernel_api...time_ticks.html
* Timer: позволяет попросить ядро запустить пользовательскую функцию через определенный промежуток времени. Подробнее: http://dfrank.bitbucket.org/tneokernel_api...__timer_8h.html
* Event group connection: позволяет "соединить" группу флагов с другими объектами РТОС. Очень удобно в случаях, когда в задаче нужно ждать, скажем, сообщения из нескольких очередей, или ждать каких-то флагов плюс сообщения из очереди. Подробнее: http://dfrank.bitbucket.org/tneokernel_api...ventgrp_connect
* Profiler (опционально): позволяет узнать общее время работы каждой задачи, максимальное время работы задачи подряд и т.д. Полезно для отладки.
* Software stack overflow check (опционально) - программный контроль переполнения стека, очень существенно облегчает дебаг;
* Recursive mutexes (опционально) - позволяет вложенную блокировку мютексов;
* Mutex deadlock detection (опционально) - в случае deadlock, ядро сообщает об этом посредством callback-функции;
* Separate interrupt stack - на всех поддерживаемых платформах прерывания используют отдельный стек.

Полный список фич тут: http://dfrank.bitbucket.org/tneokernel_api...l/features.html
Отличия API TNeo от API TNKernel 2.7 тут: http://dfrank.bitbucket.org/tneokernel_api...ernel_diff.html

Чем не устраивает TNKernel: см. документацию: Why reimplement TNKernel, также можно посмотреть мой старый пост на этом форуме: http://electronix.ru/forum/index.php?s=&am...t&p=1280109

Кратко: ключевые проблемы TNKernel:

• Самая основная проблема в том, что TNKernel - проект, написанный на коленке, т.е. в спешке. Огромное количество дублирования кода, непоследовательности и недостаточной продуманности.
• Проект не тестировался (только "вручную", как это нередко делается в эмбеддинге, к сожалению). Среди найденных багов есть банальнейшие ситуации с мютексами, которые не обрабатываются ядром корректно (см. ссылку на список багов выше). Ну, учитывая первый пункт про спешку, отсутствие тестов неудивительно, т.к. на них нужно огромное количество времени. У меня на тесты ушло примерно столько же времени, сколько на само ядро.
• Документация живет отдельной от самого ядра жизнью.
• Проект не поддерживается. Я присылал Юрию исправления некоторых ошибок, мои сообщения были проигнорированы.

Любопытный читатель может спросить: если уж я так сильно ругаю TNKernel, почему же я взял это ядро за основу? С удовольствием отвечу: не смотря на то, что реализация TNKernel, по моему мнению, далека от совершенства, идеи, стоящие за реализацией, я считаю в целом очень достойными. Ядро компактное и быстрое, и данные организованы грамотно.

Я хотел переписать его так, чтобы на код было приятно смотреть и легко модифицировать (не боясь что-то сломать), хотел быть уверенным в отсутствии багов (посредством юнит-тестов), хотел достойную актуальную документацию. Все это готово.

Попутно я реализовал вещи, которых мне самому раньше не хватало, плюс реализовал пожелания людей, заинтересовавшихся проектом (я представил TNeo на семинаре Microchip MASTERS 2014, после чего и получил предложение реализовать порт для линейки Cortex-M и несколько других фич)

Выражаю огромную благодарность Юрию за проделанную работу над TNKernel: без нее, конечно, TNeo никогда не появилась бы. Полный список благодарностей можно прочитать на странице Thanks.

[Xenia]

Так что ничего особо сложного, если есть желание - главное начать!

Есть обстоятельства, охлаждающие такое желание. Например, этой ночью появилась (точнее - была выложена на сайт) очередная версия FreeRTOS V8.2.0. По этому случаю я заглянула в список поддерживаемых ею МК и очень удивилась его широте. Вероятно, там не один человек работает, а целая компания.

Так вот я вижу в том списке среди многих прочих типов интересующие меня архитектуры МК (AVR и Cortex-R4F), которые в настоящий момент не поддерживает ни TNKernel, ни TNeo. А психика любого человека, как и психика разработчика, такова, что когда есть что-то готовое, и к тому же бесплатное, то очень трудно решиться на самостоятельные проекты, достигающие той же цели, но только другим путем. Опять же колеблешься, опасаясь возможных трудностей или возникающих проблем в процессе самостоятельного творчества, тогда как перед тобой уже находится готовый халявный вариант, который нахваливает целая толпа народа.

В этой связи у меня к вам просьба похаять FreeRTOS, указав на присущие ей недостатки, но которые отсутствуют у TNKernel/TNeo. Т.е. что в принципе можно выиграть, если использовать TNeo вместо FreeRTOS? Полагаю, что даже в том случае, если бы я не задала вам этот вопрос, то его обязательно задал бы кто-то другой, т.к. конкуренция между различными RTOS/OS - типичное дело. Да и вы сами, надо полагать, имели в голове какие-то свои соображения, если в самом начале сделали ставку на TNKernel, даже в ее недоработанном виде. Тем более что здесь и без FreeRTOS других конкурентов полно, и всяк себя в захлеб хвалит.

[AlexandrY]

В этой связи у меня к вам просьба похаять FreeRTOS, указав на присущие ей недостатки, но которые отсутствуют у TNKernel/TNeo

Так это запросто, если вы знаете FreeRTOS то должны знать, что то там нет такой фичи как Event group connection

А это реально очень полезная фича.
В задачу действительно могут посылаться и события и майлбоксы и потоки и на все надо реагировать сразу без последовательного полинга всех объектов синхронизации от которых ожидается изменение состояния.
Во FreeRTOS такого простого механизма реагировать на все сразу в одном вызове сервиса RTOS нет.

Правда в TNeo это реализовано несколько прямолинейно и не гибко.

В MQX, например, не надо создавать некую группу специфических флагов, а у очередей, семафоров и проч. сервисов можно установить специальную функцию нотификации.
А в функции нотификации можно уже взводить хоть флаги хоть кучу флагов для разных задач.

Зачем третья задача? Двух задач, использующих флешку без блокировки этого ресурса, достаточно для нарушения нормальной работы.

Это понятно, но приоритет тогда зачем поднимать. Тогда семафора достаточно.

Ведь чем больше разнородных сервисов в RTOS тем труднее программировать.
Все стремятся ограничиться минимальным набором сервисов и вот мьютексы тут как-то негармонично смотрятся.

[dimonomid]

В MQX, например, не надо создавать некую группу специфических флагов

Ну, на самом деле это не "специфические" флаги, у меня обычно есть просто группа флагов для какой-то задачи, и в этой группе есть и флаги для соединения с очередями, и любые другие флаги, которые нужны задаче. Удобно.

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

Хм, вообще коллбэк - хорошая идея, надо подумать. Гибкость, действительно, на высоте: в коллбэк-функции можно делать что хочешь, если надо.

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

Может, у вас есть какие-то примеры, что еще может быть реально полезно сделать в этом коллбэке?

Ну и если нужно только установить флаг, то в случае с коллбэком нужно будет сделать для этого больше телодвижений, чем сейчас: нужно будет написать специальную функцию, в ней вручную ставить/снимать флаг, и зарегистрировать коллбэк в TN_DQueue. А сейчас нужно просто вызвать tn_queue_eventgrp_connect() и передать туда указатель на группу флагов и маску.

Подумаю, спасибо.

Это понятно, но приоритет тогда зачем поднимать. Тогда семафора достаточно.

Ведь чем больше разнородных сервисов в RTOS тем труднее программировать.
Все стремятся ограничиться минимальным набором сервисов и вот мьютексы тут как-то негармонично смотрятся.

Мютексы и семафоры созданы для совершенно разных задач, и некоторая схожесть их API порождает огромное количество путаницы в головах. Семафор - механизм сигнализирования, мютекс - механизм блокировки ресурсов. Статья Michal Barr была именно об этом, вот еще до кучи вопрос-ответ на stackoverflow: http://stackoverflow.com/questions/62814/d...phore-and-mutex

Поэтому я, конечно, не вижу никакой дополнительной сложности программирования и негармоничности мютексов. У мютексов и у семафоров совершенно разные предназначения.

но приоритет тогда зачем поднимать.

Чтобы не было инверсии приоритетов, т.е. чтобы не получилось так, что высокоприоритетная задача Б будет ждать низкоприоритетную задачу А (из моего прошлого примера про SPI флешку)

[AlexandrY]

Может, у вас есть какие-то примеры, что еще может быть реально полезно сделать в этом коллбэке?

В этом коллбэке можно например создать ту задачу которая будет обрабатывать событие.

Мютексы и семафоры созданы для совершенно разных задач, и некоторая схожесть их API порождает огромное количество путаницы в головах. Семафор - механизм сигнализирования, мютекс - механизм блокировки ресурсов. Статья Michal Barr была именно об этом, вот еще до кучи вопрос-ответ на stackoverflow: http://stackoverflow.com/questions/62814/d...phore-and-mutex


Чтобы не было инверсии приоритетов, т.е. чтобы не получилось так, что высокоприоритетная задача Б будет ждать низкоприоритетную задачу А (из моего прошлого примера про SPI флешку)

Все эти рассуждения в принципе наверно правильны если мы говорим об OS типа Windows.

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

К сведению в RTOS Nucleus Plus вообще нет мьютексов, там их роль блокировки к разделяемым ресурсам выполняют семафоры.
Приоритеты задач в Nucleus не поднимаются семафорами автоматически, для этого есть явные функции управления приоритетами. И это более близко по духу к realtime.
А есть еще такие понятия как Lightweight Semaphores, угадайте чем они отличаются от обычных семафоров.
А например в MQX подъем приоритета семафоры делают также как и мьютексы.

Вторая фишка в том что если в Windows семафоры сложнее мьютексов, то в RTOS наоборот. Поэтому чтобы не замедлять программу от мьютексов тянет отказаться.

Т.е. не советую как аргумент ссылаться на stackoverflow.com где большинство в глаза видели один лишь PC.

[dimonomid]

Все эти рассуждения в принципе наверно правильны если мы говорим об OS типа Windows.

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

То, что есть разные трактовки этих терминов - это как раз следствие того, что в головах многих разработчиков путаница. И я не согласен эту путаницу поддерживать, в отличие от разработчиков Nucleos и других продуктов, где термин семафор используется вместо мютекса (да, таких продуктов много, к сожалению).

"Семафор", как следует из названия, нужен для сигнализирования, а "мютекс", как опять же следует из названия (mutual exclusion - взаимное исключение), нужен для блокировки ресурсов между конкурирующими потоками.

Как раз при разработке РТОС я считаю более правильным сослаться на описание мютексов и семафоров "сферических в вакууме", чем на другие реализации, которые только вводят в заблуждение. Типа, у них сделано криво - давайте тоже сделаем криво.

В TNeo роль этих объектов предельно близка к парадигме. Мютекс мы можем заблокировать (tn_mutex_lock) и разблокировать (tn_mutex_unlock); семафор мы можем ждать (tn_sem_wait) и сигналить (tn_sem_signal).