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

[-AZ-]

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

[Professor Chaos]

Как-то делал проект в фирме, занимающейся театральным оборудованием. Я там был в качестве схемотехника. Были ещё трое технарей - два конструктора и программист. Там решались задачи сценической механики - подъём сцены, её поворот, движение лебёдки, движение софитов и т.п. По разговорам с ними я понял, что никакой сертификации КД и ПО там нет и в помине. Более того, сертифицировать, по-сути там нечего. Т.к. на сертификацию направляется полный комплект КД, включая ЭД, ПД, если она есть. Ничего такого там просто нет. Нет учтённого комплекта КД. Требования ЕСКД и ЕСПД там игнорируются, нормоконтроль отсутствует. ГОСТы по разработке, регламентирующие этапы разработки, количество партий приборов и объёмы испытаний - нет, не слышали. Вернее слышали и знаем, но сознательно игнорируем - это слишком долго и дорого. Т.е. случись чего - концов не найдёшь. Ни программ, ни схем. Они где-то у кого-то на компьютерах и неизвестно насколько соответствуют реальному железу. А если увольняется ключевой разработчик - то и этого может не остаться.

[Quasar]

Как-то делал проект в фирме, занимающейся театральным оборудованием.

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

Я считаю полезным высказывать свое мнение.

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

[juvf]

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

Абсолютно одинакового. Что ПО для авиации (как для гражданской, так и для военной), что ПО для автоматической поливки комнатных цветов - пишется абсолютно одинакового. Или кто-то для военной авиации использует годный софт, а для гражданской глючный? Кто-то для кухонных весов использует заведомо глючный компилятор? Или в коде для гражданской авиации можно на ноль делить?

[makc]

Абсолютно одинакового. Что ПО для авиации (как для гражданской, так и для военной), что ПО для автоматической поливки комнатных цветов - пишется абсолютно одинакового. Или кто-то для военной авиации использует годный софт, а для гражданской глючный? Кто-то для кухонных весов использует заведомо глючный компилятор? Или в коде для гражданской авиации можно на ноль делить?

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