jenya7 0 29 ноября, 2015 Опубликовано 29 ноября, 2015 (изменено) · Жалоба лично мои впечатления. ни с STM32 ни с HAL ни с SPL раньше интенсивно не работал. так сделал пару несложных проектов. работал напрямую с регистрами. и тут понадобилось заточить проект на STM32. собирал проект на HAL. два дня собирал. собрал таки. дошел до функции HAL_SPI_TransmitReceive. тихонько перешел на SPL. собрал проект за пол часа целуя в его небритые щеки (или что там у него есть). все что имею сказать по этому поводу. Изменено 29 ноября, 2015 пользователем Jenya7 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Allregia 9 29 ноября, 2015 Опубликовано 29 ноября, 2015 · Жалоба собирал проект на HAL. два дня собирал. собрал таки. дошел до функции HAL_SPI_TransmitReceive. тихонько перешел на SPL. собрал проект за пол часа целуя в его небритые щеки Это конечно все хорошо, я сам SPL пользую (в основном для первичных нициализаций, а где надо скорость - там напрямую в регистры). Но у меня наклевывается проект на STM32F7, и насколько я помню - для него SPL нет, а только HAL. Что очень жаль, поскольку этот проект переводится со старого SPL-проекта на STM32F4. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jenya7 0 29 ноября, 2015 Опубликовано 29 ноября, 2015 (изменено) · Жалоба Это конечно все хорошо, я сам SPL пользую (в основном для первичных нициализаций, а где надо скорость - там напрямую в регистры). Но у меня наклевывается проект на STM32F7, и насколько я помню - для него SPL нет, а только HAL. Что очень жаль, поскольку этот проект переводится со старого SPL-проекта на STM32F4. я думаю можно поменть регистры в SPL функциях на свои. логика то понятна. лично я с HAL связываться не буду. ну если только будет для примера рабочий отлаженный проект. на крайний случай - работа с регистрами. ничего страшного. Изменено 29 ноября, 2015 пользователем Jenya7 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Bloom 0 7 декабря, 2015 Опубликовано 7 декабря, 2015 · Жалоба Я в проектах часто использую Chibios и, соотвественно, его HAL. Сейчас его отвязали от ядра RTOS, и можно пользоваться им отдельно. На мой взгляд, получилось очень даже неплохо. Поддерживает только самое основное, если что-то нужно подкрутить под капотом, то можно и с регистрами поработать. Размер маленький получается за счет черной магии макросов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yanvasilij 0 16 апреля, 2016 Опубликовано 16 апреля, 2016 · Жалоба Добавлю свои пять копеек. Как мне кажется использование SPL или HAL обосновано, особенно при смене процессора. В одной руке даташит, в другой сгенерованный код, немного упорства и быстро начинаешь понимать, как работать с периферией. Если там и есть какие сложности или баги, то тут, на мой взгляд все просто, один раз наткнувшись на них достаточно посидеть и поковырять "потроха". После этого начинаешь прекрасно ориентироваться в исходниках и делать на этом процессоре один проект за другим. Тем более, что на STM32 не так уж и сильно эта периферия различается от процессора к процессору. Что же касается непосредственно HAL, то, лично мне кажется, в своем стремлении абстрагироваться от регистров и низкоуровневой работы с периферией разработчики HAL переборщили. Вроде как теперь и reference manual то читать не надо (точнее похоже на то, что этого хотели добиться), но с другой стороны теперь надо читать код HAL или доку на него (кто что предпочитает). В свою очередь чтобы хорошо ориентироваться в SPL нужно все же обращаться к reference мануалу, поскольку многие типы и макроопределения введенные там непонятны без прочтения документации на проц. Но опять же и в том и другом случае разобраться то надо всего ОДИН раз, потом спокойно работаешь не заботясь о периферии. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x893 60 16 апреля, 2016 Опубликовано 16 апреля, 2016 · Жалоба C HAL просто начать, но там нет нужных функций. Для их реализации надо написать немного кода, но в их идеологии. А она немного кривовата. Если посмотреть на более популярный mbed - там немного сложнее и еще более корявее. а с переходом на mbedos и yotta - стало просто мозголомкой. Но если не выходить за рамки - почти как в arduino (а это устраивает 95% "разработчиков" :)). Я использую все известные библиотеки и никаких проблем с выбором нет вообще. Что надо использую, что не надо - удаляю и делаю своё. Если функции инициализации делается один раз - мне все равно как она сделана, если правильно работает. Хоть на суахили. Если надо иметь кольцевой буфер, а его нет в HAL - то просто пишется нужный код. Хоть в регистры напрямую, хоть через SPL/HAL/libSTM32 и еще через что угодно. Но всегда проще написать свою реализацию (хотя иногда она и не так красива как результат труда других людей). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
makser1 0 24 апреля, 2016 Опубликовано 24 апреля, 2016 (изменено) · Жалоба Я свои проекты делаю на SPL, потеря в тактах и байтах минимальна (давно тестил - буквально 1-2%). Сейчас переход на stm32f7 осложняется отсутствием оного для этих чипов. HAL действительно монстроподобен и похоже парой процентов потерь не обойдется. Насчет SPL для stm32f7, есть такая мысль - судя по даташитам F7 включает в себя F4 с некоторыми новыми наворотами, т.е. по идее можно использовать SPL от F4 для F7. Осталось попробовать перенести ее. Изменено 24 апреля, 2016 пользователем makser Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x893 60 24 апреля, 2016 Опубликовано 24 апреля, 2016 · Жалоба Мне по барабану регистры, SPL, HAL - у меня код аппаратной занимает максимум 5% от всего кода (обычно 1-2%). Вообще непонятна цель этих дискуссий. Просто делать нечего в деревне - бабки выходят и начинают ни о чем говорить. Хотя они при деле и время проходит незаметно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 2 24 апреля, 2016 Опубликовано 24 апреля, 2016 · Жалоба Мне по барабану регистры, SPL, HAL - у меня код аппаратной занимает максимум 5% от всего кода (обычно 1-2%). Для того что бы угробить производительность, да и вообще превратить продукт в кучу дерьма, достаточно добавления и меньшего его количества. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x893 60 24 апреля, 2016 Опубликовано 24 апреля, 2016 · Жалоба Это легко сравнивается через DWT, таймером, профайлером и всегда можно выбрать оптимальный вариант. Да и умелым программированием можно производительность угробить без регистров/SPL/HAL. Нельзя всех сапожников заставить пользоваться одним типом молотка. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
alexp74 0 14 мая, 2016 Опубликовано 14 мая, 2016 · Жалоба Ковырял 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 18 марта, 2019 Опубликовано 18 марта, 2019 · Жалоба Только начал изучать 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 83 19 марта, 2019 Опубликовано 19 марта, 2019 · Жалоба 6 часов назад, topor_topor сказал: До сих пор не понятен один момент - как соотносятся CMSIS и HAL библиотеки? CMSIS изобретение ARM - читать здесь, вот как раз Silicon Vendor на картинке это HAL от STM. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
esaulenka 7 19 марта, 2019 Опубликовано 19 марта, 2019 · Жалоба 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 19 марта, 2019 Опубликовано 19 марта, 2019 · Жалоба Спасибо за ответы. Действительно 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.... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться