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

Под IAR c Cortex не планируется?

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

Не могли бы вы показать примеры ваших разработок с использованием 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 мютексов, если что. Вообще, рассуждать на эти темы нет особого желания. Если человек утверждает, что мютексы-де не нужны, то обычно получается просто религиозный спор. Как я уже сказал, да, можно все написать и без мютексов, и без РТОС, и т.д.

Планируете переносить TN NET на своё ядро? И есть ли вообще планы по реализации интерфейсов?

Пока нет таких планов. Честно говоря я TN NET и не использовал, не было необходимости, так что я его пока в глаза не видел и не могу сказать, насколько это сложная работа. Но все свои поддерживаемые проекты уже, конечно, перенес с TNKernel на TNeo, даже один чужой кортексовый проект перенес, особых проблем не было. API не 100% совместим, но если включить режим совместимости с TNKernel (TN_OLD_TNKERNEL_NAMES, TN_OLD_EVENT_API) , то изменения API тривиальные, логику работы приложения продумывать заново не нужно.

Ссылку на отличия API уже приводил в первом посте.

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

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

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

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

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

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

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

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

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

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

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

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



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

Понятно. Я примерно так и предполагала: вы один, а контроллеров много - на все вас просто не хватило.


А как бы вы прокомментировали шансы "АНТИпредложения", когда какой-то человек (или человечка ) хотел бы запилить вашу TNeo на Xmega сам? Т.е. мой вопрос сводится к следующему - какой из двух путей портирования этой RTOS вы оценили бы, как более сложный?
1. Когда вы сами портируете TNeo (все нюансы которой вы знаете) на совершенно неизвестный вам контроллер.
или
2. Когда этим занимается человек, в совершенстве тот контроллер знающий, но почти ничего не знающий про TNeo?

Т.е. для успешного выполнения такой работы, в какой области требуется иметь больше знаний/опыта: по части данной RTOS или по части железа МК?

Субъективно кажется что вариант 2 проще, конечно. Ничего там в TNeo сложного нет, вот документация почти всего architecture-dependent интерфейса: http://dfrank.bitbucket.org/tneokernel_api...n__arch_8h.html , все банально. "Почти" - потому что есть еще несколько макросов, не включенных в этот файл, но там так вообще ерунда. По аналогии с другими архитектурами делается элементарно.

Ну и если человек, кроме Xmega, хотя бы примерно знает любую из уже поддерживаемых архитектур (т.е. PIC24 / PIC32 / Cortex-M), то все еще проще: всегда можно посмотреть, как то или иное сделано в других архитектурах, и сделать аналогично.

И если всерьез кто-то этим займется - подсказать что-то по TNeo я всегда рад. Для облегчения совместной работы еще очень желательно чтобы коллега пользовался Mercurial - потом на bitbucket просто с помощью pull-request все сольем без гемора.

Так что ничего особо сложного, если есть желание - главное начать!

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

Но, конечно, все решаемо.

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

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

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

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

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

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

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

Так вот я вижу в том списке среди многих прочих типов интересующие меня архитектуры МК (AVR и Cortex-R4F), которые в настоящий момент не поддерживает ни TNKernel, ни TNeo. А психика любого человека, как и психика разработчика, такова, что когда есть что-то готовое, и к тому же бесплатное, то очень трудно решиться на самостоятельные проекты, достигающие той же цели, но только другим путем. Опять же колеблешься, опасаясь возможных трудностей или возникающих проблем в процессе самостоятельного творчества, тогда как перед тобой уже находится готовый халявный вариант, который нахваливает целая толпа народа.

В этой связи у меня к вам просьба похаять FreeRTOS, указав на присущие ей недостатки, но которые отсутствуют у TNKernel/TNeo. Т.е. что в принципе можно выиграть, если использовать TNeo вместо FreeRTOS? Полагаю, что даже в том случае, если бы я не задала вам этот вопрос, то его обязательно задал бы кто-то другой, т.к. конкуренция между различными RTOS/OS - типичное дело. Да и вы сами, надо полагать, имели в голове какие-то свои соображения, если в самом начале сделали ставку на TNKernel, даже в ее недоработанном виде. Тем более что здесь и без FreeRTOS других конкурентов полно, и всяк себя в захлеб хвалит.

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

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

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


Нет.



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

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

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

Так это запросто, если вы знаете FreeRTOS то должны знать, что то там нет такой фичи как Event group connection

А это реально очень полезная фича.
В задачу действительно могут посылаться и события и майлбоксы и потоки и на все надо реагировать сразу без последовательного полинга всех объектов синхронизации от которых ожидается изменение состояния.
Во FreeRTOS такого простого механизма реагировать на все сразу в одном вызове сервиса RTOS нет.

Правда в TNeo это реализовано несколько прямолинейно и не гибко.

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



Это понятно, но приоритет тогда зачем поднимать. Тогда семафора достаточно.

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

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


Хм, вообще коллбэк - хорошая идея, надо подумать. Гибкость, действительно, на высоте: в коллбэк-функции можно делать что хочешь, если надо.

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

Может, у вас есть какие-то примеры, что еще может быть реально полезно сделать в этом коллбэке?

Ну и если нужно только установить флаг, то в случае с коллбэком нужно будет сделать для этого больше телодвижений, чем сейчас: нужно будет написать специальную функцию, в ней вручную ставить/снимать флаг, и зарегистрировать коллбэк в TN_DQueue. А сейчас нужно просто вызвать tn_queue_eventgrp_connect() и передать туда указатель на группу флагов и маску.

Подумаю, спасибо.



Мютексы и семафоры созданы для совершенно разных задач, и некоторая схожесть их API порождает огромное количество путаницы в головах. Семафор - механизм сигнализирования, мютекс - механизм блокировки ресурсов. Статья Michal Barr была именно об этом, вот еще до кучи вопрос-ответ на stackoverflow: http://stackoverflow.com/questions/62814/d...phore-and-mutex

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


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

рассмотрите возможность 11. не плохо бы разместить поля id_task, id_mutex и прочие в режиме TN_CHECK_PARAM разместить в начале структур, чтобы проще выявлять виновников портящих память

Спасибо что напомнили, готово в BETA: https://bitbucket.org/dfrank/tneokernel/com...591035f9feac374

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

http://www.freertos.org/FreeRTOS-Event-Groups.html ?

event group-то есть, а event group connection нет.

Этот connection нужен для того, чтобы, например, ждать сообщения сразу из нескольких очередей. http://dfrank.bitbucket.org/tneokernel_api...ventgrp_connect

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




Все эти рассуждения в принципе наверно правильны если мы говорим об OS типа Windows.

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

К сведению в RTOS Nucleus Plus вообще нет мьютексов, там их роль блокировки к разделяемым ресурсам выполняют семафоры.
Приоритеты задач в Nucleus не поднимаются семафорами автоматически, для этого есть явные функции управления приоритетами. И это более близко по духу к realtime.
А есть еще такие понятия как Lightweight Semaphores, угадайте чем они отличаются от обычных семафоров.
А например в MQX подъем приоритета семафоры делают также как и мьютексы.

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

Т.е. не советую как аргумент ссылаться на stackoverflow.com где большинство в глаза видели один лишь PC.

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

"Семафор", как следует из названия, нужен для сигнализирования, а "мютекс", как опять же следует из названия (mutual exclusion - взаимное исключение), нужен для блокировки ресурсов между конкурирующими потоками.

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

В TNeo роль этих объектов предельно близка к парадигме. Мютекс мы можем заблокировать (tn_mutex_lock) и разблокировать (tn_mutex_unlock); семафор мы можем ждать (tn_sem_wait) и сигналить (tn_sem_signal).

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

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

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

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

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

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


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

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

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

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

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


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

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


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

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



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

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

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



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




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

Aner, фриртос действительно тормознее других переключалок. в некоторых моментах - существенно. после одного из таких сравнений задали вопрос автору. в итоге в лицензии фриртос появился пункт запрещающий её сравнивать с другими )))

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



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

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




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

Спасибо! Будем смотреть.
А тесты в открытом доступе имеются?

Добавлено: Нашел в документации, отдельный репозиторий (:

В доке на странице "Unit tests" в конце указано, где взять тесты: http://dfrank.bitbucket.org/tneokernel_api...unit_tests.html

кроме bla-bla-bla пример тормознутости в студию!

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

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

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

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



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





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

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

померло за давностью лет. нашлась только ссылка на обсуждение http://www.microchip.com/forums/m279201.aspx
там есть а пара картинок, где виден слив, и приходит сам автор фриртоса, который заявил что вы неправильно тестите, но "правильных" результатов так и не показал.

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

а потолок "развитости" есть? и потребляемых вместе с этой развитостью ресурсов

Да блин 2007 год, крутое обсуждения незнамо чего. И по вашему с той поры Free RTOS просто замёрз и не разу не менялся и новых версий никто не видел. Так шта все это бла-бла-бла.

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


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

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


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

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

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

Шизу про догнал развивать не стоит. Я о тормозах и сравнении то о чем писали. Ссылка ни как не убедила. Возможно это еще и от арх проца зависит. Я от Микрочипа отошел давно в сторону Кортексов. Быстрее писать, отлаживать, дешевле стоит, меньше затрат, удобнее. Хотя кто как привык. TNeo возможно востребованее будет на пиках, и арх проца не последнне дело в этой оси.

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

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

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

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

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


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

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

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

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

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

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




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

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


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

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

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