STDlib для STM32 более менее приемлемое решение и понятное, к тому же не глючное. У HAL хорошая задумка и архитектура - но использовать эту индусскую реализацию просто не советую. Всё позже накроется медным тазом и потеряете лицо. Два выхода: тщательное изучение периферии внутренних модулей или выдергивание волос из носа, когда начинаются проблемы.
Из опыта: у atmel и stm похоже одни и те же индусы на поддержке сидят. Самый простой внешний интерфейс как UART и с тем не умеют правильно работать (не могут сбрасывать флаги ошибок периферии, то есть не читают документацию). HAL от идус-STM это килобайты кода в контексте прерывания и понаставленные собственные грабли, с которыми сами авторы не могут разобраться. Разрешают срабатывания прерывания когда их об этом не просишь ну и т.д.
Подход к прерываниям обусловлен старой архитектурой, когда она проэктировалась еще для 7-9 армы. Вместо выгоды в применении нового NVIC контроллера, который встроен в систему в CORTEX ядрах - HALL делает доунгрейт этой системы до скоростей уровня 7DMPI ядра + немеряно ненужного кода и времени нахождения в прерывании.

С atmelом то же самое сейчас, непонятно кто пишет поддержку. Банальный uart, нет даже правильного чтения данных, который НАСТОЯТЕЛЬНО рекомендован производителями микросхем.

Подумал, посмотрел код. У меня создалось ощущение, что вы не стесняетесь писать сразу в регистры периферии.

Все хорошо, кроме двух грубых ошибок: 1) комментарии на русском языке, 2) использование "магических чисел" вместо макросов или перечислений.

Это шо шутка какая-то ? Собственное неглючное написание процедур кхала (со всеми реализациями прототипов) займёт куда меньше времени чем время и аккуратность выкорчёвывания килобайтов ненужного и глючного кода в КОНТЕКСТЕ ПРЕРЫВАНИЙ еще и завязанного с ихними статусными состояниями ?! Или вы не знаете что там по UART, I2C всё написано ногами. Ничего себе "немного кода". Следующую версию кхалла когда они выпустят, снова будете искать что ненужно и выкорчёвывать ? Детский сад.

Однозначно стоит!

+1, ППКС.

Я не заметил особой разницы в нагромождениях HAL, SPL, LL. Документация от ST по мне, так достаточно понятная. Вожусь с TI-RTOS, CCS, cortex m3 от TI - вот это жуть!!! Вот это сплошное нагромождение и глюк на глюке. На фоне продуктов TI, продукты ST - это свет во тьме. Не сочтите за рекламу.

И что в этом плохого?



На счет затрат по времени - согласен, а вот на счет остального - не факт. Как-то делал пробный проект на MQX и их демо, взятых за основу. Так вот, все вроде работало, я обрадовался, пока не решил "поиграться" с усб-флешкой, воткнул ее, вытащил, и так раза 3, почему 3? Потому что на 4й все зависло намертво... Вот и решил потом все писать сам.

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

// а отписывающиеся тут в пользу [censored], похоже, кроме мигания светодиодов и "примеров от ST" ничего не делали, иначе поняли бы, что быстрей написать "на голом CMSIS", чем ковыряться в кривом коде кала...

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

ЗЫ. Для иностранцев проги не писал

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

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

Например, у меня есть ряд проектов, в которых на STM32F4 крутится DMR стек (стек цифровой радиосвязи) с вокодером, TCP/IP стек и USB в режиме виртуального COM порта. Все это крутится на одной из популярных легковесных ОС. DMR стек реализовывал я, совместно с еще одним разработчиком - специалистом по ЦОС и помехоустойчивому кодированию. От процессора необходима реализация базовых функция, типа принять поток по SPI/I2S/I2C, встроенный EMAC, таймеры, USB phy. СТшный HAL с вышеописанными функциями вполне справляется. Основная сложность таких проектов - в прикладной логике (стеки протоколов, обработка сигналов и т.п.), и деньги платятся за это. Если не стоит задачи жесткой оптимизации (на диком масс-продашене такое вполне возможно), колупаться с изучением конкретного камня не имеет никакого смысла, ну будет софтовый оверхед, ну выберете камень посильнее и все. Словить какие-то тяжелые баги, например в HAL'овском драйвере SPI или I2C достаточно тяжело, оно либо работает, либо нет. Намного важнее, сосредоточиться на тех задачах, которые собственно и требуют решения в ходе разработки. А судя по тому, как все тут переживают за код в HAL'е, который, как и любой другой код, естественно имеет ряд недостатков, создается впечатление, что люди дальше дерганья GPIO и работе с SPI не уходят в своих трудах.

От HAL очевидно придется уйти только тем, у кого:
1) Дикая серия и камень взят впритык, ибо на больших сериях каждый доллар на счету;
2) Если у вас жесткие требования по потреблению.

3) если есть совесть.

GitHub по сути - это история ошибок.
Отсутствие возможности сразу создавать проекты на национальных языках не моя ошибка, а ошибка GitHub-а.
Думаю они скоро ее исправят.

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

Хех, я частенько открываю свои старые или чужие проекты в Keil, и если там русский текст, то начинается перебор кодировок - ANSI? UTF? Win1251? А на английском никаких проблем.
Есть и обратная сторона - с английского не все могут правильно перевести.

Иногда, комментарии на русском языке могут быть обязательным требованием заказчика/работодателя.



Поэтому я всегда стараюсь писать комменты на инглише. Эта путаница с кодировками сильно утомляет. Особенно когда одни и те же исходники редактируются в разных операционках (Win <-> macOS/Linux).

[off]


Вы уж как-нибудь определитесь, люди используют в работе HAL потому что у них совести нет, или потому что "ничего сложнее примеров от ST не делали". А то выглядит это все как какой-то подростковый максимализм. Вы наверное еще винду не любите, потому чтА "маздай"?
[/off]

Мой рунглиш и китайцы, и англикосы нормально прочитают. А что они с вашим рашкинским будут делать?

А еще тогда, когда надо чтобы работало всегда, например, safety critical. Так, к слову, некоторые очень любят исполхзовать Linux, чтобы, например, лампочкой поморгать... Выбор инструментария и ответственность эа результаты его применение целиком лежит на разработчике. Нельзя запретить желающим писать с кубическим акцентом...

Вот щас всё брошу и начну думать как же китайцы будут мои программы читать?
Если оно им действительно надо пусть приходят с мешком юаней и вежливо спрашивают - "Что уважаемый лаовай хотел сказать своим комментарием в строке 1234?".
Ну, или пусть гуглом переводят.

Взглянул я на ваш github.
У вас там просто нечего читать. У вас фактически нет коментов. То ли вы их не научились еще писать, то ли тяжко писать их на неродном языке.
С такими текстами вы не заинтересуете ни англоговорящих, ни русскоговорящих.

Я не комментирую то, что не нуждается в комментариях.
Если функция со свистом влезает на одну страницу кода, а аргументов у нее один-два, комментарии можно и не писать. Как и вещам вроде "два+два=четыре".
Остальное комментирую вполне достаточно.
P.S. И не надо на мой быдлокод смотреть! Я не программист.

На самом деле, именно для процессоров ST, HAL просто совершенно необходима, особенно начинающим.

Это связано с тем, что их периферия сделана совершенно безобразно и, практически, не описана (I2C, RTC - это просто кошмар какой-то, DMA тоже хороший подарок и т.д.). Как она на самом деле работает, и как преодолеть ее ошибки можно понять только одновременно глядя в исходники HAL, RefMan и DS.

Можно, конечно использовать уже адаптированные RTOS, но на не слишком сложных задачах как-то не хочется.

Видал еще и индивидуумов, которые осилили только буквы и пишут на ужасном транслите

А лампочкой поморгать это safety critical? Как вообще лампочка связана с safety critical? Вообще удивительно какой бардак у многих в голове.

Ok, зайдем с другой стороны, как вы подтверждаете safety critical? Ваш софт проходит сертификацию на DO-178B, например, или вы просто по "пацанский зуб даете"?

Какой-нибудь управляемый L2 коммутатор D-link или soho роутер от них же, ни разу не лампочкой поморгать, но в нем скорее всего обычный линукс. И там это решение вполне оправдано, так как там не стоит задачи в спец. сертификации. А вот на бортовом вычислителе боинга 737 вы линукс не встретите, и не потому, что он сильно сложнее, а потому, что сделав вычислитель на линукс вы упашетесь его сертифицировать и доказывать что оно надежно. Потому что в настоящем safety critical надо доказывать, а не просто трындеть.

Если проект подразумевает safety critical с соответствующей сертификацией, то он подразумевает и соответствующее количество трудочасов и денег на него. В рамках этого проекта, естественно, разумно выделить группу для написания надежной замены ST'шному HAL'у. С которой потом, можно будет пройти все сертификации. А когда у вас задача спроектировать железку без доп. требований по надежности, а вы все равно тратите время на перепись HAL'а, полагая (почему-то?), что ваш быдло код лучше "индусского", вы просто разбазариваете время и деньги, отвлекаясь от основной задачи.

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

DRM довольно примитивный протокол. Гораздо проще того же Bluetooth или ZigBee. Работали небось по UART-у с чипом реализующем два первых уровня или вообще весь стек.
TCP стек и USB теперь есть в любой демке любого производителя микроконтроллеров.
Я даже не глядя скажу что это у вас был lwIP.
У вас и задач наверно было две три.

Вам на самом деле почти не нужна периферия. Поэтому извините, но мне кажется вы недостаточно в теме.

Иногда лучше жевать, а не раздавать советы по проектированию...

Во-первых, речь шла о DMR, а не о DRM;
Во-вторых, если вам человек пишет о том, что на процессоре "крутится DMR стек", это значит, что он там крутится (на процессоре), а не на каком-то специализированном ASIC'е, общающемся по UART'у c хостом. Реализованы там уровни начиная от phy. В сам процессор вводятся либо квадратуры с бэйсбенда, либо сигнал после ЧМ (зависит от версии железки);
В-третьих, по поводу стеков USB и lwIP, да, они есть в любой демке, но это не означает, что их нельзя использовать в проектах (стек USB и стек lwIP). Я работал когда-то в одной конторе, в которой зачем-то писали свой стек. Устройства, которые выпускала контора были мягко говоря так себе, потому что все были заняты изучением RFC и бдениями за Wireshark'ом, отлаживая стек, а об оконечном функционале (за который клиенты и платили деньги) вспоминали редко.



Проекты бывают разные, со своими тонкостями, но почему-то многие здесь, наплевав на тонкости, раздают идиотские советы типа "Cube и HAL" это для мигания лампочкой. Это просто признак низкого профессионализма, я так считаю.

Да ладно то к мелочам придираться, я ж искал по "DMR stack" . Примитивная 4-FSK модуляция. Там демодулятор не больше сотни строк.
lwIP конечно можно использовать, но достался он вам в виде рабочей демки. Сомнительная заслуга что он у вас работает на STM32.
Где собственно приложение плотно работающее с периферией?

Какие у вас прекрасные познания. Да, весь протокол это примитивная 4FSK... Пять минут в гугле и все готово.



Заслугами дети в ясельках меряются. А именно в этом треде, взрослые (как я полагаю) люди, обсуждают оптимальные пути решения технических задач. По поводу плотности использования периферии, я выше написал. Учить вас читать я не собираюсь.

Упомянутому мною выше D-Link'у все коммутаторы и роутеры, видимо, достаются в виде работающей демки linux'а.

Следую мудрым советам:
“Never argue with an idiot. They will drag you down to their level and beat you with experience.”
― Mark Twain

Да-да. При этом, судя по вашим последним сообщениям на форуме, вы считаете нужным влезать в обсуждения с одним единственным советом "не использовать Cube, HAL, SPL". Какие еще цитаты приведете по этому поводу?

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


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

У меня приличных слов нет про эту статью..
Сплошное нагромождение мифов.

А вы уверены, что это «обычное» ПО, и не подлежит сертификации?

Off topic: https://pikabu.ru/story/sovetskie_inzhenery...ezhdali_2414570

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

Я считаю полезным высказывать свое мнение. Прислушиваться к нему или нет личное дело каждого. А вот и подходящая цитата:"You can lead a horse to water, but you can't make it drink".

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








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

Аргументы у каждого свои. А далее, см. приведенную выше цитату Марка Твена.

Но технические стороны вопроса от этого не меняются. В любом случае, это задача управления электродвигателем. Что для электромобиля, что для лифта, что для сцены.

Но вы хоть различаете BLDC двигатель от скажем AC или шаговика и в курсе что у них могут быть принципиально разные алгоритмы управления?
И задачи там могут на порядок отличаться по сложности.
Давайте ближе к конкретике если есть что сказать.

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

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

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

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

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

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

- Был высказан тезис, что HAL, SPL, Cube, Linux это все для мигания лампочкой, в сложных приложениях надо писать все самому, потому что не известно, чего там индусы "накодили". Далее, мною и еще рядом участников был задан вопрос: "а с чего вы взяли, что ваш быдло код, лучше индусского в перечисленных выше фреймворках? Вы его как-то сертифицируете или просто "зуб даете"?";

- Судя по написанному в дальнейшем в этой ветке, никто ничего не сертифицируют, а просто уверен, что он пишет код лучше индусов из СТ;

- В добавок ко всему, у меня возник уточняющий вопрос, а почему в домашних/офисных роутерах чаще всего крутится Линуксе, а на Боинг 737 линукс можно встретить разве что в развлекательной системе для пассажиров? Решать навигационные задачи и управлять элеронами с тягой куда как проще какой-нибудь rasberry pi было )). Я предполагаю, что для важных приложений, нужна сертификация, принятая в соответствующей отрасли. Написав код в соответствии со стандартом, легче потом будет его сертифицировать, линукс никогда не подразумевал какой-либо сертификации, поэтому его и не используют в важных приложениях, и это никак не связано со сложностью проекта (лампочкой там мигают или двумя).


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

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

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


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

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

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


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

Только не надо уводить тему в сторону.
Линукс огромен. Взять и переписать его полностью с нуля, но чтобы сверху работали все сторонние приложения никто не может.
А c HAL-ом нормальная практика.
Каждый профессионал сталкивается рано или поздно с необходимостью выкинуть HAL и заменить на свой более эффективный код.

По поводу каждого, вспомнилось:


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

я так не считаю. я в этой теме писал, что стоит куб использовать в больших проектах. Я тоже не понимаю, почему кто-то "фу, калокуб"? А где там кал? Да, хал (впрочем как и спл) громоздкая. Но это != глючная. Есть конкретный глюк в hal?

Я не считаю свой код лучше индусского, ровно как и хуже, поэтому я не брезгую HAL/SPL. Более того, я считаю, что популярная РТОС стабильнее самописного loop. Но не смотря на то, что используется, хал/спл/лл/свойКод /ртос - в любом случае нужно тестировать конечное ПО. Если индусский код кривой, то кривизна обнаружиться сразу.

я на боинге не работаю, но в смежной отрасли работаю. Могу от первого лица сказать - линукс (и не только) используется в авиации, сплошь и рядом. И купленный в составе с роутером, и в составе промышленной микроЭВМ, и свои сборки линукса из исходников.

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

Нет таких стандартов. Может такой стандарт и есть, если есть дайте пруфлинк.

Вы свечку держали?
Не знаю о чем вы говорите, возможно у вас на предприятии так и есть. Свой язык? Это как? В автомобильном контроллере, ту часть кода, что управляет обдувом ног будете писать на си, а управление тормозами на особом языке? Мы всё пишем на Си/С++.

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

чаще у неокрепших умов создается впечатление, что у них руки не из плеч. А вот у профессионалов динозавров-консерваторов, те да.... те несправившись с инитом в хале, выпиливают его и чуть-ли не свой стартап на асме пишут, со словами "тут без хала всё просто, лучше выучить и всё написать самому, хал - отстой/глючный/громоздкий/индусский".


ps я своё мнение высказал про куб/хал. Я влез в дискуссию, чтоб развеить подобные мифы. Может быть в боинге так и есть, управление вентиляцией не тщательно тестируют, а работу закрылок более тщательно, но на предприятиях, которые разрабатывают системы, связанные с жизнью, картина немного другая. Пишут ПО, тестируют, сертифицируют. Особыми либами и особыми инструментами не пользуются. Используют и спл, и хал, и линукс. Находят глюки в купленных корках альтеры - переписывают на свои. Находят дыры в ПО у ti - переписывают и т.д. .... Отдельно ПО не сертифицируется, сертифицируется весь комплекс.
Есть мифы, что для чистого звука, нужен особый USB кабель. И есть мифы, что важное ПО как-то по особому пишется, без хал, на специальном языке. Одинаково всё пишется.

pps все мои высказывания - только касательно встроенного ПО, где и используется HAL. Что касается сертификации и тестирования системного и прикладного ПО, которое продается/поставляется как ПО без железа (всякие астра-линуксы) - тут я молчу.

Да именно так.
Это все станкостроение, промышленная автоматизация.
Если вы об этом не знаете, то что у вас там за отрасль такая?
Если говорите за свою отрасль то назовите хоть ее, а то только наводите тень на плетень.
Все одинаково важным быть не может.