[jenya7 0]

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

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

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

Изменено 29 ноября, 2015 пользователем Jenya7

[Allregia 9]

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

 

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

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

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

[jenya7 0]

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

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

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

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

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

Изменено 29 ноября, 2015 пользователем Jenya7

[Bloom 0]

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

[yanvasilij 0]

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

 

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

[x893 35]

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

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

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

 

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

 

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

[makser1 0]

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

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

Изменено 24 апреля, 2016 пользователем makser

[x893 35]

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

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

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

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

[zltigo 0]

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

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

[x893 35]

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

 

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

[alexp74 0]

Ковырял 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 не нашел требований по задержке...

[topor_topor 0]

Только начал изучать 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) эти вызовы не изменятся...

 

[HardEgor 64]

6 часов назад, topor_topor сказал:

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

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

[esaulenka 5]

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'а когда-то была благая идея "мы сделали одинаковое ядро, а вы, производителе чипов, сделайте универсально-одинаковые драйвера периферии". Идея не взлетела, рекламный слоган "у нас точно такое же, как у всех" работает плохо :-)

[topor_topor 0]

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

Действительно 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....