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

[-AZ-]

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

[haker_fox]

Очень интересно мнение тех, кто имеет практический опыт по этой теме.

Как всегда на любой вопрос нельзя дать однозначного ответа. Всё зависит от ваших условий и вашего опыта. Я имею опыт использования библиотеки CMSIS для микроконтроллеров серии LPC. Мы решили в своё время её использовать как раз для упрощения работы, и, частично, полагали, что она избавит нас от рутины. Отчасти так и произошло. Но в каждой версии CMSIS'а я находит ошибки (I2C, DMA, SSP). Как правило, функционал этих библиотек никогда не соответствовал нашим требованиям (возможность работы с ОС, по прерываниям и т.п.). Да и самое обидное было искать ошибки в библиотеке, цель которое - избаватить нас от этого процесса. Но опыт мне дал возможность подумать, и сделать вывод: что сейчас я бы начал писать свой драйвер под каждый модуль микроконтроллера. Опираясь только на даташит, юзер мануал и т.п. Вполне возможно заглядывал бы в библиотеки как в референс-дизайн. Всё-таки люди там тоже не одну собаку съели, и некоторые моменты могут быть хорошо разжёваны. Поэтому смотрите сами. Если у вас опыт совсем небольшой, берите готовую библиотеку, ищите в ней ошибке по ходу работы, исправляйте под свои нужды. Если опыта достаточно, я полагаю вы бы не стали задавать этот вопрос. Но если опыта недостаточно, а времени - вагон с тележкой, то можете попробывать и подход, к которому я пришёл)))

[-AZ-]

Давно уже, гуру рекомендовали не использовать чужие либы, я так пошел.
Времени прошло много, да именно так как вы говорите, пишу свои драйвера на каждую периферию с полным пониманием регистров.
Но почему решил собрать актуальное мнение на сегодняшний день, сложность проектов растет, кол-во типов контролеров тоже, переносимость кода в общем-то получается никакая. И довольно сильно увеличивается время разработки. Хочется понять чем сегодня "дышит" мир гуру. Может все-таки время asm проходит...
Вопрос относится к разработкам в рамках производства, а не частных поделках.

Сообщение отредактировал phenixs - Feb 14 2018, 03:39

[haker_fox]

переносимость кода в общем-то получается никакая.

Это быть не должно. Я использую Си++ при разработке драйверов. Хотя это не важно. Но все драйвера имеют более-менее одинаковый интерфейс. Поэтому для софта не важно, работаете вы часами внутри микроконтроллера, или это часы на i2c висят. Или это часы вообще с sntp сервера.

Может все-таки время asm проходит...

Оно прошло ещё лет 15 назад.

Вопрос относится к разработкам в рамках производства, а не частных поделках.

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

[pitt]

Документация ко всем STM32, с которыми мне приходилось иметь дело не лезет ни в какие ворота - совершенно неоднозначная, написана не по-английски(по-видимому, французский или итальянский) и перевод ужасный. В таком случая Куб помогает понять, о чем же хотела сказать документация. Еще одно достойное применение Куба для электриков - быстро написать примитивный проверочный код для проверки железа/периферии. Для создания профессионального продукта его тоже "можно" использовать, если вас и ваших клиентов надежность интересует в последнюю очередь.
Сейчас молодые коллеги поднимут громкий крик о достоинствах этого индийского продукта, но, в конце концов, " думайте сами, решайте сами - иметь или не иметь..."

[scifi]

Документация ко всем STM32, с которыми мне приходилось иметь дело не лезет ни в какие ворота - совершенно неоднозначная, написана не по-английски(по-видимому, французский или итальянский) и перевод ужасный.

Люто минусую. За 10+ лет работы с STM всего пару раз столкнулся с неоднозначностью в документации, причём в мелочах. У писателей английский не родной язык, но текст весьма приличный. В общем, не надо напраслину возводить.

[-AZ-]

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

[Quasar]

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

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

[-AZ-]

Возможно не стоит содержать свой штат и писать драйвера которые кто то уже точно делал, а наверное под каждую задачу искать исполнителя на постоянной основе. Так будет ещё быстрее.

[Quasar]

Возможно не стоит содержать свой штат и писать драйвера которые кто то уже точно делал, а наверное под каждую задачу искать исполнителя на постоянной основе. Так будет ещё быстрее.

Не совсем понял, а что значит не содержать свой штат, но искать кого-то на постоянной основе? В смысле стороннего исполнителя на постоянной основе?

[-AZ-]

Не совсем понял, а что значит не содержать свой штат, но искать кого-то на постоянной основе? В смысле стороннего исполнителя на постоянной основе?

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

[Jenya7]

Категорически против CubeMX. Уж лучше SPL - намного лучше. А если его (SPL) подправить так вообще конфета получается.

[amiller]

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

[-AZ-]

Категорически против CubeMX. Уж лучше SPL - намного лучше. А если его (SPL) подправить так вообще конфета получается.

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

[0men]

применяю HAL, код из куба только для первого ознакомления изредка

[Connor]

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

Сообщение отредактировал Connor - Feb 14 2018, 09:47

[-AZ-]

Но как разработчик, вы отвечаете за код чем то...
Как, например, можно ручаться за куски чужого кода.
Я так понимаю 2 варианта:
1 - это сидеть перепроверять используемые функции HAL.
2 - за это время написать свои функции.

Потом пришел в работу камень для которого нет никаких HAL и прочего, тут хочешь, не хочешь пишешь свой драйвер.
В итоге один проект так, другой сяк, и как следствие никакой системы не выработано.

Сообщение отредактировал -AZ- - Feb 14 2018, 10:58

[Connor]

Потом пришел в работу камень для которого нет никаких HAL и прочего, тут хочешь, не хочешь пишешь свой драйвер.
В итоге один проект так, другой сяк, и как следствие никакой системы не выработано.

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

[-AZ-]

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

Ну камни определяются исходя из конкретного проекта, где то ST, где то TI, где то EFM и т.д. абсолютно нельзя сказать что взял ST для всех проектов и все, некоторые задачи нельзя на них реализовать, приходится брать другие...

Сообщение отредактировал -AZ- - Feb 14 2018, 11:38

[Jenya7]

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

Мой скромный совет - не пытайтесь покрыть все контролеры, как бык овцу, написанием генерик драйверов под все камни. И под TI, и под EFM есть свои SPLи.

[-AZ-]

Мой скромный совет - не пытайтесь покрыть все контролеры, как бык овцу, написанием генерик драйверов под все камни. И под TI, и под EFM есть свои SPLи.

Да вот собственно с SPL ST проблем не было, как у других производителей не скажу, через регистры делал.

[pitt]

Люто минусую. За 10+ лет работы с STM всего пару раз столкнулся с неоднозначностью в документации, причём в мелочах. У писателей английский не родной язык, но текст весьма приличный. В общем, не надо напраслину возводить.

Рекомендую сравнить с другой аналогичной документацией.
"Если других туфель не видел — наши вот такие! Если других машин не видел — «Запорожец» вот такой! И живи!" М.М. Жванецкий.

[scifi]

Рекомендую сравнить с другой аналогичной документацией.
"Если других туфель не видел — наши вот такие! Если других машин не видел — «Запорожец» вот такой! И живи!" М.М. Жванецкий.

Не надо грязи. Всё видел. Ну да, у этих покорявее, но документация вполне рабочая. А мсье изволит эстетствовать.

[AHTOXA]

По крайней мере никто не будет спорить что CubeMx с HAL гораздо более информативней и наглядней, чем старая SPL

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

[pitt]

Не надо грязи. Всё видел. Ну да, у этих покорявее, но документация вполне рабочая. А мсье изволит эстетствовать.

Равняться надо на лучшее, а желающие могут спать на потолке...

[sadat]

Использую куб как визуализацию распиновки и первичный более-менее рабочий код инициализации. Затем не оптимальные процедуры переписываю так, как мне удобнее.
Да и там этого кода совсем немного, чтобы изучить самостоятельно.

Интересен вопрос автора выше: "Как, например, можно ручаться за куски чужого кода." - бывают ошибки и в документации на проц, и всякие эррата обновляются со временем...
А как-то же люди пишут под винду/линукс....

[kolobok0]

...кол-во типов контролеров тоже, переносимость кода в общем-то получается никакая...Может все-таки время asm проходит...

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


постулат 1 = можно и на азме и в байт кодах писать с УЧЁТОМ ПЕРЕНОСИМОСТИ. Было бы желание, опыт, умение...
постулат 2 = язык написания есть ВЫБОР РЕШЕНИЯ под КОНКРЕТНУЮ задачу, условия и больше ничего... у каждого языка есть плюсы и есть минусы ессесвенно.


удачи вам
(круглый)

[mcheb]

Использую куб как визуализацию распиновки и первичный более-менее рабочий код инициализации

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

[-AZ-]

Использую куб как визуализацию распиновки и первичный более-менее рабочий код инициализации. Затем не оптимальные процедуры переписываю так, как мне удобнее.
Да и там этого кода совсем немного, чтобы изучить самостоятельно.

Интересен вопрос автора выше: "Как, например, можно ручаться за куски чужого кода." - бывают ошибки и в документации на проц, и всякие эррата обновляются со временем...
А как-то же люди пишут под винду/линукс....

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

[Aleksandr Barano...]

-AZ-. Мне кажется, не стоит задавать таких вопросов, особенно на форуме. Вы сами должны решить, что Вам применять, и как. Вы всякий раз получите широкий ассортимент ответов от "Ура!" до "Долой!" и все равно останетесь перед личным выбором.

[-AZ-]

-AZ-. Мне кажется, не стоит задавать таких вопросов, особенно на форуме. Вы сами должны решить, что Вам применять, и как. Вы всякий раз получите широкий ассортимент ответов от "Ура!" до "Долой!" и все равно останетесь перед личным выбором.

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

Сообщение отредактировал -AZ- - Feb 15 2018, 01:00

[halfdoom]

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

[pitt]

Куб действительно удобен для начального раскидывания ножек и периферии. Можно подсмотреть в инициализацию и реализацию. Но на этом все.

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

[-AZ-]

А не лучше ли инициализацию подглядывать в SPL ?
Или она уже совсем заброшена?

[Allregia]

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

Полностью согласен.
Мне вообще кажется, что изначально не совсем верно был задан вопрос - причем тут CubeMX если речь в основном шла про HAL?

Сам CubeMX - отличная программа, очень помогает при проектировании схемы, особенно на новом процессоре - раскидывание ножек, распределение периферии, выбор и оптимизация клоков - все это с Кубом делать на порядки проще чем без него!
Да, скажут - "возьми даташит и по нему сделай клоки".
Можно.
Но я искренне завидую тем, кто способен держать в памяти все возможные комбинации множителей/делителей и частот.
Особенно, когда надо выполнить ряд условий - например иметь и частоту ядра определенную, и обеспчить USB/SDIO требуемым клоком, и уарнты обеспечить, и I2S, и наружу через МСО выдать то что нужно.

Недавно коллеги на работе белали новый проект, на базе моего старого. Использовали другой процессор. И все было классно, пока не выяснилось, что в новом проце нет делителя /3 на выводе МСО, а в старом проце - был.
Кварц стоит 24Мгц и надо на МСО иметь или 8, или 16, или 32. Так периферия требует.
А уже и плата была готова!

HAL'ом конечно лучше не пользоваться в "боевых" проектах, максимум использовать инициализацию, да и то не всегда.
Но вполне можно им пользоваться в тестовых "прикидках", чисто для ускорения времени, особенно для второстепенных вещей.
(ну вот как-то надо было поиграться с I2S, попутно с некоторым ногодрыгом и УАРТОм. I2S и написали все руками, а настройки ногодрыга и уарта - Куб сгенерил с HALом.)

P.S. стало уже ругательным слово "калокуб", но мы же не виноваты что у STM сейчас все с прставкой "Cube - вон не так давно вышел STMCube Programmer - ни малейшего отношения не имеющий ни к Кубу, ни к Халу!
Это просто STLInk Utility+FlashLoader+DfuSe, собранные в одной программе. (И что самое ценое - поддерждивающиее новые процессоры, в отличие от древнего Flash Loaderа.)

[AlexandrY]

Хочется понять чем сегодня "дышит" мир гуру.

Почему у вас растет количестов типов контроллеров? Вот в чем вопрос. Почему нельзя остановиться на одном семействе?

Вспомогательные тулсы от ST, NXP, TI, Microchip... конечно нужны, поскольку выполняют роль интерактивных иллюстраций.
А стандартные доки не имеют нормальных иллюстраций.
Чужие либы нужны обязательно, вам большую часть времени стоит посвятить анализу и интеграции чужих либ.
Но функции периферии (HAL, драйвера или как их там еще называют ...) стоит писать самому.
Они по объему короткие, но сильнее всего влияют на качество реального времени.

Ни один HAL не может использовать 100% все возможности периферии.
Забавно, что юзеры HAL выбирают чипы именно по характеристикам периферии,
а потом в HAL-е не могут найти как эту периферию эффективно использовать.

Архитектура HAL-ов ST создана так чтобы покрыть всех представителей семейства сразу. Поэтому тексты избыточны и непроходимы.
А вот скажем среда от Micrium генерит строго целевые HAL-ы, заточенные только на вами выбранный чип, ничего лишнего.
Чем бесплатнее HAL, тем он больше будет подстроен под его создателей, чем под его пользователей.

[-AZ-]

Вы совершенно правы, речь в разрезе HAL драйверов периферии, которые необходимо писать самим.
Меня пытались убедить что различные доки по чипам это зло) взял Cube и Hal и погнал шлепать код не вникая в железо, регистры.
Вот и думаю, то ли отставать от темы начинаю и теряю кучу времени на свои драйвера, то ли все больше появляется людей которые не хотят этим забивать голову, но тогда как у них что то работает ?(наверно).
Интегрированные библиотеки (не драйвера) конечно нет смысла переписывать и изобретать велосипед, лучше их хорошо изучить и тестировать различными методами, как в общем-то и основной код.

Сообщение отредактировал -AZ- - Feb 17 2018, 14:52

[leocat]

А не лучше ли инициализацию подглядывать в SPL ?
Или она уже совсем заброшена?

SPL - поддерживается. Но, как уже написали, куб удобен на посмотреть какие ноги для чего, тактирование.

[Baser]

А не лучше ли инициализацию подглядывать в SPL ?
Или она уже совсем заброшена?

В середине прошлого года на сайте ST про SPL все упоминания были "устаревшая", "не рекомендованная для новых проектов", "смотрите HAL".
Сейчас я смотрю, видимо после массивной критики пользователей, все эти ярлыки убрали. Стало "Active".
Более того, в последние версии CubeMX добавили поддержку SPL, можно выбрать для каждого периф.модуля, что будет применяться для генерации кода, HAL или SPL.


А по вопросу топика, то тут почитаешь коллег, и складывается впечатление, что у всех проекты в жестком реалтайме, где каждую мкс нужно экономить, + у всех времени вагоны
У меня все проекты неспешные, с быстродействием человеческой реакции, т.е. 10-ки мс. Но их много накопилось еще живых, несколько десятков. Со старых времен на ПИКах и АВРках, последних много на MSP430, а сейчас переползаем на STM32. И все это нужно поддерживать. Времени на разработку новых приборов много нет, зато потом можно не спеша, понемножку, все улучшать и доделывать. Поэтому по-быстрому генериться проект в CubeMX и делается его копия рядом.
Дальше один проект рабочий, а другой CubeMX-ный. Поскольку для меня семейство STM32 новое, наработок нет, то каждый следующий периферийный блок генерится в Кубе и переносится в рабочий проект, где уже просматриваются все HALовские функции и если они не слишком ужасны, то оставляются, если никак не лезут в мою концепцию, то пишется свое. Все макросы и прочие наслоения хидеров оставляю, ибо там так все завязано в один узел, что нужно либо все выбрасывать (а туда и CMSIS вплетен), либо все оставлять.
В результате примерно половину HALовских функций нормально применяю. А приборы по 10-15 лет выпускаются, будет еще время подчистить код

[makc]

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

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

[leocat]

...
Более того, в последние версии CubeMX добавили поддержку SPL, можно выбрать для каждого периф.модуля, что будет применяться для генерации кода, HAL или SPL.
...

Не путайте теплое с мягким... кубик генерит или LL или HAL.
LL и SPL не одно и то же.

[halfdoom]

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

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

[AlexandrY]

важно не только что именно применяется (какая библиотека), но и каким образом.

Само определение HAL (hardware abstraction layer) указывает на его слабость.
Как можно абстрагировать hardware если мы выбираем его за его уникальность?
Т.е. как минимум в некотрых случаях HAL в принципе будет неприемлем если хотим использовать периферию инновационным способом.
Каким бы образом вы HAL не применяли он однозначно вас изолирует от кучи полезной функциональности конкретной периферии.

В embedded изоляцию от железа надо ограничивать BSP (board support package) и PSP (platform support package)
Но даже эти вещи слишком абстрагированы от железа.
Изоляция в виде HAL удобна видимо начинающим и неопытным программистам.
Поскольку у них от мануалов по периферии в несколько тысяч страниц возникают нехорошие чувства. Их можно понять.
По опыту скажу, чтобы приспособиться под информационную экосистему производитекля (структура, состав, стиль мануалов и т.д.) нужно несколько лет.
У кого нет столько времени, понятно, альтенативы HAL-у не имеет.

Когда я стал очень давно применять RTOS я понял, что ни один HAL и даже BSP мне не подходят.
На уровне HAL нигде не используются сервисы RTOS. Максимум могут предложить самому написать свои функции синхронизации.
Отсутствие асинхронности на уровне доступа к периферии рушит всю идеологию RTOS и принципы планирования.

Иногда BSP очень сильно интегрирован в RTOS, например так обстоит в MQX.
Тогда мне пришлось большими усилями вырвать из лап BSP управление DMA чтобы использовать его так как мне надо.
Но еще много периферии осталось под властью BSP: USB, SDIO, Ethernet
Но только потому что у них у всех есть собственный механизм DMA.

[Baser]

Не путайте теплое с мягким... кубик генерит или LL или HAL.
LL и SPL не одно и то же.

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

А по теме топика понравились комментарии AlexandrY, очень толковые и красиво сформулированные, хоть в статью оформляй. Поддерживаю!

[haker_fox]

У кого нет столько времени, понятно, альтенативы HAL-у не имеет.

Расскажите, пожалуйста, как вы обращаетесь к железу в своём коде? Всё-равно же какая-то абстракция есть? Ну, например, в коде терминала (консоли) вы же не обращаетесь к регистру данных последовательного порта или ethernet'а напрямую?
И как вы поступите, если вам код нужно портировать с kinetis на stm32?

[golf2109]

Дла реализации промышленного проекта STM32F769BI & LCD screen 7" 800x480 FreeRTOS, STemWin, FATFS, SDIO, FMC 32 bit, LTDC 24 bit, DMA2D, 3xUART, I2C, CAN, RTC, QSPI, ETM, SPI, FS USB - испоьзовался CubeMX для конфигурации всей периферии и настройки FreeRTOS и FATFS - все работает отлично, и самое главное радуют затраты времени на конфигурацию и последующие ремапы выводов.

[makc]

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

Вы хотите сказать, что разрабатываете прошивки исключительно с полным соблюдением MISRA C? Включая их статический анализатор?

Если нет, то любой код содержит ошибки. При исполнении любого кода что-то может пойти не так (некорректная обработка внешних условий и исключительных ситуаций). Поэтому я не вижу почему HAL нельзя использовать в проектах, где цена ошибки велика и быстродействие критично (профилировку и оптимизацию никто не отменял. Я пытаюсь сказать, что в случае правильного использования HAL будет хорошо работать правило 20/80 (закон Парето). А потом, правильно его применив, потратить оставшееся время (80%) на отладку и тонкую доводку. Возможно, с патчами в коде HAL.

Само определение HAL (hardware abstraction layer) указывает на его слабость.
Как можно абстрагировать hardware если мы выбираем его за его уникальность?

Есть типовые периферийный блоки для решения вполне стандартных задач (таймеры, контроллеры SPI/I2C и т.п.). Да, они отличаются функциональными особенностями и регистрами, но в целом они очень похожи и с прикладной точки зрения вполне могут быть взаимозаменяемы. Поэтому я не вижу тут никакой слабости.

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

Т.е. как минимум в некотрых случаях HAL в принципе будет неприемлем если хотим использовать периферию инновационным способом.
Каким бы образом вы HAL не применяли он однозначно вас изолирует от кучи полезной функциональности конкретной периферии.

Пардон, но я нигде не утверждал, что HAL покрывает возможности периферии на 100%. Также не говорил, что не нужно знать возможности и особенности этой периферии. Это все знать нужно, но на это и есть процесс тонкой доводки после того, как большая часть функционала была реализована.

Повторюсь выражаясь иначе: чтобы грамотно применять HAL нужно знать и понимать, как работает железо и периферия отдельно взятого контроллера. HAL не может заменить это понимание, что и показывают многие неудачные попытки его применения новичками. Но для опытного разработчика он может позволить сэкономить время на разработку базового функционала, с точной доводкой под частную задачу, с дополнительной оптимизацией. Ценой является определенный оверхед, но если объем флеша позволяет, то почему бы и нет?

[AlexandrY]

Расскажите, пожалуйста, как вы обращаетесь к железу в своём коде? Всё-равно же какая-то абстракция есть? Ну, например, в коде терминала (консоли) вы же не обращаетесь к регистру данных последовательного порта или ethernet'а напрямую?
И как вы поступите, если вам код нужно портировать с kinetis на stm32?

У меня не абстракции, а минималистичные наборы функций, только для целевой задачи. Абстракция - это некое обобщение, исключение несущественного.
Но откуда авторы HAL знают что для вас несущественно?
Они свою абстракцию рождают при разработке своих демок.

Абстракция как бы должна вести к лаконичности, но API HAL-ов наоборот раздуто до неприличия.
Это от того, что им еще хотят придать видимость универсальности.
Но что небоевые инженеры в офисе ST могут знать об универсальности?

Вот когда говорят, что успешно применили HAL, там с GUI от segger-а, UART-ами, SPI, Ethernet и проч., то я почти не сомневаюсь что сделано это было на базе демок от ST.
Малейшее отклонение от демки в сторону увеличения пропукной способности, более жесткого реального времени, увеличения количества одновременно работающих интерфейсов и следует разочарование.
Поскольку оказывается, что надо штудировать сразу два огромных пакета документов: мануал по программированию семейства и мануал на HAL.

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

Между тем на самом деле функции работы с периферией можно сделать очень короткими и предельно прозрачными.
Например, работа с АЦП в моем пректе универсального модуля

Ну а переход на другую платформу меня меньше всего заботит.
Я уже перешел с STM32 на Kinetis и не вижу поводов переходить обратно.
Я ж сравнивал их не один год и дружил я с ST много лет. Все прикладное интресное для ST с легкостью переносится на Kinetis, но вот сказать обратное нельзя.

[haker_fox]

но вот сказать обратное нельзя.

Мне всегда нравятся ваши подробные и развёрнутые ответы! Прочел. Надо обдумать))))

[halfdoom]

Вы хотите сказать, что разрабатываете прошивки исключительно с полным соблюдением MISRA C? Включая их статический анализатор?

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

Поэтому я не вижу почему HAL нельзя использовать в проектах, где цена ошибки велика и быстродействие критично (профилировку и оптимизацию никто не отменял. Я пытаюсь сказать, что в случае правильного использования HAL будет хорошо работать правило 20/80 (закон Парето). А потом, правильно его применив, потратить оставшееся время (80%) на отладку и тонкую доводку. Возможно, с патчами в коде HAL.

Здесь можно углубиться в непролазные дебри обсуждения каждой функции с избыточным кодом, поэтому просто отмечу - мы уже пытались базировать свой код на HAL и результат заметно хуже по времени разработки, объему бинарника и быстродействию. Но, повторюсь, у нас задачи далеки от отправки десяти байт через GSM.

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

И это тоже. Для сравнения, один из наших "умников" (в хорошем смысле слова), унифицировал внутренний API до такой степени, что прикладная задача практически не видит разницы между применяемыми МК семейства С2000 (TI) и STM32F3. И да, совсем забыл - все библиотеки и обертки написаны на C++ с очень жесткой типизацией всего чего только можно, поэтому даже выставить бит в одном регистре пользуясь дефайном от другого, весьма проблематично.

[картошка]

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

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

[haker_fox]

Мне всегда нравятся ваши подробные и развёрнутые ответы! Прочел. Надо обдумать))))

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

[Эдди]

работа с АЦП в моем пректе универсального модуля

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

[картошка]

Использую куб как визуализацию ... Затем не оптимальные процедуры переписываю так, как мне удобнее.
Да и там этого кода совсем немного, чтобы изучить самостоятельно.

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

[juvf]

Все-таки стоит ли применять подобные вещи ...
При написании больших проектов ... ?

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

Дла реализации промышленного проекта STM32F769BI & LCD screen 7" 800x480 FreeRTOS, STemWin, FATFS, SDIO, FMC 32 bit, LTDC 24 bit, DMA2D, 3xUART, I2C, CAN, RTC, QSPI, ETM, SPI, FS USB - испоьзовался CubeMX для конфигурации всей периферии и настройки FreeRTOS и FATFS - все работает отлично, и самое главное радуют затраты времени на конфигурацию и последующие ремапы выводов.

+1, ППКС.

SPL по сравнению с HAL - это просто образец понятности.

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

[mantech]

Все хорошо, кроме двух грубых ошибок: 1) комментарии на русском языке

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

Дла реализации промышленного проекта STM32F769BI & LCD screen 7" 800x480 FreeRTOS, STemWin, FATFS, SDIO, FMC 32 bit, LTDC 24 bit, DMA2D, 3xUART, I2C, CAN, RTC, QSPI, ETM, SPI, FS USB - испоьзовался CubeMX для конфигурации всей периферии и настройки FreeRTOS и FATFS - все работает отлично, и самое главное радуют затраты времени на конфигурацию и последующие ремапы выводов.

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

[Эдди]

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

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

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

[mantech]

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

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

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

Сообщение отредактировал mantech - Feb 22 2018, 18:50

[Эдди]

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

[Quasar]

// а отписывающиеся тут в пользу [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) если есть совесть.

[AlexandrY]

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

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

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

[HardEgor]

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

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

[Quasar]

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

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

...ANSI? UTF? Win1251? А на английском никаких проблем.

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

[off]

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

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

[Эдди]

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

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

[pitt]

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

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

[SSerge]

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

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

[AlexandrY]

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

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

[Эдди]

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

Сообщение отредактировал Эдди - Feb 23 2018, 12:58

[rudy_b]

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

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

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

[mantech]

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

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

[Quasar]

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

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

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

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

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

[mantech]

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

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

[AlexandrY]

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

Например, у меня есть ряд проектов, в которых на STM32F4 крутится DMR стек (стек цифровой радиосвязи) с вокодером, TCP/IP стек и USB в режиме виртуального COM порта.
От HAL очевидно придется уйти только тем, у кого:
1) Дикая серия и камень взят впритык, ибо на больших сериях каждый доллар на счету;
2) Если у вас жесткие требования по потреблению.

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

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

[Quasar]

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

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

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

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

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

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

[AlexandrY]

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

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

[Quasar]

Да ладно то к мелочам придираться, я ж искал по "DMR stack" . Примитивная 4-FSK модуляция. Там демодулятор не больше сотни строк.

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

lwIP конечно можно использовать, но достался он вам в виде рабочей демки. Сомнительная заслуга что он у вас работает на STM32.

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

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

[pitt]

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

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

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

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

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

[Quasar]

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

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

[Professor Chaos]

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

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

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

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

[AlexandrY]

... - хороший пример - управление электродвигателями.
вторая - про отечественный микроконтроллер К1921ВК01Т от НИИЭТ и про решение задачи управления двигателем на нём...

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

[Quasar]

Это обычная промышленная задача, решаемая для управления лифтом, троллейбусом, трамваем, электровозом, карьерным самосвалом или тепловозом с электрической передачей.

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

[Aleksandr Barano...]

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

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

Сообщение отредактировал Aleksandr Baranov - Feb 25 2018, 14:29

[Professor Chaos]

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

[pitt]

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

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

[Quasar]

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

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

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

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

[pitt]

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

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

[Professor Chaos]

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

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

[AlexandrY]

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

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

[juvf]

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

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

[AlexandrY]

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

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

[makc]

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

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

[juvf]

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

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

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

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

[Quasar]

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

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

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

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

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


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

[AlexandrY]

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

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

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

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

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

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

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

[Quasar]

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

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

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

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

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

[AlexandrY]

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

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

[Quasar]

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

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

Второе по значимости событие в жизни каждого мужчины — это день, когда он покупает яхту, а самое великое событие в его жизни — тот день, когда он ее продает.

Д. Трамп.

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

[juvf]

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

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

почему в домашних/офисных роутерах чаще всего крутится Линуксе, а на Боинг 737 линукс можно встретить разве что в развлекательной системе для пассажиров? ...........линукс ................. не используют в важных приложениях...........

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

Я предполагаю, что для важных приложений, нужна сертификация, принятая в соответствующей отрасли.

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

Написав код в соответствии со стандартом

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

вы не программировали системы отвественные за безопасность

Вы свечку держали?

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

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

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

У не окрепших умов создается впечатление, что это неработающее "Г..."

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


ps

Я предполагаю .... мне кажется

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

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

[AlexandrY]

Свой язык? Это как? В автомобильном контроллере, ту часть кода, что управляет обдувом ног будете писать на си, а управление тормозами на особом языке?

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