STM32: регистровый CMSIS или высокоуровневый HAL ?, ПРосто выскажите аргументы за или против, пожалуйста, без холивара Опции

[Jenya7]

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

Сообщение отредактировал Jenya7 - Nov 29 2015, 12:25

[Allregia]

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

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

[Jenya7]

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

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

Сообщение отредактировал Jenya7 - Nov 29 2015, 17:04

[Bloom]

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

[yanvasiij]

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

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

[x893]

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

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

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

[makser]

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

Сообщение отредактировал makser - Apr 24 2016, 10:59

[x893]

Мне по барабану регистры, SPL, HAL - у меня код аппаратной занимает максимум 5% от всего кода (обычно 1-2%).
Вообще непонятна цель этих дискуссий.
Просто делать нечего в деревне - бабки выходят и начинают ни о чем говорить.
Хотя они при деле и время проходит незаметно.

[zltigo]

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

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

[x893]

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

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

[alexp74]

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