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.

[AlexandrY]

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

Не могли бы вы показать примеры ваших разработок с использованием RTOS?

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

Скажем такие страсти вокруг мьютексов.
С виду нужная фича.
Но вот смотрю в MQX в основном дистрибутиве и не нахожу где бы вызывались сервисы мьютексов.
Хотя в RTOS они реализованы, хорошо документированы, развиты.
Но во всем промежуточном ПО включая файловую систему, USB стеки, TCP/IP стеки, сетевые сервисы, командные оболочки, драйверы нигде не применяются мьютексы.

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

[dimonomid]

Не могли бы вы показать примеры ваших разработок с использованием RTOS?

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

Скажем такие страсти вокруг мьютексов.
С виду нужная фича.
Но вот смотрю в MQX в основном дистрибутиве мьютексы вообще! нигде не применяются.
Хотя в RTOS они есть, хорошо документированы, развиты.
Но во всем промежуточном ПО включая файловую систему, USB стеки, TCP/IP стеки, сетевые сервисы, командные оболочки, драйверы нигде не применяются мьютексы.

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

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

То, что многие эмбеддеры не знают, зачем нужны мютексы, не новость: вот яркий пример http://www.microchip.su/showthread.php?p=1...near#post185067 . Да что там мютексы, многие не знают зачем нужна РТОС. Типа, и так можно написать. Спорить не буду - можно и без мютексов написать, и без РТОС, и без C, и т.д.

Вот очень хорошая небольшая статья на тему мютексов и семафоров http://www.barrgroup.com/Embedded-Systems/...Mutex-Semaphore

Вкратце, мютекс нужен для доступа к разделяемому ресурсу. Например, если в двух (или более) задачах используется, скажем, внешняя SPI-флешка, т.е. они обе эту флешку читают/пишут, то нужно быть уверенным в том, что они не будут друг другу мешать работать с флешкой. С этим не будете спорить?

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

То, что в большинстве библиотек не используются мютексы - логично, потому что в большинстве случаев мютексы должны уже использоваться в самом приложении, а не в библиотеке. Взять вот тот же пример с флешкой: допустим, я оформлю библиотеку для чтения-записи во флеш в виде библиотеки. Если в приложении эта библиотека будет использоваться, например, только из одной задачи, то и мютекс тут необязателен. Так зачем включать его использование в либу? Разумнее сделать так: обязать пользователя реализовать две функции: lock() / unlock(), и при работе с флешкой вызывать их. Если пользователь либы решит использовать мютекс, он будет его использовать в этих lock() / unlock(). А может, он решит как-то иначе обеспечивать атомарный доступ, а может вообще не нужна ему блокировка, тогда он оставит эти функции пустыми, и все.

У меня в среднего размера проекте обычно 5-7 задач и около 10 мютексов, если что. Вообще, рассуждать на эти темы нет особого желания. Если человек утверждает, что мютексы-де не нужны, то обычно получается просто религиозный спор. Как я уже сказал, да, можно все написать и без мютексов, и без РТОС, и т.д.

[AlexandrY]

То, что многие эмбеддеры не знают, зачем нужны мютексы, не новость: вот яркий пример http://www.microchip.su/showthread.php?p=1...near#post185067 . Да что там мютексы, многие не знают зачем нужна РТОС. Типа, и так можно написать. Спорить не буду - можно и без мютексов написать, и без РТОС, и без C, и т.д.

Вот очень хорошая небольшая статья на тему мютексов и семафоров http://www.barrgroup.com/Embedded-Systems/...Mutex-Semaphore

Вкратце, мютекс нужен для доступа к разделяемому ресурсу. Например, если в двух (или более) задачах используется, скажем, внешняя SPI-флешка, т.е. они обе эту флешку читают/пишут, то нужно быть уверенным в том, что они не будут друг другу мешать работать с флешкой. С этим не будете спорить?

Да, на форуме microchip.su некто клаccно отмахнулся.
Дескать нет таких примеров где абсолютно необходим мьютекс.
Как и нет таких примеров где нельзя без RTOS.

Да вот примеров где нельзя без RTOS навалом. Намедни я вон даже у ардуино RTOS обнаружил.

Статья на barrgroup.com в принципе правильная. И указывает однозначно, что необходимость в мьютексах возникает при наличии некой третьей мешающей задачи.
В сценарии SPI я не вижу третьей задачи которая вмешалась бы и нарушила работу планировщика на основе Rate Monotonic Algorithm (RMA)

Более того если задача обращается к разделяемому ресурсу я ее сразу же перестаю считать realtime задачей, а следовательно и принцип RMA на нее не распространяю.
Т.е. ей и мьютекс уже как бы не требуется.

Тут я вижу некое противоречие.

Вот скажите честно, вы применяете теорию RMA на практике? Оцениваете точно длительности выполнения всех задач? У вас все задачи всегда выполняются в строго отведенное известное время?

[dimonomid]

Да, на форуме microchip.su некто клаccно отмахнулся.
Дескать нет таких примеров где абсолютно необходим мьютекс.
Как и нет таких примеров где нельзя без RTOS.

Да вот примеров где нельзя без RTOS навалом. Намедни я вон даже у ардуино RTOS обнаружил.

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

... необходимость в мьютексах возникает при наличии некой третьей мешающей задачи.
В сценарии SPI я не вижу третьей задачи которая вмешалась бы и нарушила работу планировщика на основе Rate Monotonic Algorithm (RMA)

Зачем третья задача? Двух задач, использующих флешку без блокировки этого ресурса, достаточно для нарушения нормальной работы. Например, предположим что для записи во флеш нужно сначала передать по SPI команду на запись, потом адрес, потом передавать данные для записи. И есть две задачи: А хочет записать какие-то 100 байт по адресу 0x1000, Б хочет записать 100 байт по адресу 0x2000. Теперь последовательность без мютекса:

* Задача А передает команду на запись и адрес 0x1000
* Задача А начинает передавать данные для записи - передала 10 байт из 100
* Высокоприоритетная задача Б вытесняет задачу А
* Задача Б передает команду на запись и адрес 0x2000
* Задача Б передает данные для записи - 100 байт
* Задача Б уходит в ожидание, управление передается задаче А
* Задача А продолжает передавать данные - передает оставшиеся 90 байт, но они уже будут записаны не туда, куда нужно.

Вот скажите честно, вы применяете теорию RMA на практике? Оцениваете точно длительности выполнения всех задач? У вас все задачи всегда выполняются в строго отведенное известное время?

Нет.

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

Не буду хаять, извините, потому что сам всерьез и не использовал. От коллег, имевших опыт работы как с FreeRTOS, так и с TNKernel, наслушался, что FreeRTOS очень медленная по сравнению с TN: назывались цифры типа от момента отправки сообщения в задачу до получения задачей управления происходит примерно в 2 раза больше инструкций, чем в случае с TN. Но сам я все это не проверял, так что ручаться не буду.

Может когда-нибудь и дойдут руки до подобных сравнений, но пока нет. Есть более важные вещи.

Вообще, по чесноку, я на вашем месте, наверное, взял бы FreeRTOS и не парился. Если не будете успевать - возьмите железо мощнее. Ведь, как вы заметили, над FreeRTOS работает команда, а не один человек, так что шансы на то, что проект вдруг перестанет поддерживаться, у FreeRTOS гораздо ниже. TNKernel вот уже, фактически, не поддерживается; TNeo сегодня поддерживается, а завтра - неизвестно.