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

[-AZ-]

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

[Professor Chaos]

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

[Quasar]

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

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

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

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

[juvf]

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

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

[AlexandrY]

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

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

[juvf]

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

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

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

Да, согласен, просто так ни кто этого делать не будет. Но если вы пишете ПО - вы обязаны это сделать. Для любого ПО. Эти тесты и испытания не такие уж и дорогостоящие. Если это зарядной устройство для аккумулятора - то какие там могут быть дорогие испытания? Если пойдет устройство в массы и софт начнет глючить - это гибель производителю. Если это система посадки - тут тесты не дороже... тут само устройство больше, соответственно и тестов больше, включая облёты. И ПО пишется, что для бытовухи, что для систем жизнеобеспечения одинакового, с применением одинаковых IDE, компиляторов, библиотек.... Если кто-то считает что иначе - я вас разочарую.

[AlexandrY]

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

И ПО пишется, что для бытовухи, что для систем жизнеобеспечения одинакового, с применением одинаковых IDE, компиляторов, библиотек.... Если кто-то считает что иначе - я вас разочарую.

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

А в космос могут запускать что угодно. Даже студенты из нашего универа свой спутник запустили сделанный из PI и ардуино, и может быть даже с системой торможения и посадки. Поскольку у них там лимит времени на орбите.
А американцы на МКС уже годами держат глючного робота.
Упоминание космоса - это нынче не о чем.

Поэтому там, где поставленной задачей заранее, никак не ограничивается использование HAL, SPL, Cube, Linux (сертификация, или ограничения по производительности/быстродействию, или потреблению) - их вполне можно использовать.

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

А насчет надежности и безглючности согласен.
Не стоит приписывать HAL-у какую-то особенную глючность. Его все-таки солидная толпа проверяет.
HAL просто неэффективен.

[Quasar]

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

А насчет надежности и безглючности согласен.
Не стоит приписывать HAL-у какую-то особенную глючность. Его все-таки солидная толпа проверяет.

HAL это вообще первое, что увидит начинающий в теме. Поэтому по нему и дофига вопросов на форумах, типа "НИ ЧЕГО НЕ РАБОТАЕТ ПАМАГИТЕ". У не окрепших умов создается впечатление, что это неработающее "Г...", вон же сколько тем по нему! Я сколько использую HAL, ни разу не сталкивался с чем-то, для чего нужна была бы помощь зала.

HAL просто неэффективен.

Linux тоже не эффективен, память жрет, мипсы тратит, четырехслойку с BGA требует, но его популярность на планете порой пугает.