[golf2109 0]

Дла реализации промышленного проекта 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 192]

Немного не так. 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 2]

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

И как вы поступите, если вам код нужно портировать с kinetis на stm32?

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

Но откуда авторы HAL знают что для вас несущественно?

Они свою абстракцию рождают при разработке своих демок.

 

Абстракция как бы должна вести к лаконичности, но API HAL-ов наоборот раздуто до неприличия.

Это от того, что им еще хотят придать видимость универсальности.

Но что небоевые инженеры в офисе ST могут знать об универсальности?

 

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

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

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

 

Как только вы патчите HAL, то становитесь его заложником.

На новые версии уже так просто не сможете перейти и принять участие во всеобщем веселье.

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

 

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

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

 

Ну а переход на другую платформу меня меньше всего заботит.

Я уже перешел с STM32 на Kinetis и не вижу поводов переходить обратно.

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

 

 

[haker_fox 60]

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

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

[halfdoom 0]

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

 

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

 

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

 

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

 

 

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

 

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

[Hiehachi 0]

STDlib для STM32 более менее приемлемое решение и понятное, к тому же не глючное. У HAL хорошая задумка и архитектура - но использовать эту индусскую реализацию просто не советую. Всё позже накроется медным тазом и потеряете лицо. Два выхода: тщательное изучение периферии внутренних модулей или выдергивание волос из носа, когда начинаются проблемы.

Из опыта: у atmel и stm похоже одни и те же индусы на поддержке сидят. Самый простой внешний интерфейс как UART и с тем не умеют правильно работать (не могут сбрасывать флаги ошибок периферии, то есть не читают документацию). HAL от идус-STM это килобайты кода в контексте прерывания и понаставленные собственные грабли, с которыми сами авторы не могут разобраться. Разрешают срабатывания прерывания когда их об этом не просишь ну и т.д.

Подход к прерываниям обусловлен старой архитектурой, когда она проэктировалась еще для 7-9 армы. Вместо выгоды в применении нового NVIC контроллера, который встроен в систему в CORTEX ядрах - HALL делает доунгрейт этой системы до скоростей уровня 7DMPI ядра + немеряно ненужного кода и времени нахождения в прерывании.

 

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

[haker_fox 60]

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

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

[Eddy_Em 1]

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

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

[Hiehachi 0]

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

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

 

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

 

[juvf 10]

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

При написании больших проектов ... ?

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

 

Дла реализации промышленного проекта 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 34]

Все хорошо, кроме двух грубых ошибок: 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й все зависло намертво... Вот и решил потом все писать сам.

[Eddy_Em 1]

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

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

 

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

[mantech 34]

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

 

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

 

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

Изменено 22 февраля, 2018 пользователем mantech

[Eddy_Em 1]

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

[Quasar 18]

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