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

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


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

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

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

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

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

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




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

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


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

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

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

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

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

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

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


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

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

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


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



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

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

На вскидку:

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



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


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

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

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

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

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