Not sure about recent progress but IIRC Duc Doan (cced) is also using
STM provided HAL for his work on GPIO driver for F4 BSP. Please see [1]
and [2].
If however you consider HAL to be too heavy weight solution, perhaps you
may have a look into STM provided LL (low-layers drivers) API? This
should be more light weight low level API but with less portability.
Please see UM1786[3].
Important question here is also a question of licensing. Last few
releases of at least H7 HAL were done under Apache 2.0 license. F4 seems
to be the same case and I would bet F3 would be same too. I mention that
as RTEMS developers still need to kind of discuss Apache 2.0 licensed
code in the project. Opinion were still not settled before summer
holidays break but I do not know if there is any movement on this front.
Thanks,
Karel
[1]: https://devel.rtems.org/wiki/GSoC/2022
[2]: https://medium.com/@dtbpkmte
[3]:
https://www.st.com/content/ccc/resource/technical/document/user_manual/a6/79/73/ae/6e/1c/44/14/DM00122016.pdf/files/DM00122016.pdf/jcr:content/translations/en.DM00122016.pdf
On 9/10/22 18:20, Y. HB wrote:
I have seen in rtems 6.0, there are two stm32 families: stm32f4 and stm32h7
The former one uses custom code to set up BSP, while the latter one uses
the ST provided HAL lib to set up BSP.
Now I need to add a BSP for stm32f3, which is very different (reg
layout) from stm32f4.
To add stm32f3 BSP as the stm32f4 approach is tedious and error prone,
but slim codebase,
the stm32h7 way has full capabilities provided via ST HAL, but may be
too bloat if many stm32 families being added into source tree.
So what is your suggestions? Which is a preferable way ?
Thanks
_______________________________________________
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
_______________________________________________
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
