Представляю новое ядро реального времени: 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.

Нет. Мьютекс достается только одной задаче. Если одна задача получила мьютекс, то, значит, у другой его не было. То есть, и отдавать другой задаче нечего.
Я не пробовал выполнять osMutexRelease до его получения. Но, думаю, просто ничего не произойдет.

Вот это и называется - задача владеет мьютексом. Захватила, и владеет единолично, пока не отдаст. Это я к вашей фразе

Теперь видите разницу?

Почитайте выше, что пишет топикстартер, У него мьютекс всегда принадлежит одной и той же задаче. Вот ему я и пишу, что у Кейла - не так. Мьютекс создает ОС, задачи им пользуются.

Перечитал сообщение 26. В начале говорится о заблокированном мьютексе, а потом уже просто о владельце. Я неправильно понял.

Вы меня совершенно неправильно поняли. Где именно я так неясно выразился?

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

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

Не знаю как у Кейла, может, и не так. Это не новость, что эти термины постоянно путаются, к сожалению. Ну еще раз дам ссылку на статью: Mutexes and Semaphores Demystified, почитайте там хотя бы The Myth: Mutexes and semaphores are similar or even interchangeable, а также The History of Semaphores and Mutexes.

Хотите семафоров? - их есть у Кейла. Как говорится, найдите отличие от мьютекса.
То же, что в статье и dimonomid называют семафором, у Кейла выполняют "сигналы" (osSignalSet, osSignalClear, osSignalWait), они же в девичестве "события" (Event), они же "флаги". Они принадлежат задаче (по умолчанию у каждой задачи их 16 штук), и могут обрабатываться поодиночке или группой.

Еще предлагаю посмотреть документ от Кейла:
http://www.keil.com/product/brochures/rl-arm_gs.pdf
Синтаксис устарел, но принципы остались теми же. В-частности, там показано, как используются семафоры: Сигнализация, Мультиплекс, Рандеву, Турникет.

Ай пошли войны. Создали бы тему или блог какой и обсуждали бы краеугольные камни архитектуры ПО.
Мне бы больше хотелось увидеть сравнение времени переключения контекста от количества задач между TNeo и той же FreeRTOS (порт для pic32 ) . Да и по памяти выделяемой на те же объекты синхронизации.
У меня пока что руки дошли запустить-помигать. Исходный код у проекта выглядит очень приятно. Попробую прикрутить гармониевский стек, заодно буду смотреть что у TNeo с менеджером динамической памяти.

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

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

Точно.

Прошу прошения.
А почему такой древний компилятор XC32 v1.21?

Нет особых причин, соберите новым компилятором, проблем быть не должно.

Насчет FreeRTOS:




Ради интереса, таки провел сравнение, вопреки лицензии FreeRTOS. Пример простейший: две задачи: А (высокоприоритетная) и B (низкоприоритетная). А ждет семафора, B через определенный интервал сигналит семафором. Т.к. А высокоприоритетная, то как только B сигналит семафором, управление передается задаче А.

Измерял время от момента вызова сервиса сигнализирования из задачи B до получения управления задачей А.

В TNeo: 624 тиков (594 с отключенной проверкой переполнения стека),
в FreeRTOS: 1215 тиков (1075 с отключенной проверкой переполнения стека).
UPD: в FreeRTOS: 863 тиков (699 с отключенной проверкой переполнения стека). Я по запаре накосячил с измерениями первый раз, см. след. сообщение.

Измерения производились на PIC32MX с помощью stopwatch в MPLABX.

TNeo:


FreeRTOS:


Сообщение отредактировал dimonomid - Apr 8 2015, 09:59

Так, отставить, я ерунду написал в прошлом сообщении: для TNeo-то я взял существующий настроенный проект, а для FreeRTOS создал новый, и забыл в нем оптимизацию включить. Пардон.

Так что отличия поскромнее:

В TNeo: 624 тиков (594 с отключенной проверкой переполнения стека),
в FreeRTOS: 863 тиков (699 с отключенной проверкой переполнения стека).

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

Сообщение отредактировал LightElf - Apr 8 2015, 14:20

Как в FreeRTOS - не знаю, а в TNeo, как и в TNKernel, количество задач не влияет на скорость переключения контекста: для каждого приоритета есть связанный список задач, готовых к запуску. И есть битовая маска, каждый бит которой отражает приоритет, в котором есть готовые к запуску задачи. Таким образом, когда ядро выясняет, какую задачу нужно запустить, оно делает следующее:

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


От количества задач эта задержка тоже не зависит.

Сообщение отредактировал dimonomid - Apr 8 2015, 14:16