ST's (STM32Cube) software ecosystem is terrible - how can we fix it?

[blkdev2]

Various RTOSes are taking up the challenge of providing a vendor-neutral API. I can verify that the STM32 port of Zephyr is usable, although lacking some drivers: https://www.zephyrproject.org/doc/api/api.html

Problem is, designing a flexible vendor-neutral API with low overhead is fundamentally hard, and they all end up as lowest-common-denominator solutions to some extent. Zephyr needs to attempt this because it is ultimately trying to enable composable systems where the software components (e.g. network stacks) may come from different vendors, while mediating concurrent access to hardware.

For many applications it's better to write an application-specific HAL that contains precisely the functionality you use and port that between vendors on an as-needed basis.

So far the Arduino folks have been doing a good job keeping AVR8, SAM3X and SAMD21 in the ropes, and TI folks is looping in MSP430 too.

There's already a port to STM32 that works with the common F103 boards https://github.com/rogerclarkmelbourne/Arduino_STM32. I don't personally feel the Arduino hardware abstractions qualify as "good" but that's a matter of opinion.

[technix]

Various RTOSes are taking up the challenge of providing a vendor-neutral API. I can verify that the STM32 port of Zephyr is usable, although lacking some drivers: https://www.zephyrproject.org/doc/api/api.html

Problem is, designing a flexible vendor-neutral API with low overhead is fundamentally hard, and they all end up as lowest-common-denominator solutions to some extent. Zephyr needs to attempt this because it is ultimately trying to enable composable systems where the software components (e.g. network stacks) may come from different vendors, while mediating concurrent access to hardware.

For many applications it's better to write an application-specific HAL that contains precisely the functionality you use and port that between vendors on an as-needed basis.

So far the Arduino folks have been doing a good job keeping AVR8, SAM3X and SAMD21 in the ropes, and TI folks is looping in MSP430 too.

There's already a port to STM32 that works with the common F103 boards https://github.com/rogerclarkmelbourne/Arduino_STM32. I don't personally feel the Arduino hardware abstractions qualify as "good" but that's a matter of opinion.

In my opinion for a POSIX-style HAL the only thing that can muddy things up is open(2). I am talking about using GCC toolchain, and make use of linker garbage collection here to keep the final image size down. Since for embedded systems there is no vfs the traditional vfs-based open(2) either loops in too much drivers (making the final binary too large,) or makes implementing a VFS troublesome (difficult to patch,) I usually go for a driver-specific open(2), kind of like the socket(2) and pipe(2) calls. This allows the GNU linker garbage collection to throw out unused drivers, while still keeping a POSIX-like semantic. Here is the code used to set up the stdin, stdout and stderr streams in my code:

Code: [Select]

void __attribute__((constructor)) _stdio_init(void)
{
    int usart_fd = open_uart(USART1, O_RDONLY, 115200, 8, 0, 1); // This function calls open_device, which actually allocates the file descriptor.
    dup2(usart_fd, STDIN_FILENO);
    if (usart_fd != STDIN_FILENO) close(usart_fd);
    usart_fd = open_uart(USART1, O_WRONLY, 115200, 8, 0, 1); // Have to close and open again to reset the permissions.
    dup2(usart_fd, STDOUT_FILENO);
    dup2(usart_fd, STDERR_FILENO);
    if (usart_fd != STDOUT_FILENO && usart_fd != STDERR_FILENO) close(usart_fd);
}This code opens USART1 for stdin, stdout and stderr at 115200bps 8/N/1. THis is usually a good starting point for application code.

[Gibson486]

A good HAL need to be platform and vendor agnostic, so those "vendor HAL" flat out does not meet this criteria. A good example of a good HAL would be the Arduino API.
In my own code I do use HAL - a mix of POSIX API and Arduino API for features not exist in POSIX.

Any peripheral differs from vendor to vendor. So the layer above the peripheral  that handles the init and all the tweaks and quircks , flags and interrupt etc from that peripheral ,usually called the HAL is and will always be vendor specific.

Nothing is stopping you from writing a proprietary userHAL on top of the vendors HAL, but saying that all HALs from all vendors should be equal is waiting for utopia.

So far the Arduino folks have been doing a good job keeping AVR8, SAM3X and SAMD21 in the ropes, and TI folks is looping in MSP430 too.

In fact the sole point for me to bring up POSIX is because itself is too a HAL and have been used to abstract away platform differences on a good multitude of hardware platforms: the same POSIX API works on things from PC (Linux) to Mac (macOS) to embedded systems (uCLinux) to smartphones (iOS) to game consoles (OrbisOS.) What I am trying to say here is maybe we can try make some parts of POSIX API work on STM32 without an operating system kernel.

I applaud Arduino for doing it, but if you ever dug under the hood, you will see the pain they went through to get it to work. In my experience, just from going from a Freescale m4 to a St Micro m4 is a lot of work because the peripherals do not work the same way. The closest thing to to what you want is mbed. Essentially, took the vendor HAL and put their own API on top of it. 

[blkdev2]

The closest thing to to what you want is mbed. Essentially, took the vendor HAL and put their own API on top of it.

mbed lost me with the transition from mbed 2 to mbed OS 5, but I believe they've abandoned the lightweight event driven concurrency model for a full RTOS based on CMSIS-RTOS... and have renamed/rewritten all the tooling.

[Gibson486]

The closest thing to to what you want is mbed. Essentially, took the vendor HAL and put their own API on top of it.

mbed lost me with the transition from mbed 2 to mbed OS 5, but I believe they've abandoned the lightweight event driven concurrency model for a full RTOS based on CMSIS-RTOS... and have renamed/rewritten all the tooling.

This is probably the right move in the long run. After trying to help out a few newcomers I feel like an RTOS is what most people want. Try explaining the concept of hardware timers and interrupt handlers to someone who just wants their project to do the equivalent of walk and chew bubble gum. Not fun. They can spare a few KB though, no problem. Arduino is utterly deficient.

I have not used it the past 2 years. That is sad that they did that.

[duparq]

I started a project of a HAL a few years ago when I wrote my first program for an STM32F103. I have called it HWA.

The goal was to get very readable and concise source code producing fully optimized binaries. I think I have reached it.

HWA is still at the beginning concerning the STM32, but the support of a few Atmel AVR8 chips is more mature and a bunch of examples demonstrate what can be done with it.

It is free software: https://github.com/duparq/hwa

You'll find a documentation here: http://duparq.free.fr/hwa/index.html

The way it works is very different of all others I have seen so far.

Any comment on HWA would be greatly appreciated!