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 или вообще из кучи память никак не привязывается к задаче (т.к. память легко может быть выделена в одной задаче, а освобождена в другой), так что удаление задачи, выделяющей память динамически, может привести к утечке памяти. Хотя, конечно, не удивлюсь, если вы и динамическое выделение памяти не используете.

[AlexandrY]

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

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

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

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

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

Во первых половину задач я создаю динамически. Их цель выполнить операцию и прекратить свое существование.
Например дали команду с клавиатуры сложному механизму выполнить определенное движение.
На запуск движения (еще не на само движение) создается задача.
Движение сложного механизма сопряжено с выполнение многих подготовительных действий.
Это управление элементами индикации: лампочки, бузера; включение или выключение каких-то соленоидов, активация вспомогательных приводов и проч. и проч.
И вот если какая либо из этих мелочей по ходу не сработает или не даст подтверждения происходит аварийная выгрузка задачи. В MQX это будет просто команда return errorcode. И все!
Все мьютексы, семафоры, флаги, блоки памяти занятые этой задачей будут освобождены автоматически. Никаких хлопот.

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

Не возводите только в ранг стандарта то, что сами себе придумали. Как написал выше в развитых RTOS это не так.

Кстати советую подумать зачем мьютексы нужны в Windows если это не система реального времени и на инверсию приоритетов... ну она там точно не важна.

[dimonomid]

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

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

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

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

Но я наверное слишком идеалист для эмбеддерства и вообще не прав.

Не возводите только в ранг стандарта то, что сами себе придумали. Как написал выше в развитых RTOS это не так.

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

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

[AlexandrY]

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

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

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

Ваш пример с SPI тоже не отличается прямизной. Для таких дел специально созданы сервисы очередей.
Зачем задачам которые должны абстрагироваться от аппаратуры лазить в SPI, разбираться с адресами , данными?
Это означает подкладывание под свой софт мины межплатформенной несовместимости.
Если на такую архитектуру софта рассчитана ваша RTOS, то я конечно дальше обсуждать не буду.

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

Nucleus Plus стоит на 3-х миллиардах дивайсов и не имеет мьютексов. Это должно кое о чем говорить.

[dimonomid]

Ваш пример с SPI тоже не отличается прямизной. Для таких дел специально созданы сервисы очередей.
Зачем задачам которые должны абстрагироваться от аппаратуры лазить в SPI, разбираться с адресами , данными?

Совсем необязательно задачам, которым нужно так или иначе что-то прочитать из флеши, самостоятельно "разбираться с адресами, данными". К железу привязан только bsp-layer (board support package). Задача обычно вызывает функции далеко абстрагированного от железа модуля, который, прямо или косвенно, в итоге читает из флеши то, что ему нужно.

И расскажите, как здесь правильно пользоваться сервисами очередей.

Nucleus Plus стоит на 3-х миллиардах дивайсов и не имеет мьютексов. Это должно кое о чем говорить.

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

В ThreadX есть мютексы и она стоит на миллиарде девайсов (как у них на сайте указано), ну и что.

[AlexandrY]

Совсем необязательно задачам, которым нужно так или иначе что-то прочитать из флеши, самостоятельно "разбираться с адресами, данными". К железу привязан только bsp-layer (board support package). Задача обычно вызывает функции далеко абстрагированного от железа модуля, который, прямо или косвенно, в итоге читает из флеши то, что ему нужно.

И расскажите, как здесь правильно пользоваться сервисами очередей.

Таким подходом опять нарушается принцип реального времени.
Вызывая функции которые только опосредованно где-то могут обращаться с Flash и могут тормозить на мьютексах вы еще больше себе затрудняете анализ что называется schedulability.
Где детерминизм? Видим в тексте такую функцию вызова сервиса BSP и ничего не можем сказать о времени ее исполнения. Это уже не realtime приложение.

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

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

Все на виду и анализируемо.

В ThreadX есть мютексы и она стоит на миллиарде девайсов (как у них на сайте указано), ну и что.

Методом от обратного было доказано, что мьютексы не есть необходимость для развитой RTOS и вообще для реального времени.
Следовательно и маркетинговый эффект от их реализации сомнительный.

[dimonomid]

А надо было бы организовать во-первых задачу менеджера SPI шины.

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

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

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

[AlexandrY]

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


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

Панацеи нет, но есть плохие и хорошие лекарства. И это стоит обсуждать.
Что можно без RTOS, а что нельзя, кстати, тоже интересная тема.
Но нет так нет.
Значит ваша ось все таки ради искусства.

[dimonomid]

Панацеи нет, но есть плохие и хорошие лекарства.

Не плохие и хорошие, а подходящие или не подходящие для решения конкретной задачи.