[-=az=- 0]

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

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

По большому счету это обмен опытом, который дорого стоит.

Как трактовать и использовать информацию данной ветки, конечно же каждый решает сам.

Изменено 15 февраля, 2018 пользователем -AZ-

[halfdoom 0]

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

[let's see 0]

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

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

 

[-=az=- 0]

А не лучше ли инициализацию подглядывать в SPL ?

Или она уже совсем заброшена?

[Allregia 9]

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

 

Полностью согласен.

Мне вообще кажется, что изначально не совсем верно был задан вопрос - причем тут 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 2]

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

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

 

Вспомогательные тулсы от ST, NXP, TI, Microchip... конечно нужны, поскольку выполняют роль интерактивных иллюстраций.

А стандартные доки не имеют нормальных иллюстраций.

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

Но функции периферии (HAL, драйвера или как их там еще называют ...) стоит писать самому.

Они по объему короткие, но сильнее всего влияют на качество реального времени.

 

Ни один HAL не может использовать 100% все возможности периферии.

Забавно, что юзеры HAL выбирают чипы именно по характеристикам периферии,

а потом в HAL-е не могут найти как эту периферию эффективно использовать.

 

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

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

Чем бесплатнее HAL, тем он больше будет подстроен под его создателей, чем под его пользователей.

[-=az=- 0]

Вы совершенно правы, речь в разрезе HAL драйверов периферии, которые необходимо писать самим.

Меня пытались убедить что различные доки по чипам это зло) взял Cube и Hal и погнал шлепать код не вникая в железо, регистры.

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

Интегрированные библиотеки (не драйвера) конечно нет смысла переписывать и изобретать велосипед, лучше их хорошо изучить и тестировать различными методами, как в общем-то и основной код.

Изменено 17 февраля, 2018 пользователем -AZ-

[leocat 0]

А не лучше ли инициализацию подглядывать в SPL ?

Или она уже совсем заброшена?

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

 

[Baser 3]

А не лучше ли инициализацию подглядывать в SPL ?

Или она уже совсем заброшена?

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

Сейчас я смотрю, видимо после массивной критики пользователей, все эти ярлыки убрали. Стало "Active".

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

 

 

А по вопросу топика, то тут почитаешь коллег, и складывается впечатление, что у всех проекты в жестком реалтайме, где каждую мкс нужно экономить, + у всех времени вагоны :)

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

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

В результате примерно половину HALовских функций нормально применяю. А приборы по 10-15 лет выпускаются, будет еще время подчистить код :)

[makc 190]

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

 

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

[leocat 0]

...

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

...

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

LL и SPL не одно и то же.

[halfdoom 0]

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

 

 

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

 

 

[AlexandrY 2]

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

Само определение 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 3]

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

LL и SPL не одно и то же.

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

 

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

[haker_fox 60]

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

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

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