[En-Nut-Discussion] STM32 support

[Thiago A. Corrêa]

Hi Uwe,

     It would be of great help if you could upload to github. I have found
some python scripts in the NutOS repository for the pin configuration, but
I guess the F4 is being considered the 100 pin version while I'm using the
144 pin version. Not sure how it chooses which one to generate for.
     Let me know when it would be better for you for an online talk.

Thanks,
     Thiago A. Correa



On Sat, Mar 4, 2023 at 8:16 AM Uwe Bonnes <
bon at elektron.ikp.physik.tu-darmstadt.de> wrote:

> >>>>> "Thiago" == Thiago A Corrêa <thiago.correa at gmail.com> writes:
>
>     Thiago> Hi, How could I get stared with STM32? I'm trying to build
>     Thiago> for STM32F407ZE but I'm usually met with an invalid nutbld
>     Thiago> where make complains on arch about invalid path. It looks
>     Thiago> like the generated makefile doesn't reference the the arch
>     Thiago> c source files.  Trying to use the compiler from
>     Thiago> STM32CubeIDE which is installed in a very awkward path
>     Thiago> inside Eclipse plugins.
>
> Dear Thiago,
>
> a lot of my STM32 work has probably not yet got upstream. E.g. there
> are python scripts that get pin mapping files from the STM data
> base. In the end I use it like e.g.
> ...
> #include PINMUXHEADER
> ...
> #define TIM2_CH1_AF PINMUX(PA00, TIM2_CH1_FUNC)
> #if TIM2_CH1_AF == AF_NO_SUCH_PINFUNC
> # warning BAD TIM2_CH1_AF assignment
> #endif
>
> If you want, I can upload my git tree to my github account. Maybe we
> should have a Zoom talk, solve problems when other people use that
> tree.
> You know my definition of program usability:
> 1. It should work
> 2. It worked for me
> 3. It works for me
> 4 It works
>
> As I did other things the last time, I think the tree is at about
> stage 2.5 :-)
>
> Using a single pin designator as "PA00" against  the two
> designators PortA and Pin 0 allowed a lot more header and configurator
> magic.
>
> As I work for several families I use different build approch, only in
> user space.
> <base firectory>: Containg all the projects and a common makefile to
> build the libs
> <project directory>: Containing the user code and the application
> Makefile
> <target build directory>: Containing the Makefile
> ====
> export BOARD ?= $(shell basename $(CURDIR))
>
> include ../../Makefile.lib
> ====
> and a local build of the directory. A simple make here will build the
> application and the code
>
> This results in a tree like
> en_apps/Makefile.lib
> en_apps/socketserver/
> en_apps/socketserver/Makefile.app
> en_apps/socketserver/socketserver.c
> en_apps/socketserver/nucleo_f767zi/
> en_apps/socketserver/nucleo_f767zi/Makefile
>
> Compiling for another supported STM32 board would mean to only create
> en_apps/socketserver/f4_discovery
> and copy the makefile from en_apps/socketserver/nucleo_f767zi/Makefile
>
> Feel free to ask more, but I am mostly on the road this weekend.
>
> Anybody at embedded world in Nürnberg?
>
> Bye
>
> --
> Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>