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]

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

[dimonomid]

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

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

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

[nill]

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

[dimonomid]

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

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

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

[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, я вряд ли откажусь.

[Xenia]

Просто запилил себе порт под PIC32,... В итоге понравилось как оно получилось, решил перенести существующие проекты на PIC24 на него. Запилил порт под это дело. ... Потом ...сделали мне деловое предложение запилить порт под линейку Cortex-M и еще несколько плюшек.

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

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

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

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

[dimonomid]

А как бы вы прокомментировали шансы "АНТИпредложения", когда какой-то человек (или человечка ) хотел бы запилить вашу 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 не документирован, нужно по аналогии с другими архитектурами смотреть. Вылизывать проект юнит-тестов времени уже не хватило; задачу свою выполняют - и хорошо.

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

[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 на практике? Оцениваете точно длительности выполнения всех задач? У вас все задачи всегда выполняются в строго отведенное известное время?

[Xenia]

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

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

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

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

[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 сегодня поддерживается, а завтра - неизвестно.

[AlexandrY]

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

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

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

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

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

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

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

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

[dimonomid]

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

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

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

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

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

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

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

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

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

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

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

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

но приоритет тогда зачем поднимать.

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

[megajohn]

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

[dimonomid]

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

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

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

[den_po]

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

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

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

[dimonomid]

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

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

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

[AlexandrY]

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

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

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


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

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

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

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

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

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

[dimonomid]

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

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

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

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

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

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

[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 мьютекс не будет удален при удалении создавшей его задачи?
Логично ожидать его удаления, а значит мьютексы можно разблокировать и из других задач.
Т.е. принципиальная разница с семафором не такая уж и огромная.

[Aner]

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

[dimonomid]

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

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

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

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

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

Т.е. принципиальная разница с семафором не такая уж и огромная.

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

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

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

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

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

[AlexandrY]

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

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

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

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

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

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

[Mahagam]

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

[dimonomid]

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

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

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

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

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

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

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

[Valentine Logino...]

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

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

Сообщение отредактировал Valentine Loginov - Jan 20 2015, 08:09

[dimonomid]

А тесты в открытом доступе имеются?

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

[Aner]

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

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

[LightElf]

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

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

Сообщение отредактировал LightElf - Jan 20 2015, 09:49

[dimonomid]

Но кучи в системах высокой ответственности - однозначное зло.

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

[AlexandrY]

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

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

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

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

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

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

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

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

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

[Mahagam]

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

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

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

[den_po]

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

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

[Aner]

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

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

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

[dimonomid]

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

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

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

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

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

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

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

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

[Mahagam]

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

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

[Aner]

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

[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]

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

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

[AlexandrY]

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

"подходящие или не подходящие" - это, что, намек на существование объективности в этом вопросе?
Как по мне, то TNeo более похожа на неподходящие решение.

С удивлением только что узнал, что во FreeRTOS есть таки аналог Event group connection и это xQueueCreateSet

[dimonomid]

"подходящие или не подходящие" - это, что, намек на существование объективности в этом вопросе?

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

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

Как по мне, то TNeo более похожа на неподходящие решение.

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

[ViKo]

Здесь много разговора про мьютексы. В Keil CMSIS-RTOS RTX, например, есть и мьютексы, и семафоры, и события... Я использую мьютекс для ограничения доступа к образу изображения на ЖКИ, чтобы одна задача не стирала что-то, нарисованное другой. И у него нет владельца. Не вижу принципиальной разницы с семафором. Каждый автор сочиняет ОС, как хочет. Зачем же продвигать именно свою точку зрения, как истинно верную? Еще назывались "бинарные семафоры" - мьютексы, в отличие от "счетных семафоров". И т.д.

Эскизы прикрепленных изображений

 

[AlexandrY]

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

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

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

Давайте не передергивать.

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

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

[_Pasha]

Мне вообще даже эти все разговоры про ртосы не нравятся
очень много шума из ничего. Как и оверхеда и бессмысленных оберток.

[dimonomid]

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

На вскидку:

Отдельная задача - в контексте вытесняющей РТОС это означает, как минимум, выделение в RAM отдельного стека для нее, и двойное переключение контекста каждый раз, когда нам нужно выполнить какие-то действия (если вернуться к тому же примеру, то речь идет о действиях с SPI).

1) Задача требует значительно большего кол-ва RAM. Например, на MIPS минимально необходимый размер стека - 36 слов (144 байта), это если задача вообще ничего делать не будет, только крутиться в цикле. Соответственно, чтобы она делала что-то полезное, этот размер стека еще значительно увеличится, раза в два легко - т.е. около 300 байт если без жира. Плюс еще нужна память для структуры очереди сообщений, и буфер для этой очереди. Еще минимум 50 байт, это если буфер совсем маленький. Мютекс занимает в RAM 36 байт - грубо говоря, в 10 раз меньше. Если на каждый ресурс лепить отдельную задачу - RAM кончается слишком быстро. Если у вас полмегабайта RAM - ерунда конечно, но в моих embedded-проектах на камне никогда не было больше 32К RAM.

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

* отправляем сообщение из A в SPI,
* сохраняем контекст (32 слова для MIPS) в стек задачи А,
* восстанавливаем контекст задачи SPI,
* задача SPI принимает сообщение и делает свою работу,
* сохраняем весь контекст в стек задачи SPI,
* восстанавливаем контекст задачи А.

В случае с мютексом, действий нужно гораздо меньше:

* блокируем мютекс,
* модуль SPI делает свою работу,
* разблокируем мютекс.

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

Имел в виду, что TNeo слишком нефункциональна по сравнению с той же FreeRTOS.

А в чем именно заключается нефункциональность?

Мне вообще даже эти все разговоры про ртосы не нравятся
очень много шума из ничего. Как и оверхеда и бессмысленных оберток.

А, _Pasha, то есть вы никогда не используете РТОС, правильно? Класс, я ждал, пока кто-нибудь отпишется, спасибо.
Вот видите, AlexandrY, есть тут люди, которые пишут без РТОС!
Ждем человека, который пишет исключительно на асме.

[Alex B._]

dimonomid – можно рассмотреть кейс, когда на SPI висит не только «память», а, например, Flash, FRAM, RF-трансивер, акселерометр. И вся эта периферия имет разный приоритет (отправить пакет через RF важнее, чем сделать запись лога во Flash, потому что таймаут).
Одна задача, обслуживающая интерфейс через очередь – это хороший подход и он может быть действительно удобнее мютексов, если интефейс нужен только двум задачам с одинаковым приоритетом.

[dimonomid]

dimonomid – можно рассмотреть кейс, когда на SPI висит не только «память», а, например, Flash, FRAM, RF-трансивер, акселерометр. И вся эта периферия имет разный приоритет (отправить пакет через RF важнее, чем сделать запись лога во Flash, потому что таймаут).
Одна задача, обслуживающая интерфейс через очередь – это хороший подход и он может быть действительно удобнее мютексов, если интефейс нужен двум задачам с одинаковым приоритетом.

Согласен: иногда, действительно, задача удобнее мютексов. А иногда наоборот. Я где-то противоречил этому?

[Alex B._]

Я где-то противоречил этому?

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

[AHTOXA]

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

То есть, если одна задача захватит мьютекс при помощи wait(), то другая задача может его освободить, вызвав release()?

[ViKo]

То есть, если одна задача захватит мьютекс при помощи wait(), то другая задача может его освободить, вызвав release()?

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

[AHTOXA]

Нет. Мьютекс достается только одной задаче.

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

И у него нет владельца. Не вижу принципиальной разницы с семафором.

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

[ViKo]

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

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

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

[dimonomid]

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

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

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

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

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

[ViKo]

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

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

[Valentine Logino...]

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

[ViKo]

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

[LightElf]

Так что, разница есть. Но и говорить, что мьютекс - частный случай семафора - тоже верно.

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

[ViKo]

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

Точно.

[zaicev_ekb]

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

[dimonomid]

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

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

[dimonomid]

Насчет FreeRTOS:

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

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

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

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

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

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

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

TNeo:

Код

volatile int i;

/*
* Low-priority task (2). The lower value, the higher priority.
*/
void task_b_body(void *par)
{
   for(;;)
   {
      tn_task_sleep(10);
      i = 0;   //-- stopwatch start
      tn_sem_signal(&sem);
   }
}

/*
* High-priority task (1). The lower value, the higher priority.
*/
void task_a_body(void *par)
{
   for(;;)
   {
      tn_sem_wait(&sem, TN_WAIT_INFINITE);
      i = 1;   //-- stopwatch stop: 624 cycles (594 without stack overflow check)
   }
}

FreeRTOS:

Код

volatile int i;

/*
* Low-priority task (tskIDLE_PRIORITY + 1)
*/
void prvTaskB (void* pvParameters)
{
   for (;;) {
      vTaskDelay(10);
      i = 1;   //-- stopwatch start
      xSemaphoreGive( mySem );
   }
}

/*
* High-priority task (tskIDLE_PRIORITY + 2)
*/
void prvTaskA (void* pvParameters)
{        
   for (;;) {
      xSemaphoreTake( mySem, portMAX_DELAY );
      i = 0;   //-- stopwatch stop: 863 cycles (624 without stack overflow check)
   }
}

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

[dimonomid]

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

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

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

[LightElf]

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

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

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

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

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

[dimonomid]

Насколько я помню, автор FreeRTOS всегда упирал на большую предсказуемость. Т.е. две задачи - не показатель, а вот что будет с 20 задачами - вопрос интересный.

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

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

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

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

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

[LightElf]

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

Хм. И по спискам задач (семафоров, мутексов и т.д.) под запрещенными прерываниями не ходите?

[dimonomid]

Хм. И по спискам задач (семафоров, мутексов и т.д.) под запрещенными прерываниями не ходите?

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

Другое дело, что на некоторых платформах (пока только dsPIC/PIC24) есть возможность запрещать в критических секциях не все прерывания, а только определенный диапазон приоритетов прерываний. Но тогда из остальных прерываний нельзя вызывать сервисы ядра.

[LightElf]

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

Во! Значиццо есть куда стремиться. Поскольку мутексы (по логике вещей) не используются из прерываний, логично было бы обойтись без критических секций в данном случае.

Другое дело, что на некоторых платформах (пока только dsPIC/PIC24) есть возможность запрещать в критических секциях не все прерывания, а только определенный диапазон приоритетов прерываний. Но тогда из остальных прерываний нельзя вызывать сервисы ядра.

Эта фишка во FreeRTOS тоже искаропки идет, как минимум на ARM Cortex-M3 и Renesas RX. Но описанные минусы напрягают.

[dimonomid]

Во! Значиццо есть куда стремиться. Поскольку мутексы (по логике вещей) не используются из прерываний, логично было бы обойтись без критических секций в данном случае.

Вам нужен AVIX тогда. http://avix-rt.com/ Она никогда не запрещает прерывания, вообще. Но денег стоит.

[LightElf]

Вам нужен AVIX тогда. http://avix-rt.com/ Она никогда не запрещает прерывания, вообще. Но денег стоит.

Это наверно оверкилл, хотя давно у меня чешется что-нить подобное наваять (естественно на архитектурах, где такое вообще возможно). Но речь здесь о TNeo vs FreeRTOS. Так вот, FreeRTOS под запрещенными прерываниями списки не обходит. Отсюда и "большие задержки".

[dimonomid]

Так вот, FreeRTOS под запрещенными прерываниями списки не обходит. Отсюда и "большие задержки".

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

Ладно, спасибо за инфу, когда будет время, попробую разобраться.

[LightElf]

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

Это один из вариантов. Можно еще:
1) хранить список ожидающих задач в отсортированном виде.
2) запрещать прерывания только на время работы с конкретным элементом

Ок, но как, например, с таймерами? Если запущено много таймеров, то эту очередь надо как-то обслуживать, и чем больше таймеров в очереди, тем больше времени это занимает.

Логично. Поэтому таймеры в виде коллбэков из прерывания - зло.