[dimonomid 0]

Ваш пример с SPI тоже не отличается прямизной. Для таких дел специально созданы сервисы очередей.

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

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

 

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

 

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

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

 

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

 

[AlexandrY 3]

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

 

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

 

Таким подходом опять нарушается принцип реального времени.

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

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

 

А надо было бы организовать во-первых задачу менеджера SPI шины.

Во-вторых остальные задачи менеджеру шлют свои командные структуры через сервис очередей.

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

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

 

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

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

 

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

 

 

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

 

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

Следовательно и маркетинговый эффект от их реализации сомнительный.

[dimonomid 0]

А надо было бы организовать во-первых задачу менеджера SPI шины.

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

 

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

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

[AlexandrY 3]

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

 

 

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

 

 

Панацеи нет, но есть плохие и хорошие лекарства. И это стоит обсуждать.

Что можно без RTOS, а что нельзя, кстати, тоже интересная тема.

Но нет так нет.

Значит ваша ось все таки ради искусства. ;)

[dimonomid 0]

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

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

[AlexandrY 3]

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

 

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

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

 

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

[dimonomid 0]

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

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

 

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

 

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

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

 

[ViKo 1]

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

[AlexandrY 3]

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

 

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

 

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

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

 

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

 

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

Тогда хотя бы обосновать такой минимализм.

[_Pasha 0]

Мне вообще даже эти все разговоры про ртосы не нравятся :rolleyes:

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

[dimonomid 0]

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

На вскидку:

 

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

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

 

Мне вообще даже эти все разговоры про ртосы не нравятся :rolleyes:

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

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

Вот видите, AlexandrY, есть тут люди, которые пишут без РТОС! :)

Ждем человека, который пишет исключительно на асме.

[Alex B._ 0]

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

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

[dimonomid 0]

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

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

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

 

[Alex B._ 0]

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

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

[AHTOXA 14]

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

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