+ за вопрос.

Тут оправданность выбора, изучения и перехода сильно зависит от задач.
Оправдано только при необходимости работы с большим потоком событий с гарантией реакции на каждое из них.
Иногда ситуация может быть разрешена распределением обработки на несколько устройств.
А так RTOS разного вида вполне себе живут вокруг нас.
Даже примитивные кнопки (iButton) на чипах от TI вполне себе с этой системой живут.
Конечно меняется подход к программированию, но сильно сложного там ничего нет.
При опыте работы с конечными автоматами все покажется очень похожим .

Пример проекта на RTOS. Сниффер SPI, бывает полезно знать что на самом деле передаётся на подчинённый чип. Блок SPI с высокой и неравномерной скоростью читает данные и передаёт на RS-232. Конечно через промежуточный буфер. Если делать на RTOS, проблема решается просто. Одна задача срабатывает от прерывания блока SPI и посылает даные на задачу отправляющую данные в RS-232. Эти две задачи взаимодействуют через очередь FIFO, в FreeRTOS есть такие объекты. У меня есть скелетные проекты по FreeRTOS http://stm32.aiq.ru/FREERTOS/FreeRTOS.html

После 3+ лет погружения в любительский эмбед [на изиэлектроникс] я всё больше склоняюсь к тому, что сразу после мигалки должна быть какая-то rtos [особенно для arm]

Тебе или эмбеду? )

Логически к "все" никак не относится... Ну вот тебе ртос чем помогла??? Да ни чем... И в ближайшем будущем 100%  охвата ртосом ждать не приходится...

Посматриваю и в сторону хала и куба, там же встроенна FreeRtos. Что мы экономим ? Память? Скорость ? В стм32 .
Да там в микрочипе 8 битники и скорость не ахти.

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

Деньги. Как во время разработки, так и во время поддержки устройства в его цикле жизни.
В плане ХалоКуба, если делать железки для медицины - использование халокуба влечет за собой кучу человеколет для его "понимания" и тестирования.
Основное требование в медицине (ну я про немецкую сейчас, чтоб получить сертификат == право на продажу железки), понимание как оно работает в плоть до последнего регистра в цепочке Аппликуха - девайс - драйвер - ХАЛ - регистр - железо. Понимание, и возможность доказать это понимание, если вдруг случится такая необходимость (уже случались, к сожалению, такие необходимости, но после всех проверок и наших доказательств выявили фактор кривых рук пользователей).
С Халокубом это сделать ооооочень сложно, с его кашей в дефайнах, как и в подходе к работе с железом. И тем более, что оно малость баговатое, что в этом всем приходится находить ошибки и править.

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

В принципе - та же канитель с и RTOS. Я немного покопался в недрах FreeRTOS, есть возможность сравнить с SeggerOS. Для медицины класса С берем Зеггеровскую, для класса B - FreeRTOS.
К вопросу - зачем она нужна....
Ну конечно можно систему GUI и на обычном большом цикле с простеньким шедулером написать, но с RTOS это немного быстрее получится

Отредактировано MasterAlexei (2018-11-24 15:03:35)

Кхе кхе я аж подавился тут печенькой

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

Халокуб удобен только в одном случае:
вы получили из производства плату и вам надо проверить, всё ли правильно запаянно. Для этого обычно пишутся быстрые тесты, которые там пару байт в УАРТ кидают, светиками моргают. И все.
Остальная работа уже будет идти на совершенно другом уровне.

Наша фирма OEM в области иземерния потоков жидкостей в трубах   Как силиконовых, так и венах человеческих.
em-tec.de
Параллелльно еще есть пара проектов, но про них пока не могу говорить. Скажу только, что если ЭТА железка вдруг встанет, то человек умирает в течение 7 секунд. Ну это так гласит теория. Я сам не знаю точно, сколько там времени остается.

Да.
https://www.segger.com/purchase/pricing/embos/

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

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

А что касается ST, то было бы неплохо от них еще и сниппеты для других линеек МК иметь, дабы самому их не писать. Т.к. сниппеты для F0 не всегда можно использовать на других сериях.
Все, больше ничего не надо от них: описания регистров уже есть, так что все хорошо. Что касается их стека USB, то наткнулся я раз на USB от них для STM32F0, очень даже неплохо написано (если выкинуть половину кода). Разве что в CDC они почему-то не используют EP1 (которая для прерываний). Вот USB "для всех линеек" — да, страшное.
Ну, мне, собственно, только CDC нужен. Я его сделал на основе HID отсюда, больше мне от USB ничего не нужно (еще на STM32F103 это портирую когда-нибудь, и все).

Попробуем присабачить к FreeRtos SystemView.

Я правильно понял что нужно заменить пару файлов в фреертос из патча segger, подключить в проект файлы systemview и вызвать в майн инициализацию systemview до запуска ртос самой ?

Интересно как пропатчить то,файл с расширением .path. Просто первый раз встречаюсь с таким. А как вы замерджил их ? просто не встречался с этим еще ))

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

Сравнение сделал,а как применить,пока не соображу в этой проге ))