Do you have any complaints about headers stocked with STM packages? Are they incomplete?
Best regards. Peter Borisenko Awesome Technologies, Ltd. http://awsmtek.com +66826684211 On Tue, Sep 13, 2022 at 9:30 AM Y. HB <[email protected]> wrote: > Thanks for the info. I am working on stm32f302/303 devices. > > IMO, it would be better to use a script to generate corresponding BSP by > converting SVD files (https://github.com/posborne/cmsis-svd) > > On Mon, Sep 12, 2022 at 3:00 PM Peter B <[email protected]> wrote: > >> There some bugs and design flaws in the existing stm32f4 bsp discovered. >> I have fixed it locally as well as extended it a while (added pwm, uart, >> spi, can). But have no time to prepare it and make a pull request. I can >> share it with you if you want. >> >> One important thing is to not glue console and UART drivers together. I >> have separated it as console can work over USB, UART, Telnet and even SWO. >> >> I think it would also be great to reuse device support files (e.g. >> stm32f307x.h, etc.) provided by vendor and make a device selector option in >> build configuration (even if it will be only a single device). The original >> stm32f4 bsp was written and tested with stm32f407 but I use stm32f429. >> >> >> On Mon, Sep 12, 2022, 12:45 PM Y. HB <[email protected]> wrote: >> >>> Thanks for your great information ! >>> >>> On Sun, Sep 11, 2022 at 9:57 PM Karel Gardas <[email protected]> >>> wrote: >>> >>>> >>>> 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 >>>> > [email protected] >>>> > http://lists.rtems.org/mailman/listinfo/users >>>> >>>> _______________________________________________ >>> users mailing list >>> [email protected] >>> http://lists.rtems.org/mailman/listinfo/users >> >>
_______________________________________________ users mailing list [email protected] http://lists.rtems.org/mailman/listinfo/users
