Jump to content

    
Sign in to follow this  
Ruslan1

STM32: регистровый CMSIS или высокоуровневый HAL ?

Recommended Posts

лично мои впечатления.

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

и тут понадобилось заточить проект на STM32. собирал проект на HAL. два дня собирал. собрал таки. дошел до функции HAL_SPI_TransmitReceive. тихонько перешел на SPL. собрал проект за пол часа целуя в его небритые щеки (или что там у него есть). все что имею сказать по этому поводу.

Edited by Jenya7

Share this post


Link to post
Share on other sites
собирал проект на HAL. два дня собирал. собрал таки. дошел до функции HAL_SPI_TransmitReceive. тихонько перешел на SPL. собрал проект за пол часа целуя в его небритые щеки

 

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

Но у меня наклевывается проект на STM32F7, и насколько я помню - для него SPL нет, а только HAL.

Что очень жаль, поскольку этот проект переводится со старого SPL-проекта на STM32F4.

Share this post


Link to post
Share on other sites
Это конечно все хорошо, я сам SPL пользую (в основном для первичных нициализаций, а где надо скорость - там напрямую в регистры).

Но у меня наклевывается проект на STM32F7, и насколько я помню - для него SPL нет, а только HAL.

Что очень жаль, поскольку этот проект переводится со старого SPL-проекта на STM32F4.

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

на крайний случай - работа с регистрами. ничего страшного.

Edited by Jenya7

Share this post


Link to post
Share on other sites

Я в проектах часто использую Chibios и, соотвественно, его HAL. Сейчас его отвязали от ядра RTOS, и можно пользоваться им отдельно. На мой взгляд, получилось очень даже неплохо. Поддерживает только самое основное, если что-то нужно подкрутить под капотом, то можно и с регистрами поработать. Размер маленький получается за счет черной магии макросов.

Share this post


Link to post
Share on other sites

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

 

Что же касается непосредственно HAL, то, лично мне кажется, в своем стремлении абстрагироваться от регистров и низкоуровневой работы с периферией разработчики HAL переборщили. Вроде как теперь и reference manual то читать не надо (точнее похоже на то, что этого хотели добиться), но с другой стороны теперь надо читать код HAL или доку на него (кто что предпочитает). В свою очередь чтобы хорошо ориентироваться в SPL нужно все же обращаться к reference мануалу, поскольку многие типы и макроопределения введенные там непонятны без прочтения документации на проц. Но опять же и в том и другом случае разобраться то надо всего ОДИН раз, потом спокойно работаешь не заботясь о периферии.

Share this post


Link to post
Share on other sites

C HAL просто начать, но там нет нужных функций. Для их реализации надо написать немного кода, но в их идеологии. А она немного кривовата. Если посмотреть на более популярный mbed - там немного сложнее и еще более корявее. а с переходом на mbedos и yotta - стало просто мозголомкой. Но если не выходить за рамки - почти как в arduino (а это устраивает 95% "разработчиков" :)).

Я использую все известные библиотеки и никаких проблем с выбором нет вообще.

Что надо использую, что не надо - удаляю и делаю своё.

 

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

 

Но всегда проще написать свою реализацию (хотя иногда она и не так красива как результат труда других людей).

Share this post


Link to post
Share on other sites

Я свои проекты делаю на SPL, потеря в тактах и байтах минимальна (давно тестил - буквально 1-2%). Сейчас переход на stm32f7 осложняется отсутствием оного для этих чипов. HAL действительно монстроподобен и похоже парой процентов потерь не обойдется.

Насчет SPL для stm32f7, есть такая мысль - судя по даташитам F7 включает в себя F4 с некоторыми новыми наворотами, т.е. по идее можно использовать SPL от F4 для F7. Осталось попробовать перенести ее.

Edited by makser

Share this post


Link to post
Share on other sites

Мне по барабану регистры, SPL, HAL - у меня код аппаратной занимает максимум 5% от всего кода (обычно 1-2%).

Вообще непонятна цель этих дискуссий.

Просто делать нечего в деревне - бабки выходят и начинают ни о чем говорить.

Хотя они при деле и время проходит незаметно.

Share this post


Link to post
Share on other sites
Мне по барабану регистры, SPL, HAL - у меня код аппаратной занимает максимум 5% от всего кода (обычно 1-2%).

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

Share this post


Link to post
Share on other sites

Это легко сравнивается через DWT, таймером, профайлером и всегда можно выбрать оптимальный вариант. Да и умелым программированием можно производительность угробить без регистров/SPL/HAL.

 

Нельзя всех сапожников заставить пользоваться одним типом молотка.

Share this post


Link to post
Share on other sites

Ковырял stm32f4xx_hal_eth.c и нашел интересный момент. Много записей в MAC регистры сделаны таким макаром:

static void ETH_FlushTransmitFIFO(ETH_HandleTypeDef *heth)
{
  __IO uint32_t tmpreg1 = 0U;
  
  /* Set the Flush Transmit FIFO bit */
  (heth->Instance)->DMAOMR |= ETH_DMAOMR_FTF;
  
  /* Wait until the write operation will be taken into account:
     at least four TX_CLK/RX_CLK clock cycles */
  tmpreg1 = (heth->Instance)->DMAOMR;
  HAL_Delay(ETH_REG_WRITE_DELAY);
  (heth->Instance)->DMAOMR = tmpreg1;
}

Т.е. в регистр происходит запись, потом он же читается, потом задержка на от ~0 до 1-го systick и запись прочитанного опять в регистр.

Напрягает плавающая задержка. В мануале на stm32 не нашел требований по задержке...

Share this post


Link to post
Share on other sites

Только начал изучать STM32 CubeMX.

До сих пор не понятен один момент - как соотносятся CMSIS и HAL  библиотеки?

Пересекаются, дополняют друг-друга или независимы?

-------------------------------------------------------------------------

Насколько понял сам:

а) Есть CMSIS для конкретного ядра (без периферии) \Drivers\CMSIS\Include. В этих инклудах нет ничего из периферии типа ADC\GPIO

б) Есть CMSIS для STM32 периферии \Drivers\CMSIS\Device\ST\STM32F4xx\Include. В этих инклудах есть периферия (ADC\GPIO итд) но нет ничего с ядра

в) Есть CMSIS обертка для FreeRTOS \Middlewares\Third_Party\FreeRTOS\Source\CMSIS_RTOS/

г) Есть FreeRTOS и без CMSIS обертки \Middlewares\Third_Party\FreeRTOS\Source\include

д) Есть HAL \Drivers\STM32F4xx_HAL_Driver\Inc. В этих инклудах есть периферия (ADC\GPIO итд) и ядро (stm32f4xx_hal_cortex.h)

е) А вот сгенеренный CubeMX \Inc\main.h содержит микс CMSIS и HAL.

  #define LD5_Pin GPIO_PIN_14 - ссылка на HAL

  #define B1_GPIO_Port GPIOA - ссылка на CMSIS

-------------------------------------------------------------------------

Вопросы появились такие:

1) Достаточно ли CMSIS библиотек (пп.а), б), в)) для использования и ядра и периферии STM32 совместно с  FreeRTOS?

2) Достаточно ли HAL библиотек (пп.д)) для использования и ядра и периферии STM32 совместно с  FreeRTOS (п.г))?

3) Зачем CubeMX замешал CMSIS и HAL? Имеет ли смысл такой микс?

4) Если STM32 имеет свою "не стандартную" (писанную под конкретный микроконтроллер) библиотеку CMSIS (п.б)), то есть ли смысл говорить об универсальности и переносимости кода?

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

 

Для тех кто операционку под голое ядро пишет может только и есть смысл работать в CMSIS.

Если делать вызовы операционки через CMSIS (п.г)), то при замене операционки (на uOS) эти вызовы не изменятся...

 

Share this post


Link to post
Share on other sites
6 часов назад, topor_topor сказал:

До сих пор не понятен один момент - как соотносятся CMSIS и HAL  библиотеки?

CMSIS изобретение ARM - читать здесь, вот как раз Silicon Vendor на картинке это HAL от STM.

Share this post


Link to post
Share on other sites
7 hours ago, topor_topor said:

1) Достаточно ли CMSIS библиотек (пп.а), б), в)) для использования и ядра и периферии STM32 совместно с  FreeRTOS?

Да, тут многие так живут, используя описание регистров ядра + периферии и свои велосипеды.

 

7 hours ago, topor_topor said:

 2) Достаточно ли HAL библиотек (пп.д)) для использования и ядра и периферии STM32 совместно с  FreeRTOS (п.г))?

Это модный подход, который STM последние лет 5 активно продвигает. Проблема в том, что в нестандартных случаях (шаг в сторону от примера) этот HAL может сломаться. Чинить его (попутно полностью разобравшись, как он устроен) или выкинуть целиком - личное дело каждого, на форуме холивары ежемесячно поднимаются. И HAL построен на описании регистров из CMSIS, они не стали делать точно такое же, но с перламутровыми пуговицами. Соответственно, внутри HAL'а есть CMSIS, и он периодически "торчит" наружу.

7 hours ago, topor_topor said:

4) Если STM32 имеет свою "не стандартную" (писанную под конкретный микроконтроллер) библиотеку CMSIS (п.б)), то есть ли смысл говорить об универсальности и переносимости кода?

Насколько я понимаю, у ARM'а когда-то была благая идея "мы сделали одинаковое ядро, а вы, производителе чипов, сделайте универсально-одинаковые драйвера периферии". Идея не взлетела, рекламный слоган "у нас точно такое же, как у всех" работает плохо :-)

Share this post


Link to post
Share on other sites

Спасибо за ответы.

Действительно HAL использует CMSIS, т.е. он надстройка над CMSIS. Например:

#include "stm32f4xx.h" // <- CMSIS

void HAL_NVIC_DisableIRQ(IRQn_Type IRQn)
{
  /* Check the parameters */
  assert_param(IS_NVIC_DEVICE_IRQ(IRQn));
  
  /* Disable interrupt */
  NVIC_DisableIRQ(IRQn); // <- CMSIS
}

================================================================

Подскажите пожалуйста какой API используют драйверы которые генерит CuebMX? Напр. USB, Eth.

Как я вижу в "usbh_conf.h"  используется микс HAL и CMSIS:

// В "usbh_conf.h" есть инклуды с HAL & CMSIS
#include "cmsis_os.h"
#include "stm32f4xx.h"
#include "stm32f4xx_hal.h"
  
// Есть вызовы HAL ("usbh_platform.с")
HAL_GPIO_WritePin(GPIOC,GPIO_PIN_0,(GPIO_PinState)data);

// Есть вызовы CMSIS ("usbh_core.с")
osThreadDef(USBH_Thread, USBH_Process_OS, USBH_PROCESS_PRIO, 0U, USBH_PROCESS_STACK_SIZE);

Зачем использовать микс ?

Похоже что на уровне ядра (usbh_core) пишется платформенно независимо с использованием CMSIS, а при переходе к конкретному микроконтроллеру (usbh_platform) уже с использованием HAL.

В результате USB надо использовать по-любому через HAL.

Выходит нет смысла использовать CMSIS (а это немного сложнее) так как нужные драйвера всё равно в HAL....

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this