STM32СubeMX и подобные Опции

[-AZ-]

Хотел собрать мнения специалистов, на примере STM32CubeMX.
Все-таки стоит ли применять подобные вещи или это для домохозяек?
При написании больших проектов на чистых С, С++ падает скорость разработки, но пока проверишь используемые ветки HAL, получается тоже не быстро.
Есть ли подводные камни и сложности "ручной" сборки например RTOS, в Cube довольно быстро, но качество неизвестно.
Может применение библиотек производителей, пусть не совсем хороших, не так уж плохо?
Очень интересно мнение тех, кто имеет практический опыт по этой теме.

[Professor Chaos]

По поводу быстродействия кода, написанного с помощью CubeMX, HAL, SPL, а также применения ОС в микроконтроллерах - хороший пример - управление электродвигателями. Вот интересная статья про это. Вот вторая - про отечественный микроконтроллер К1921ВК01Т от НИИЭТ и про решение задачи управления двигателем на нём.
Если коротко, то

В-четвертых, никаких операционных систем! Можно предвидеть, как у некоторых в голове крутится мысль «ну раз у вас такая сложная задача, поставьте нормальный микроконтроллер с Linux и пишите под него обычные приложения, обновляя ПО с флешки». Системы управления силовым оборудованием – системы очень жесткого реального времени. Не то что Linux, даже не все специализированные ОС реального времени подходят для таких задач. Например, прерывание АЦП по считыванию и усреднению аналоговых данных может вызываться с частотой до 100кГц. При этом оно будет содержать всего десяток-другой строк кода – сбор данных аналоговых каналов, пара проверок быстродействующих защит и выход – всё, больше ничего не успеть. Если поручить такое прерывание какому-нибудь планировщику задач ОС, то просто его собственное выполнение будет занимать больше ресурсов. Не говоря уже о том, что, в частности, для Linux вместо одной микросхемы МК на плату надо поставить еще две – внешнюю оперативную и флеш-память, отведя на них кучу драгоценных ножек кристалла, использовать шестислойную плату для правильной разводки, получить огромное время загрузки МК (иногда при сбое питания или срабатывании сторожевого таймера надо начать работу раньше, чем двигатель успел остановиться!), иметь проблемы с целостностью файловой системы и прочее.

Также есть ряд продуктов, позволяющих «рисовать» программы непосредственно для микроконтроллеров. В том числе тот же Matlab умеет генерировать Си-код для МК именитых брендов на основе модели в Simulink. Якобы можно нарисовать и отладить нарисованную структуру системы управления на компьютере в модели, а потом загрузить в МК – и готово, поехали! И даже такие среды позволяют отлаживать нарисованные структуры управления прямо внутри МК, смотреть переменные и т.п., а на сайтах таких продуктов есть куча демо-проектов для самых сложных систем, «запрограммированных» таким образом. Но так как все реальные проекты до сих пор почему-то программируют «руками», то можно догадаться, что с «рисованием» что-то не так. Но тут даже сложно описать, что именно, когда не так – всё. Главный аргумент против – это отсутствие полного контроля над происходящим внутри МК. Вы нажимаете кнопку в такой среде «сделать хорошо» и надеетесь, что генератор кода сделает за вас всё остальное. Для каких-то простых систем, где производительности МК «за глаза», сроки разработки очень поджимают, а программировать на фирме, которая взялась за проект, никто не умеет… то да, наверное, можно попробовать «нарисовать» программу. Но если она не заработает как надо, или будет иметь какой-то очень специфический глюк, то отладить её уже не будет никакой возможности. А для сложной задачи, где даже при программировании руками с производительностью МК всегда проблемы, рисование не подходит просто по причине нехватки ресурсов – любой язык программирования, чем он более высокоуровневый (куда уж выше рисования), генерирует менее оптимальный машинный код. А низкоуровневые оптимизации, которые сделал бы программист на Си, такая система сделать не сможет (расчет блоков одной структуры с разным тактированием, использование закешированных значений синуса и косинуса, замена функций деления на умножение на заранее подготовленную величину, или совсем уж хитрые вещи типа таких и т.п.).
...
Таким образом, приходится писать свой софт, и писать на Си. И отлаживать свой софт так или иначе надо, и надо на объекте. Наверное, к этому месту статьи все уже поняли, что отладить структуру управления можно только просмотром осциллограмм внутренних переменных, т.е. просмотром графиков во времени, как меняется та или иная переменная на Си – скажем, «выход вот того блока, пятого слева, одновременно с входами третьего справа».
...
И сделать это можно только средствами самого микроконтроллера. Нельзя просто взять и поставить внешний быстрый интерфейс связи и посылать «наверх» значение какой-то переменной, так быстро, как только можно, а уже в системе верхнего уровня строить график. Потому что ни один интерфейс связи МК не успеет сделать это с той частотой, с которой протекают регулируемые переходные процессы. А если успеет, то все ресурсы МК уйдут на обслуживание этого интерфейса связи. Поэтому делают так – записывают осциллограмму в оперативную память МК, просто в массив.

Понятно, что не всегда и не везде так жёстко со временем, но, просто, как один из реальных примеров. Причём не из области военной техники, управления оружием, типа маневрирующей гиперзвуковой боеголовки Ю-71 ракетного комплекса "Сармат" в атмосфере на скоростях 5-7 км/с, или случаев, подлежащих обязательной сертификации. Это обычная промышленная задача, решаемая для управления лифтом, троллейбусом, трамваем, электровозом, карьерным самосвалом или тепловозом с электрической передачей.