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.

[Aner]

Философия однако, не даром западные программисты все доктора философскмх наук, а не доктора лингвистики по языкам. Для кого как а для меня "мютекс" это и есть один из видов "Семафора". Наверное как и вы, я пользую (к примеру при юзании Free RTOS) их очень много и везде, не очень понимаю как без них можно писать, начиная уже с 2-3 ниток, даже средненький софтик. Но вот разницу в TNeo и Free RTOS к примеру в v7.1 не очень увидел. TNeo, возможно ценна другим, ... вот в чём?

[dimonomid]

Для кого как а для меня "мютекс" это и есть один из видов "Семафора".

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

Использование мютекса всегда сводится к следующему: задача А заблокировала мютекс, задача А разблокировала мютекс. Не может быть другой последовательности. Пока мютекс заблокирован задачей, никто больше не может его заблокировать, и никто кроме задачи А также не может его разблокировать.

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

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

Еще раз дам эту ссылку на stackoverflow, где человек чуть подробнее объясняет то же самое: http://stackoverflow.com/a/86021/1099240.

Но вот разницу в TNeo и Free RTOS к примеру в v7.1 не очень увидел. TNeo, возможно ценна другим, ... вот в чём?

Я уже выше писал, что я всерьез не использовал FreeRTOS, так что не смогу вам ответить. Ну вот товарищ AlexandrY отметил, что в FreeRTOS нет event group connection, а это иногда ну очень удобно. От коллег слышал что FreeRTOS значительно медленнее TNKernel, но сам не проверял.

Сообщение отредактировал dimonomid - Jan 19 2015, 18:51

[AlexandrY]

Использование мютекса всегда сводится к следующему: задача А заблокировала мютекс, задача А разблокировала мютекс. Не может быть другой последовательности. Пока мютекс заблокирован задачей, никто больше не может его заблокировать, и никто кроме задачи А также не может его разблокировать.

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

Ну зачем париться об инверсии если не подводите структуру задач под Rate Monotonic Algorithm ?
Есть там инверсия или нет инверсии вашему софту все равно будет по барабану.
Это же не deadlock, а вполне себе невинная коллизия.

И потом, разве в TNeo мьютекс не будет удален при удалении создавшей его задачи?
Логично ожидать его удаления, а значит мьютексы можно разблокировать и из других задач.
Т.е. принципиальная разница с семафором не такая уж и огромная.

[dimonomid]

Ну зачем париться об инверсии если не подводите структуру задач под Rate Monotonic Algorithm ?
Есть там инверсия или нет инверсии вашему софту все равно будет по барабану.

Нет, не по барабану. Если вашему софту по барабану, значит, вашим задачам и приоритизация вообще не нужна: сделать все тупо одного приоритета, да и все. У меня же бывают задачи, для которых существуют требования типа "задача X обязана отреагировать на сообщение Y в течение времени Z". Необязательно все прям рассчитывать с точностью до микросекунд, бывает просто эмпирически становится ясно, что определенная задача перестает успевать за естественными требованиями по времени.

И потом, разве в TNeo мьютекс не будет удален при удалении создавшей его задачи?
Логично ожидать его удаления, а значит мьютексы можно разблокировать и из других задач.

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

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

Т.е. принципиальная разница с семафором не такая уж и огромная.

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

Если есть что-то конкретно по TNeo - с удовольствием отвечу, а если только холивар про использование примитивов синхронизации, то давайте лучше просто займемся своими делами.

Про то что FreeRTOS значительно медленнее TNKernel думаю, так говорить некорректно; от задачи и окружения зависит

Ладно, это спор без фактов: как я вам сразу сказал, я сам не проверял. Насколько я слышал, сравнения проводились при прочих явных условиях без побочных вещей: типа, отправляем сообщение из задачи А в высокоприоритетную задачу Б и смотрим сколько прошло тиков до получения управления задачей Б.

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

[AlexandrY]

Нет, не по барабану. Если вашему софту по барабану, значит, вашим задачам и приоритизация вообще не нужна: сделать все тупо одного приоритета, да и все. У меня же бывают задачи, для которых существуют требования типа "задача X обязана отреагировать на сообщение Y в течение времени Z". Необязательно все прям рассчитывать с точностью до микросекунд, бывает просто эмпирически становится ясно, что определенная задача перестает успевать за естественными требованиями по времени.

Ну, и были случаи когда только мьютекс помогал задаче гарантированно выполниться до deadline?

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

Т.е. ваш код не отрабатывает аварийные ситуации, пилит и пилит дальше не смотря ни на что?
А у других 90% кода это сплошь обработка аварийных ситуаций знаете-ли, иначе сертификацию не пройдут.

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

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

[dimonomid]

Ну, и были случаи когда только мьютекс помогал задаче гарантированно выполниться до deadline?

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

Т.е. ваш код не отрабатывает аварийные ситуации, пилит и пилитдальше не смотря ни на что?
А у других 90% кода это сплошь обработка аварийных ситуаций знаете-ли, иначе сертификацию не пройдут.

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

И приведите пожалуйста примеры, когда вы используете удаление задачи в качестве разрешения нештатной ситуации?

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

Единственный объект синхронизации, привязанный к задаче - мютекс. Например, выделенная из TN_FMem или вообще из кучи память никак не привязывается к задаче (т.к. память легко может быть выделена в одной задаче, а освобождена в другой), так что удаление задачи, выделяющей память динамически, может привести к утечке памяти. Хотя, конечно, не удивлюсь, если вы и динамическое выделение памяти не используете.

[LightElf]

Хотя, конечно, не удивлюсь, если вы и динамическое выделение памяти не используете.

Да, многие не используют динамическое распределение памяти в embedded системах. Одна из холиварных тем. Но кучи в системах высокой ответственности - однозначное зло.

Сообщение отредактировал LightElf - Jan 20 2015, 09:49

[dimonomid]

Но кучи в системах высокой ответственности - однозначное зло.

Куча - согласен, зло, т.к. поведение недетерминировано. Но кроме кучи есть другие инструменты для динамического распределения памяти - например, TN_FMem (и аналоги в других ядрах). Это - не зло