Seperating the STM32 variants according to their product range (STM32F0, F1 etc)

Development of new Cores using the STMCubeMX and HAL
User avatar
Vassilis
Posts: 313
Joined: Thu May 21, 2015 6:42 am
Location: Thessaloniki, Greece
Contact:

Seperating the STM32 variants according to their product range (STM32F0, F1 etc)

Post by Vassilis » Sat May 14, 2016 5:36 pm

It is known that there is a large range of STM32 devices (STM32L0, L1, L4, STM32F0, F1, F2,..,F7) according to their features.
For that reason the ST categorized the STM32Cube libraries with different names STM32CubeL0, STM32CubeL1,...,STM32CubeF7.

I have been thinking that maybe its is a good idea to separate the HALMX variants in categories just like the STM32duino does. Instead of using the generic HALMX folder that includes the whole variants I would suggest each STM32 range (F0, F1 etc) to exists in a dedicated folder.
For example instead of using the generic HALMX folder we could use the folder HALMX_F0 for all STM32F0 MCUs, the folder HALMX_F1 for all STM32F1 MCUs etc.

What do you say about it ?

User avatar
Slammer
Posts: 247
Joined: Tue Mar 01, 2016 10:35 pm
Location: Athens, Greece

Re: Seperating the STM32 variants according to their product range (STM32F0, F1 etc)

Post by Slammer » Sat May 14, 2016 6:23 pm

This idea is correct...
Furthermore, I think the correct way is to use directly the HAL source inside every directory (F0,F1, etc). Every variant in the same family must use the same files of HAL. The CubeMX is something more, is the initialization code generator on top of HALMX. Normally, every variant must have a board.c or variant.c with the specific code for the corresponding variant. Think of HALMX as a low level API like libopencm3 or libmaple, and the CubeMX files as the minimum initializing procedure.

User avatar
GrumpyOldPizza
Posts: 181
Joined: Fri Apr 15, 2016 4:15 pm
Location: Denver, CO

Re: Seperating the STM32 variants according to their product range (STM32F0, F1 etc)

Post by GrumpyOldPizza » Sat May 14, 2016 7:49 pm

Vassilis wrote:It is known that there is a large range of STM32 devices (STM32L0, L1, L4, STM32F0, F1, F2,..,F7) according to their features.
For that reason the ST categorized the STM32Cube libraries with different names STM32CubeL0, STM32CubeL1,...,STM32CubeF7.

I have been thinking that maybe its is a good idea to separate the HALMX variants in categories just like the STM32duino does. Instead of using the generic HALMX folder that includes the whole variants I would suggest each STM32 range (F0, F1 etc) to exists in a dedicated folder.
For example instead of using the generic HALMX folder we could use the folder HALMX_F0 for all STM32F0 MCUs, the folder HALMX_F1 for all STM32F1 MCUs etc.

What do you say about it ?
Why not having a structure like this:

core/HALMX
system/CubeL0
system/CubeL1
system/CubeF0
system/CubeF1

and so on ,,,

I think the descision over which HAL to pull in can be made via command line define via "platform.txt" and "boards.txt". The Cube[FL][012347] code could be precompiled as a library, so that each sketch would recompile only the minimum.

The per board CubeMX code lives in variants/<XZY>/variant.cpp anyway.


If you switch back to a separate core per HAL, what is the point of using the HAL to begin with ? Wasn't the motivation to have a common source base for all STM32 MCU ?

User avatar
RogerClark
Posts: 6917
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Seperating the STM32 variants according to their product range (STM32F0, F1 etc)

Post by RogerClark » Sat May 14, 2016 9:00 pm

I think the motivation for using the HAL was for several reasons

* To support different series processors e.g F2,F3 F7 and L series etc, without having to write all the low level code by hand (like leaflabs had to do a lot in libmaple)

* To use official STM code as the underpinnings, which means we get official bug fixes when the Cube is updated ( albeit we have to re-export for every core)

* Give users the ability to call the standard HAL functions, rather then the leaflabs API to the hardware, as this would allow people to use all the official example code etc

* Use STMs own USB drivers e.g. for CDC etc, so we don't have to use libwdi to install the Windows driver.
One caveat with the USB drivers is that I think we should switch to using a composite device, preferably as sooner rather than later, even if it just contains one sub device, as we should have the ability to add HID and other devices (like the Arduino Leonardo etc have)
But I don't know if there is an official STM composite driver (Vid PID) that we can use.

User avatar
Vassilis
Posts: 313
Joined: Thu May 21, 2015 6:42 am
Location: Thessaloniki, Greece
Contact:

Re: Seperating the STM32 variants according to their product range (STM32F0, F1 etc)

Post by Vassilis » Sat May 14, 2016 9:23 pm

Roger do you suggest to keep all variants in one folder as it is now ?

User avatar
RogerClark
Posts: 6917
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Seperating the STM32 variants according to their product range (STM32F0, F1 etc)

Post by RogerClark » Sat May 14, 2016 9:46 pm

Vassilis

I think the repo is likely to get very big if each board has a complete copy of the HAL files, but I don't know if its practical to separate it in the way that has been suggested.

I don't know if the HAL core that is exported for the L0 would be the same as for the F7

The way @sheepdoll has structured the files is the safest, but probably has a lot of duplication.

However until we try to build some completely different cores, E.g. L0 of F7, I dont think it will be possible to decide the best way to structure the repo.


Also, on a related topic.
I have been looking at building a board manager package for the F1, and it is possible to write a script that just extracts one core from the repo and packages it.

So one option would be to have separate board manager packages for the different series ( albeit this would be a lot of separate packages), which would help with the duplication, as end users would not be downloading the whole repo with every single variant

User avatar
ekawahyu
Posts: 107
Joined: Wed Apr 13, 2016 6:17 am

Re: Seperating the STM32 variants according to their product range (STM32F0, F1 etc)

Post by ekawahyu » Tue May 24, 2016 10:31 pm

Has anyone started to work on this separation? How does the new structure look like? I have at least F0, F1, F4, and L0 platforms with me that I can test it with.

I can imagine the whole process of porting to new platform/board would look like this:
  1. Generate the code using STM32CubeMX
  2. Add setup() and loop() in the main.c
  3. Add chip.h, variant.h, variant.cpp
  4. Remove Drivers and Middlewares folders, the final built will need to link to a library (libf0.a, libf1.a, etc)
  5. All source code for CMSIS, STM32Fxx or Lxx reside in a new drivers folder ---> build partially as needed
As for the structure I propose, it should look like:

Code: Select all

____ cores
   |     |_ mapleMX
   |_ drivers
   |     |_ CMSIS
   |     |_ STMF0xx_HAL_Driver
   |     |_ STMF1xx_HAL_Driver
   |     |_ STMF2xx_HAL_Driver
   |       .
   |       .
   |     |_ STM32_USB_Device_Library
   |_ libraries
   |_ variants
   |     |_ MX<blabla>
   |           |_ Inc
   |           |_ Src
   |           |_ SW4STM32
   |           |_ chip.h
   |           |_ variant.h
   |           |_ variant.cpp
   |_ boards.txt
   |_ platform.txt
Let me know your opinion or concern.

User avatar
sheepdoll
Posts: 236
Joined: Fri May 22, 2015 12:58 am
Location: Silicon Valley Vortex
Contact:

Re: Seperating the STM32 variants according to their product range (STM32F0, F1 etc)

Post by sheepdoll » Wed May 25, 2016 3:11 am

A lot of the way it is currently structured is to take advantage of the way Cube stores the files. Most of this is automatically generated.

One idea that I had would be to use git where each variant is a branch. That way if you want to work on F1 then you check out the F1 branch. Work on F4 then check out the F4 branch. Each variant folder has a .ioc file in it. The distribution would NOT have the actual HAL code. This would be generated by the user/configurator for the board that they want to use.

There would also be a second script. This might be a plug in to Cube. I need to talk to the contact I made at Maker Faire to see if this is even possible. In the present time, I will probably write it in postscript to test the concept. This script reads the .ioc file Modifies main to add setup() and loop() and creates the variant.cpp and variant.h file using the choices the user made in the Cube tool. This script would also need to touch boards.txt and possibly platform.txt.

It might be that only board creators use these scripts to set up a generic board. Gets a bit messy. There are no standard Arduino pin number to STM pin number thingys. The Nucleo and the F0 SPL libraries use the same mapping. This mapping is more for a 'R" package. Most of the maples use a 'C' package. The OTTO is going to add even more confusion.

If the Arduino IDE is going to better support ARM, they they really need to use a real makefile system and dynamic libraries that do not get loaded unless needed. I am working on getting a 3rd party LCD library working and it compiles all the wiring and bit banged I2C just in case the user might want to call it.

stevech
Posts: 441
Joined: Thu Aug 27, 2015 6:32 am

Re: Seperating the STM32 variants according to their product range (STM32F0, F1 etc)

Post by stevech » Wed May 25, 2016 3:29 am

Arduino is rooted in the AVR which didn't have alternate functions on chips' pins. Then mapping a given chip pin to a board pin is an Arduino notion that adds more inflexibility yet, unless you are using Arduino's own boards.

Is it even possible to use Arduino concepts for pin names, with fixed functions on each pin, whereas CubeMX allows GUI based pin mapping of about 8 chooseable functions per pin. Plus GUI input of all the setup parameters for the chosen function per pin (such as GPIO speed, pullups, or Timer period, or Capture timer DMA yes/no, and so on and so on). Seems incompatible with Arduino's concept where any given board named X has a fixed pin mapping.

As you know, once you use CubeMX or CubeFn to generate alternate function choices for used MCU pins, and their device parameters, Cube spits out all the initialization code, ISRs, system clock/PLL, bus clocks, etc., and an empty main(); Your work then focuses on the app and the HAL library API document, not hacking I/O stuff.

It would seem to me that user contributed code would be middleware, as are the HAL compatible FATFS, SDIO, LCD, FREE_RTOS, etc. Most all on-chip I/O functions, UARTs, SPI, SDIO, I2C, and their drivers, are in the HAL libraries, not considered user middleware.

User avatar
RogerClark
Posts: 6917
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Seperating the STM32 variants according to their product range (STM32F0, F1 etc)

Post by RogerClark » Wed May 25, 2016 4:35 am

Re: Using Alternative pin config's

I'm not sure if we need to use this feature

I understand why its a handy thing to have, but I think if you want that level of configurability...
You should probably either use the cube code directly (not Arduino API layer at all)
Or, you should make your own board variant that has the Alternative pin mapping you want.

Re: Use of Arduino Pin numbers

I now only use STM32 style port/pin numbers e.g. PA11, but there is nothing to stop us using an array of pins and enums like libmaple does, so that boards like the Maple mini can be used without referencing the numbers printed on the board back to the STM port / pin version.


Re: Structure of codebase

I've not had time to look at this, but as I've previously said... I don't think we've built enough variants yet to know how much code is common.

e.g. I noticed someone posted about how the F03 had different param's in one part of the code, and I know the F4 has different peripheral speed settings to the F1

So it could be that we do need a lot of code duplication, and perhaps @sheepdoll's suggestion of different github branches, is one way to handle this without appearing to have a massive code base. (i.e so you can just choose which branch you want to download the zip file of)

But I wonder how much work it would then be to keep all the common code up to date, as I'm not sure if its possible to use git merge for this ( I suspect not), and I use a git submodule for the common code only works for people who clone the repo recursively, and not for anyone who just downloads the zip, as github does not include submodules in the zip :-(

Post Reply