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

согласно ГОСТ Р 8.654-2015 и Р 50.2.077-2014



например, 66314-16

Там ничего необычного нет, простые вещи которые соблюдают нормальные программисты. Вы еще про стандарты оформления ПО вспомните.

Видимо, вы не совсем в теме, бывает. Рекомендую еще взглянуть на ГОСТ Р МЭК 61508-6-2012, но он к метрологии не имеет отношения.

Сообщение отредактировал 0men - Mar 12 2018, 14:07

При чем тут метрология, идет разговор о надежности применения CubeMX и HAL в своих изделиях и методов испытания надежности ПО.

про надежность смотрите ГОСТ Р МЭК 61508 и гост р мэк 61511. У импортных он упоминается как SIL

Сообщение отредактировал 0men - Mar 12 2018, 15:51

Тоже метрологией занимаюсь. Спорить не буду, но считаю, что гарантом качества и безопасности может выступать только производитель. А всё остальное от лукавого. Все эти сертификаты - лишь бумажки. И лучше разработчика никто не оттестирует изделие. Понятно, что вылизывание - это самая длительная и, соответственно, самая дорогостоящая операция. Любой производитель всегда будет пытаться её минимизировать. Иначе возрастает, цена, неоправданно растут сроки и т.д. Любой производитель может сделать продукт лучше и надёжнее. Вот только вопрос - нужен ли он рынку.
По теме вопроса - личное мнение я уже озвучивал.
Считаю, что тема не особенно актуальна. Если рассматривать чисто обработку железа - то бишь драйвера - то это несколько процентов от общего объёма проекта. Если рассматривать всякие там GUI, OS и прочие входящие компоненты, то надо понимать, что это совершенно независимые разработки. Применение каждой из них должно рассматриваться в отрыве.
Как правило драйвера, в том виде, в котором они написаны - просто не нужны. Я бы сказал бессмысленны и явно избыточны.
Например, мне трудно представить проект, где органично бы вписался драйвер USART от ST. Возможно у меня фантазия слабая.
Что ещё нехорошо, это то, что все библиотеки завязаны друг на друга. В результате, при использовании одного устройства благополучно подключается несколько других. Таким образом весьма проблематично использовать микс из своих и чужих дров и т.п.

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

Похоже для STM и ATMEL библиотечный код пишет один и тот же индус. При принятии данных заставить прочитать регистр статуса перед регистром данных - ни в какую не хочет. На STM UARTe такой ленивый подход просто аппаратно блокирует прием данных вообще, если закрался FE при приеме.
Для I2C по атмелу весь код - сплошные прерывания, зачем ? Эти функции например нельзя использовать в контексте другого прерывания ! Система API таймеров для ATMEL оперирует 4 байтными значениями задержек в микросекундах, при использовании подсчета не атомарных величин - запрещают прерывания, длительность расчета превышает десятки микросекунд, при использовании например UART на скорости выше или равно 115200 - задержка для вычисления времени API TIMER калбэков по таймерам превышает время трансляции байта, а так как у atmel нет FIFO - данные просто теряются. При задержке в калбек функции по премени вычисления больше чем запрограммировано время следующего калбека - вылет и неопределенное значение внутреннего программного состояния Timer API - ну и т.д.
И это что считается нормальным поиск багов ? Такие API не годятся вообще никуда, они только показательны и только когда работают одни в системе, или таймера или UART или I2C. А вот в связке функционирования - полная Ж... . Вообще халява она для особенных людей, когда ее кто-то ищет - это очень яркий ярлык отсутствия шишек.

Мое впечатление от HAL в этой цитате.

Стандартные решения средствами HAL вполне интересны, но не стандартные варианты увы не подъемны. SPL может помочь для отважных фантазеров. Когда HAL будет способен на ЛЮБУЮ импровизацию, тогда свершится ожидаемый скачок.

Пример. SDIO заточен на обмен с SD. Это значит, что в перечне команд заложены стандартные наборы с соответствующими ответами. Архитектура(CRC7, CRC16, стартовые\завершающие коды, файловая система и т.п.) присутствует явно в HAL. .....Жизнь диктует свои законы и стык SDIO можно использовать для многих применений(подразумевается гибкость ПЛИС).
В этом случае произвольным образом менять коды команд, а также необходимость ответа на них при помощи HAL проблематично.
И вся эта красота моментально рушится.

Кроме банальных и грубых ошибок в API поддержек микроконтроллеров, существует еще и простые политики - зарабатывание денег.


API периферии, а ТАКЖЕ ПЕРИФЕРИЙНЫЕ УЗЛЫ между производителями - ранее, ныне и всегда будут уникальными, это способ затормозить юзеров на переход или смену "периферийного железа" на другого производителя, это по крайней мере должны понимать не наивные люди. И как вследствие этого НИКОГДА НЕ БУДЕТ безболезненного перехода. Время чтения документации + поиск багов + нереальные трудности по изменению "специально написанного" кода - делают своё дело, причём это делается скорее всего целенаправленно, чем случайно.

Сколько продержалась STM_SPL уступив STM_HAL, кому мешала быстро переносимая API архитектура ?

А в каком конкретно месте этот баг? Глянул на вскидку хал для stm32l0 функцию HAL_UART_Receive(), сначало читается ISR, потом RDR.

довод ни о чем. все ваши высказывания в двух словах - "хал грамоздкий". А то что там по времени что-то у вас не пролезло, хал тут не причем. Он грамоздкий - со всеми вытекающими, этим всё сказано. Запустите хал на 150 МГц и пролезут ваши 115200. С другой стороны.... вы свой код соптимизируте на 48МГц, ваши 115200 с запасом будут работать.... в другом проекте нужно будет проц на 1 МГц запустить.... и те же грабли, что вы описали.

дма нет?

В части где нелинейно укрюченый код отловил FE или NOISE Interrupt - ТАМ. Возможно и подправили со временем, но когда обычно такой код пишут , он много говорит о том кто его писал.



Это не XMEGA и не STM, не MSP и не LPC. Это класика AVR .



Интересно, а к чему тогда мануалы: ну например что такое 240 mka / 1 Mhz. Сейчас полно автономных устройств на своем питании, где время выполнения кода играет первостепенную роль.
Дык, волшебство превращения контроллера в кирпичеподобную субстанцию за день работы - вот, это точно не выход.
Надо вообще разбить ветку форума на две, в одной высказывания программистов "которым еще кажется" в другой "которые уже открестились"

Сообщение отредактировал картошка - Mar 13 2018, 12:45

В этом случае без SPL не обойтись.... Какие рекомендации от корифеев?

А был ли мальчик? Так и не нашел я ни какого бага, о котором вы говорите. Из гита качнул самую первую версию
При приеме вычитывается статусный регистр в течении таймаута, если пришел RXNE, то читаем RDR. По другому - даже кривыми руками не написать. Вы говорите
Но с самой первой версии хала вычитывается статусный регистр. Толи вы не заметили эту вычитку, толи какая-то другая ошибка в хале? Может нет анализа флага FE, может этот баг в функции приема по ДМА?
Почему я за это зацепился? Я использую хал, и не хочу наступить на эту граблю если она есть. Вы можете показать эту граблю? Если не можете, то с вашими выводами всё понятно.

Уже 15 страниц толкуют, что HAL===SPL (только с бóльшими извращениями), и опять начинай сначала…
Только внимательное чтение даташита поможет правильно реализовать требуемый алгоритм. И никакие SPL/HAL/opencm3/что-то-еще не помогут.
Невозможно обойтись без опыта разработки, неизбежно дающего в качестве побочного продукта пополнение личного багажа сниппетов. Если ты один раз написал сниппет для работы с SD-картой и, скажем, файловой системой ext2, то и дальше это будешь использовать. Если не написал, то ничто не поможет.

Вы не поняли... Когда от SDIO не требуется обмен с SD, а требуется клон, который резко отличается от SD-спецификации,-HAL- беспомощен, потому как в нем прописан промышленный стандарт. Выход Только в прямом управлении регистрами!..
HAL хорош для стандартных решений. ЛЕГО!!!