Bring in the ChibiOS HAL?

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.

jcw wrote:Here’s another idea / suggestion: bring the ChibiOS Hardware Abstraction Layer into the Arduino-STM32 project.
<..>

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?

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?

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

mrburnette wrote:The interest in the STM32 has gone from the medium density to the high-density much faster than I had imagined.

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.

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.

$ 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 .

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.

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 🙂

Did someone say Eclipse? Fresh article on HAD:

http://hackaday.com/2015/10/30/code-cra … velopment/

Thanks

I noticed that as well, but have not read it yet.

I know a few people on the forum have managed to configure Eclipse for use with Arduino and the STM32 but I”ve not had much luck when I tried (and I don’t have a huge amount of spare time to spend on it

Edit.
It looks like the article focuses on Linux. I think @rickkimball has it set up and working, but I suspect the on Windows that things are still not that straightforward

eclipsearduino
i’ve just tried it again on this debian 8 system, it complains about 1.6.5r? and shows 1.6.4 for software;
i can see a selection list of boards.txt
my main arduino 1.6.5 is installed in ~/ard165 and the ‘boards.txt’s listed are from the hardware directory in that location.
it doesn’t see the ~/sketchbook/hardware/Arduino_STM32 directory, this i believe is the recommended way for us(?)
i did configure the plugin with the correct paths for my sketchbook, libraries and hardware. i use a soft link for ~/sketchbook to ‘sketchbook_STM32 and in sketchbook/hardware’ is another soft link to the ‘current’ Arduino_STM32′ directory.

i’ll go off and have a play with directories under ~/ard165xx …

edit1
the directories listed are from ~/.arduino15 and ard165xxx/hardware, not seeing sketchbook/hardware
edit2
moved stm32 to ard165xxx/hardware, now seeing stm32 boards / variant/ upload options
tried a compile and got ……
copied gcc-arm….etc into hardware/tools/gcc….
now moans about missing “libmaple/libmaple_types.h”
include path screwed up i suspect

i’m reverting.

stephen