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 ?
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.
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 ?
* 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.
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
I can imagine the whole process of porting to new platform/board would look like this:
- Generate the code using STM32CubeMX
- Add setup() and loop() in the main.c
- Add chip.h, variant.h, variant.cpp
- Remove Drivers and Middlewares folders, the final built will need to link to a library (libf0.a, libf1.a, etc)
- 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:
____ 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
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.
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.
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 
I’m not sure if we need to use this feature
I’m not sure if we need to use this feature
I’m not sure if we need to use this feature
I gave my Teensy away. Probably still have the second one around in a box somewhere. Nice little board but I objected to having to patch the IDE and that darn pop-up download tool is so cheesy… like muenster 
Paul is a decent enough dude, I’ve communicated with him a few times. But Paul is a hardhead, no compromise , do it my way kind of human… I can relate; but we clash.
Point of this whole Paul discussion? Honestly, I do not know.
But forgoing auto-generated code from Cube/HAL is a huge mistake. Impractical to reinvent AND debug all that is in the HAL.
My opinion is unchanged… IF the current github is going to have different models of ST’s STM32Fx” microcontrollers, then those boards should be capable of being programmed by the ArduinoIDE by board selection. Evolving feature and core support is OK, IMO. Now, I personally could care less of how the core materializes… by humans, by automated tools, or by a million monkeys.
I suspect 95% of this forum knows that ST has professional tools and that other IDEs can be used, but bashing the ArduinoIDE as inferior is crude … the comparison is an “apples and oranges” comparison. The trick, is to backport the essence of the professional IDE(s) created code back into open source core code to support the Arduino riding on top of GCC.
Ray
Here is why I am here:
- I have spent a lot of time in the past toying around with STM32F0, F1, F4 using their Standard Peripheral Libraries. I have ported codes to it like simple shell and various hardware driver support with a nicely written Makefiles. ST-Link, JLink, USB-ARM-OCD, you name it, I have them all supported for the flashers. All that sudden, the SPL has been discontinued and I had to move on with the HAL? That is hours of work in replacing SPL to HAL for multiple cores! So I found STM32duino.com and I thought if I could contribute something to work with all of you, then I can understand how the HAL work quicker then doing it myself.
- I have been fascinated with the growth of Arduino community and I also notice some haters. Some said that Arduino is not a “normal” programming language, has no multiple tabs, has no support for multiple source code writing, but that is Arduino! With its simplicity offered, still more people joining the club and write more library for it. I have to agree with Ray in this regard. Keep it simple because Arduino is Arduino. It is not for experts, it is for beginners. The way we do it for digital I/O is correct by naming it PA, PB, etc instead of keeping it as Arduino with numbers. I think we should do the same for analog pins.
- STM32CubeMX is just the tool for us to generate code faster for the lower levels. I have to disagree to provide only *.ioc for others instead of the full generated code out of it. For the last two weeks, I have been generating code with the exact same *.ioc but the generated code were not the same from time to time. What would happen if ST decided to move on to something else in the future and stop their support on STM32CubeMX? The same cycle would happen again, just like no more support for the SPL and we are all left with only *.ioc in our repositories.
- I design electronic boards for younger kids for their Makerspace. I use STM32 because it is affordable most schools can buy, and less expensive compared to getting only AVR on Uno. It has built-in DFU, no programmer is needed. If they decided to go advance, ST-Link is low cost and I already put Makefiles here and there to build, off of Arduino IDE. They could program and debug in Eclipse IDE for the exact same source code and the .ino
With that being said, I think we should keep the full libraries (probably as separates git submodules?, or whatever). We just need to build each variant against Drivers and Middlewares at their new location. That’s all. Providing a script to download libraries from ST is not an option. Because, I am afraid those HAL repositories on ST website might be disappeared some time in the future, just like the SPL did.
We are all expert in digging the STM32 code to the lowest level and that is not the main reason why we want to work on the support for the Arduino IDE. Arduino does not have the best IDE, but you may go and choose Eclipse as you wish. In my opinion, if you are capable enough to touch the lowest level, then you would probably choose other tools other than Arduino IDE. So, what is your reason doing this? What is your target in doing this?
<…>
