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]

Представляю новое ядро реального времени: TNeo.

А скачать-то ее откуда-нибудь можно? Или отсюда по одному файлику вылавливать? (там их десятка три, да еще и по разным директориям хитрО разложены)

[dimonomid]

А скачать-то ее откуда-нибудь можно? Или отсюда по одному файлику вылавливать? (там их десятка три, да еще и по разным директориям хитрО разложены)

Вот в том самом предложении, которое вы процитировали:

Представляю новое ядро реального времени: TNeo

Нажимаете на TNeo - попадаете на bitbucket. Можете или клонировать Mercurial-репозиторий, или зайти там в "Downloads" и просто скачать там последний собранный релиз.

[Xenia]

Вот в том самом предложении, которое вы процитировали:
Нажимаете на TNeo - попадаете на bitbucket. Можете или клонировать Mercurial-репозиторий, или зайти там в "Downloads" и просто скачать там последний собранный релиз.

Спасибо! Получилось.

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

1. Известно, что TNKernel поддерживает MSP430x (по крайней мере, такой проект у них был), тогда так TNeo его не поддерживает, хотя и позиционирует себя, как дальнейшее развитие TNKernel. Что стряслось? Возросли требования к архитектуре? Или возникло презрение к MSP430x, как к "вымирающему" виду?

2. Может ли TNKernel или TNeo быть портированы на ... AVR? Понятно, что не на Tiny или Mega, а хотя бы на Xmega? Если нет, то что этому мешает? Мало памяти, гарвардская архитектура, недостаточно уровней вложения прерываний? Или что-то еще?

[dimonomid]

1. Известно, что TNKernel поддерживает MSP430x (по крайней мере, такой проект у них был), тогда так TNeo его не поддерживает, хотя и позиционирует себя, как дальнейшее развитие TNKernel. Что стряслось? Возросли требования к архитектуре? Или возникло презрение к MSP430x, как к "вымирающему" виду?

Если TNeo и позиционирует себя как развитие TNKernel, то безотносительно конкретных поддерживаемых архитектур. Так что ничего особо не стряслось: ни требования не возросли, ни презрения не появилось.

Когда я только начинал работать над TNeo, я честно говоря и не думал что получится так глобально. Просто запилил себе порт под PIC32, потому что существующие порты меня категорически не устраивали тем, как там организован стек для прерываний. По ходу перепиливания ядра, это ядро нравилось мне все меньше и меньше, и я решил "сделать хорошо". Чтобы ничего не сломать, сначала написал подробные юнит-тесты. Пока писал тесты, нашел ошибки в оригинальном ядре. Потом пошло-поехало: давно хотел таймеры, давно хотел то да сё.

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

В итоге понравилось как оно получилось, решил перенести существующие проекты на PIC24 на него. Запилил порт под это дело.

Потом на семинаре Microchip рассказал про свое ядро, некоторые товарищи заинтересовались и сделали мне деловое предложение запилить порт под линейку Cortex-M и еще несколько плюшек. Я отказываться не стал.

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

2. Может ли TNKernel или TNeo быть портированы на ... AVR . Понятно, что не на Tiny или Mega, а хотя бы на Xmega? Если нет, то что этому мешает? Мало памяти, гарвардская архитектура, недостаточно уровней вложения прерываний? Или что-то еще?

Я никогда не работал с AVR и не могу точно сказать, но почти уверен, что технически ничего не мешает. Так что тут та же ситуация что и с MSP430x: если мне кто-то сделает интересное предложение запилить порт под AVR, я вряд ли откажусь.