Makefile structure for stmhal

[marfis]

I saw that in a recent commit that the hal/cmsis subdirectory were preprared for a STMF2xx port. That's good news towards a better variety of (STM-)ARM targets..

I'm working on a port to a STML151 target (also cortex M3 based) and have some code running (python shell on UART). Yet I was wondering how to best integrate it into the existing stmhal file/build structure.

For example, the makefile has hardcoded CFLAGS_CORTEX_M4 flags, which obviously are different for a cortex M3 CPU... Yet I'd like to integrate my changes into the stmhal directory rather than into a (yet another..) build folder.

So I'd like to raise a discussion if a new structure of the stmhal build target might be useful in order to simplify the ports to a different ARM CPUs

The approach I'd would have taken was to separate host specific compiler switches into sub-mak files that each platform can implement individually. For example, each platform (board) would specifiy "CFLAGS_HOST" that will be included by the master makefile in the stmhal root.

As most of the boards currently supported are using the F4 CPU there might be an option to group it to something like:

Code: Select all

-stmhal
  - boards
    - F4based
      - PYBOARD
      - HYDRABUS
      - ...
    - F2based
    - L1based

in each "..based" directory would be the location of the submakefile mentioned above.

For memory constraint systems, I'd also include the possibilty to configure the USB subsystem (e.g. only supporting CDC profile) in that makefile.

Anyway is this idea completly way off or what do people think?

[dhylands]

I think I'd be inclined to do things a little differently.

I like the fact that you don't need to know which type of processor a given board uses.

Currently, it looks like the mpconfigboard.mk file inside each board directory already has an MCU_SERIES macro.

So, one simple approach would be to do something like changing the name of CFLAGS_CORTEX_M4 to be CFLAGS_CORTEX_f4 and then use $(CFLAGS_CORTEX_$(MCU_SERIES))

Then the stmhal makefile would define each of CFLAGS_CORTEX_f4/f2/f7 etc. I just got my STM32F7 discovery board to play with (which is why I mentioned f7)

If we need more than that then we could create makefile snippets which go in the boards directory or something.

[marfis]

Thanks for the feedback.

I like the fact that you don't need to know which type of processor a given board uses.

Thats fair enough.

The benefit I see that it would give a certain structure that would indicate which performance level each board might have. And it would be synchronised with the separation in the hal directory. There is another benefit I've outlined below.

Currently, it looks like the mpconfigboard.mk file inside each board directory already has an MCU_SERIES macro.

Yeah - I saw that it was introduced the same time as the other separation with the hal files.

So, one simple approach would be to do something like changing the name of CFLAGS_CORTEX_M4 to be CFLAGS_CORTEX_f4 and then use $(CFLAGS_CORTEX_$(MCU_SERIES))

I like that.

If we need more than that then we could create makefile snippets which go in the boards directory or something.

Yes - hmmm. Thinking of it - it would maybe break with the compiler switch approach (compiler switches in the mpconfigboard.h / mpconfigport.h select the features). Otherwise we end up in rearranging everything which of course I have no intention I kind of like the way the makefile is written. There is also PREFIX_FILE but I think that is already pretty generic.

Beside the makefile I see another problem in the mpconfigport.h file mainly, with the MICROPY_PY_xxx switches.

I'd like to selectively disable flash/ram intensive features for my port hence I think it should be in the boards directory. This would be another advantage of having the f4based / f3based subdirs because you could move this file there.

So I'd like to use $(CFLAGS_CORTEX_$(MCU_SERIES)) as you have proposed. And move the mpconfigport.h into the boards directory perhaps.

I'm not sure how damian thinks of it but he has already taken steps towards a separation of f2/f4 devices and maybe he's not against a further separation

[dhylands]

I've done some of that already. I have my M7 board booting to a UART REPL.

You can see what I've done so far here:
https://github.com/dhylands/micropython ... f7-support

This commit assumes that the f7 hal & cmsis files exist and has all of the other changes I did to bring up the f7
https://github.com/dhylands/micropython ... 556b99cd0c

It's not quite ready to do a PR, I need to fix up the hack I did for i2c and spi.

[Damien]

Yes definitely it would be good to support all STM32 series MCUs in stmhal, or at least all those MCUs that are supported by the ST Cube HAL library.

I don't think we should separate the boards into F4based, F2based, etc. I think the directory hierarchy is good as it is, and you shouldn't need to know the MCU series to know the board.

We can use mpconfigboard.mk to configure all Makefile-related variables for a given board. If lots of things become common to a given series, then we can add boards/Makefile.f4, boards/Makefile.f2, etc files (as Dave suggests) which can then be included in a given board's mpconfigboard.mk if you want to use these common defaults.

mpconfigport.h should stay in stmhal/. Then you should use stmhal/boalds/MYBOARD/mpconfigboard.h to override any settings (eg disable floating point). To that end we should make stmhal/mpconfigport.h more like py/mpconfig.h in that it checks to see if a macro is defined, and only defines it if it's not already.

[marfis]

To that end we should make stmhal/mpconfigport.h more like py/mpconfig.h in that it checks to see if a macro is defined, and only defines it if it's not already.

Got the picture.

If lots of things become common to a given series, then we can add boards/Makefile.f4, boards/Makefile.f2, etc files (as Dave suggests) which can then be included in a given board's mpconfigboard.mk if you want to use these common defaults.

Ok fine.

Do you think there is a way to configure the USB support for different boards? Overriding the SRC_USBDEV filelist maybe in one of the sub-makefiles? Or even the SRC_LIB filelist? I believe that these options should be configurable for a board with less RAM/FLASH.

Then maybe, even a "minimal-stm" board example would be nice to have (maybe based on the pyboard HW?), just to see where the lower limit would be (similar to the "minimal" target outside the stmhal).

[dhylands]

I ran into some of the USB issues when I was bringing up the M7.

I think that building micropython with no USB support is a valid way to do things, but it currently isn't supported.

The way that this is typically done is that we always include the .c file, and we put #ifdefs in the c file. An example of this is in: https://github.com/micropython/micropyt ... /can.c#L41

So we should probably have a MICROPY_HW_ENABLE_USB_DEV or something like that, and figure out all of the places it needs to go.

[Damien]

The network drivers are conditionally compiled by the Makefile itself, and the variable is set in mpconfigport.mk. We can do something similar for USB device.

If some ports want a stripped down version of USB (eg serial only) then we can use #if for that.

[marfis]

I ran into some of the USB issues when I was bringing up the M7.

Yes - It is really hard to separate common usb code and port specific staff with the STM hal.

So to expand the discussion a bit:
What do people think about STM's HAL code quality? My view is that it is... well crap.

It is such a pity the HAL library is not written in a clean way. And it does complicate the build structure for a different ARM architectures.

During the porting of the Cortex M3 MCU my effort was mainly spent on HAL related issues (USB staff, UART staff, Clock setup you name it). Ok - I'm more familiar with MSP430 series than ARM but I do think that this shouldn't be so complicated. I don't like to fill out a large struct just to switch a port pin to input. The code size it generates for a simple USB HID/CDC example is staggering. uPy core in comparision compiled always flawlessly...

Yesterday I had a look on the libopencm3 library http://libopencm3.org. This library has a much better and cleaner interface than STM's Hal - my opinion. It's LGPL3 licensed, but that shouldn't be a problem if you link the library. A simple CDC example compiles with less then 6kB of Code and I was able to run it on my custom made board with no problem. The f4 port seems to be well maintained.

I think due to the positive experience I've had so far, I'm going to use that library rather than stmhal. It will mean to rewrite most mp_hal related things but I think it is more satisfiying than using a crappy hal API.

What are peoples opinion about that issue?

[dhylands]

Yesterday I had a look on the libopencm3 library http://libopencm3.org. This library has a much better and cleaner interface than STM's Hal - my opinion. It's LGPL3 licensed, but that shouldn't be a problem if you link the library. A simple CDC example compiles with less then 6kB of Code and I was able to run it on my custom made board with no problem. The f4 port seems to be well maintained.

Unfortunately, micropython is licensed under the MIT license which precludes static linking of LGPL3 source code, which means that we can't use LGPL3 source for the embedded processors.