Bring in the ChibiOS HAL?

What could be included in further releases, or for the forum.
jcw
Posts: 171
Joined: Mon Oct 26, 2015 8:16 am

Bring in the ChibiOS HAL?

Post by jcw » Thu Oct 29, 2015 8:58 pm

Here's another idea / suggestion: bring the ChibiOS Hardware Abstraction Layer into the Arduino-STM32 project.

Plus: tons of STM32 chips and peripherals supported, actively developed, mature, well-organised code (IMO).

Minus: more code to bring in and learn, until it replaces existing stuff, i.e. more complexity before it gets better.

I'm not suggesting to expose ChibiOS in the IDE. Just to find out whether the ADC/PWM/I2C/SPI/NVIC/DMA/etc
implementation can be used for parts of the current code base. Perhaps initially to implement new features, but
ultimately to replace accumulated implementations which have diverged across the different variants.

ChibiOS (http://chibios.org/dokuwiki/doku.php) is a Real-Time OS. The HAL part of it has recently been made
completely independent (in release 3.0). It has a very flexible header/source/make/linker structure, allowing it to
support all the different architectures and variants without duplication. This is NOT a proposal to add the RTOS in.

By investing time in this setup, hopefully the Arduino-STM32 project can cover more bases, while doing less work.
I.e. more momentum by deferring the low-level details to those who have already created a good HAL infrastructure.

Maybe I'm pushing in the wrong direction with this, i.e. support for a wider variety of STM32 chips and boards, so
please take this for what it is: merely a suggestion, to feel the waters in this forum... such a change would take a
substantial amount of work.

User avatar
mrburnette
Posts: 1796
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: Bring in the ChibiOS HAL?

Post by mrburnette » Thu Oct 29, 2015 9:07 pm

jcw wrote:Here's another idea / suggestion: bring the ChibiOS Hardware Abstraction Layer into the Arduino-STM32 project.
<..>
Sheepdoll is working on abstractions for high-density STM32 chips that cannot be supported easily with the monolithic nature of Arduino core code.

But for the F103 medium density series, the forum is titled STM32duino, so my thinking is we stay with the core we have, improve it, add to it, but keep the Arduino feel about it. Maybe Sheepdoll or someone else (you maybe?) will make an abstraction for the F103 series. I say go for it, if you want. Even if you hit a brick wall down the road, the work should be very interesting and you should have some good experience.

For me, the Maple Mini is just fine the way it is.

Of course, I am not doing anything serious with the boards, I have like 30 of them because I hate to wait on the Chinese shipping lanes and they are so cheap.

Ray

stuartw
Posts: 36
Joined: Mon Jun 01, 2015 8:57 am

Re: Bring in the ChibiOS HAL?

Post by stuartw » Thu Oct 29, 2015 9:20 pm

Wouldn't including anything from ChibiOS create a bit of a licensing issue? These days you have to be extremely careful about licensing impacts when mixing projects, as we have seen in the wider community before it can be complex to say the least.

I do see however that the HAL section is Apache, which should make it reasonably simple, but whats the advantage of depending on that when the rest is not?

jcw
Posts: 171
Joined: Mon Oct 26, 2015 8:16 am

Re: Bring in the ChibiOS HAL?

Post by jcw » Thu Oct 29, 2015 10:05 pm

Ah, hadn't given the licensing part too much thought, I admit.
Apache with MIT should be ok, though?

The HAL is in itself very useful IMO, in that it addresses all the chip/peripheral variations.
I think all the STM32 chips are supported already - still some gaps, such as no ADC+DMA for every one.
But more than enough of the basics (DMA was never available on the ATmega chips anyway).

Again, it really all depends on the direction and focus of Arduino-STM32: specific STM32 boards, or generic?

User avatar
mrburnette
Posts: 1796
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: Bring in the ChibiOS HAL?

Post by mrburnette » Thu Oct 29, 2015 10:14 pm

jcw wrote: <...>
Again, it really all depends on the direction and focus of Arduino-STM32: specific STM32 boards, or generic?
Yes.
The interest in the STM32 has gone from the medium density to the high-density much faster than I had imagined. You have a good point and something I think Roger and the forum need to decide.

Ray

User avatar
martinayotte
Posts: 1213
Joined: Mon Apr 27, 2015 1:45 pm

Re: Bring in the ChibiOS HAL?

Post by martinayotte » Fri Oct 30, 2015 1:52 am

mrburnette wrote:The interest in the STM32 has gone from the medium density to the high-density much faster than I had imagined.
Hi Ray,
This is true, but maybe earlier than you though : I came to this forum (and even before on the arduino.cc long thread) because I had some F4 boards sitting around such my Netduino2Plus and my STM32F4Stamp. I've got those boards finally working with our current github. It is only during those early days that I've purchased some maple-mini clones to play with it.
Recently, one of my projects (commercial ones) was to migrate a previous LPC1768 design to STM32F405, same as above board. I've received the PCBs last week and working to migrate the LPC firmware I had made before.
Job done at 75%. I'm really happy ! More Flash, more RAM, more Arduino libraries instead of the ugly mBed dead support ...

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

Re: Bring in the ChibiOS HAL?

Post by sheepdoll » Fri Oct 30, 2015 1:57 am

jcw wrote: By investing time in this setup, hopefully the Arduino-STM32 project can cover more bases, while doing less work.
I.e. more momentum by deferring the low-level details to those who have already created a good HAL infrastructure.
The way I implemented the HALMX is fairly straightforward. It does however require reading the documentation which seems to be the main stumbling block to wider spread usage.

ST provides a tool called CubeMX, which automatically generates the mid level code. Most of the implementation is floating a processing/wiring API set above the HAL layer. This way the Arduino API can be used direct.

Scalability is done through the use of GIT. This way each variation can have it's own folder which contains the auto generated HAL code and hooks to the Arduino API. By separating the boards int different private branches, one can keep code trees for say F1, F4 and perhaps F0 devices in a local branch. Other user can have private local branches for F7 or L0.

It take me between 1 and 3 hours to add a new ST variant branch to my local git for a new core. Most of this work is mapping the pins to match "Arduino" functionality. This gives the user basic gpio, some coms and timers. HAL can be called direct from a sketch. IMHO it does not get much simpler than that.

What is really needed is help with the testing and to extend some of the functionality, in areas like SPI and USB. The nice thing about CubeMX is that sometimes one gets DMA for free.

jcw
Posts: 171
Joined: Mon Oct 26, 2015 8:16 am

Re: Bring in the ChibiOS HAL?

Post by jcw » Fri Oct 30, 2015 8:51 am

Neat trick, although this requires command-line use, or a Git GUI tool.

I'd expect most people to just want to use the options, not develop their own board variants.
Local git branches won't help there, unless we bring them all into github.

Have you looked at the way ChibiOS is set up? It's compiler/rtos/architecture/device variant subtree, the switch is made through a few Makefile variables. Supports not just STM32 and not just GCC (but these are by far most fully defined), with pin definitions worked out for 46 STM32 boards so far.

Code: Select all

$ cd ChibiOS/os/hal/ports/STM32
$ du
32	./LLD/ADCv1
40	./LLD/ADCv2
36	./LLD/CANv1
36	./LLD/DACv1
44	./LLD/DMAv1
48	./LLD/DMAv2
20	./LLD/EXTIv1
20	./LLD/GPIOv1
24	./LLD/GPIOv2
48	./LLD/I2Cv1
56	./LLD/I2Cv2
36	./LLD/MACv1
112	./LLD/OTGv1
24	./LLD/RTCv1
24	./LLD/RTCv2
40	./LLD/SDIOv1
40	./LLD/SDMMCv1
72	./LLD/SPIv1
44	./LLD/SPIv2
180	./LLD/TIMv1
84	./LLD/USARTv1
96	./LLD/USARTv2
52	./LLD/USBv1
1208	./LLD
152	./STM32F0xx
236	./STM32F1xx
180	./STM32F37x
228	./STM32F3xx
200	./STM32F4xx
168	./STM32F7xx
116	./STM32L0xx
148	./STM32L1xx
68	./STM32L4xx
2704	.
The half dozen boards I tried just work, with demo, a test suite, and benchmarks for most of the boards.
Including USB serial, Ethernet (based on LwIP), and SDFAT.

Code: Select all

$ ls ChibiOS/os/hal/boards
ARDUINO_MEGA                  ST_EVB_SPC560BC
ARDUINO_UNO                   ST_EVB_SPC560D
EA_LPCXPRESSO_11C24           ST_EVB_SPC560P
EA_LPCXPRESSO_BB_1114         ST_EVB_SPC563M
EA_LPCXPRESSO_BB_11U14        ST_EVB_SPC564A
EA_LPCXPRESSO_BB_1343         ST_EVB_SPC56EC
EA_LPCXPRESSO_LPC812          ST_EVB_SPC56EL
FREESCALE_FREEDOM_K20D50M     ST_INEMO_M1_DISCOVERY
FREESCALE_FREEDOM_KL25Z       ST_NUCLEO_F030R8
MAPLEMINI_STM32_F103          ST_NUCLEO_F103RB
MCHCK_K20                     ST_NUCLEO_F302R8
NGX_BB_LPC11U14               ST_NUCLEO_F334R8
NONSTANDARD_STM32F4_BARTHESS1 ST_NUCLEO_F401RE
OLIMEX_AVR_CAN                ST_NUCLEO_F411RE
OLIMEX_AVR_MT_128             ST_NUCLEO_L053R8
OLIMEX_LPC_P1227              ST_NUCLEO_L152RE
OLIMEX_LPC_P1343              ST_NUCLEO_L476RG
OLIMEX_LPC_P2148              ST_STM3210C_EVAL
OLIMEX_MSP430_P1611           ST_STM3210E_EVAL
OLIMEX_SAM7_EX256             ST_STM3220G_EVAL
OLIMEX_SAM7_P256              ST_STM32373C_EVAL
OLIMEX_STM32_103STK           ST_STM32F072B_DISCOVERY
OLIMEX_STM32_E407             ST_STM32F0_DISCOVERY
OLIMEX_STM32_E407_REV_D       ST_STM32F3_DISCOVERY
OLIMEX_STM32_H103             ST_STM32F401C_DISCOVERY
OLIMEX_STM32_H407             ST_STM32F429I_DISCOVERY
OLIMEX_STM32_LCD              ST_STM32F4_DISCOVERY
OLIMEX_STM32_P103             ST_STM32F746G_DISCOVERY
OLIMEX_STM32_P107             ST_STM32L_DISCOVERY
OLIMEX_STM32_P407             ST_STM32VL_DISCOVERY
PJRC_TEENSY_3                 ST_STM8L_DISCOVERY
RAISONANCE_REVA_STM8S         ST_STM8S_DISCOVERY
STUDIEL_AT91SAM7A3_EK         readme.txt
ST_EVB_SPC560B 
There's one entry which builds without any RTOS, "HAL-STM32F407-DISCOVERY":

Code: Select all

$ ls demos/STM32/
CMSIS-STM32F407-DISCOVERY               RT-STM32F334R8-NUCLEO
HAL-STM32F407-DISCOVERY                 RT-STM32F373-STM32373C_EVAL
NIL-STM32F051-DISCOVERY                 RT-STM32F401C-DISCOVERY
NIL-STM32F100-DISCOVERY                 RT-STM32F401RE-NUCLEO
NIL-STM32F303-DISCOVERY                 RT-STM32F407-DISCOVERY
NIL-STM32F373-STM32373C_EVAL            RT-STM32F407-DISCOVERY-G++
NIL-STM32L152-DISCOVERY                 RT-STM32F407-DISCOVERY-MEMS
RT-STM32F030R8-NUCLEO                   RT-STM32F407-OLIMEX_E407-LWIP-FATFS-USB
RT-STM32F051-DISCOVERY                  RT-STM32F411RE-NUCLEO
RT-STM32F072-DISCOVERY                  RT-STM32F429-DISCOVERY
RT-STM32F100-DISCOVERY                  RT-STM32F746G-DISCOVERY
RT-STM32F103-MAPLEMINI                  RT-STM32F746G-DISCOVERY-LWIP-FATFS-USB
RT-STM32F103-OLIMEX_STM32_P103          RT-STM32L053R8-NUCLEO
RT-STM32F103RB-NUCLEO                   RT-STM32L152-DISCOVERY
RT-STM32F103_INEMO_DISCOVERY            RT-STM32L152RE-NUCLEO
RT-STM32F302R8-NUCLEO                   RT-STM32L476RG-NUCLEO
RT-STM32F303-DISCOVERY

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

Re: Bring in the ChibiOS HAL?

Post by sheepdoll » Fri Oct 30, 2015 6:02 pm

jcw wrote: I'd expect most people to just want to use the options, not develop their own board variants.
Local git branches won't help there, unless we bring them all into github.
With the explosion of combinations, I am not seeing a one size fits all approach other than to scrap Ardiono IDE and use Eclipse. This effectively makes the work here irrelevant.

The options are set in CubeMX. Git is just used as source control.

With Arduino there has to be a pin mapping table. This maps the functions to the expected pins. Most of the variants are built on this mapping table. While the Nucleo did this badly all the Nucleo boards use the same footprint which I think is R. This makes the baseline GPIO common across all Nucleo boards. Even some of the low end Discovery boards can use this sort of mapping.

Contrast this to the stuff with more horsepower like the F429I which supports things like extended memory TFT controllers etc. How does one simply "Use the options?"

Add in all the cheap F1xx boards and the clones, then what happens?

In effect what is being done is to emulate the AVRmega xx8 chip footprint, the same way Apple used to emulate Motorola 68K or intel xx86 on the power PC.

I am not arguing for or against anything here. More just throwing out (Hopefully not with the bathwater) just some Ideas I have had.

jcw
Posts: 171
Joined: Mon Oct 26, 2015 8:16 am

Re: Bring in the ChibiOS HAL?

Post by jcw » Fri Oct 30, 2015 6:41 pm

Good points. I agree, it's a complex problem.

Could some of the variability be moved into libraries? Take SPI, for example: the Arduino runtime doesn't know about it, it gets added as library, which you pull in when you need it. Could this be done for advanced stuff, such as the LCD/FSMD/DMA side of things? The runtime doesn't have to deal with ALL the platform differences.

I tend to prefer command-line and "make", but that isn't friendly enough without something like an Arduino IDE to wrap it - for people who don't have the background (yet, possibly), or don't want to learn all that. Some just want to get their garage door opener working with their own circuit and some simple programmed logic. Or tie a Christmas tree to a web server, or whatever :)

Post Reply