HALMX roadmap.

Here is a simple skeleton roadmap of where I am planning to go with HALMX

• Glue code to float Arduino API over the HAL API through boards.txt/platforms.txt – concept proven mostly done
• Digital output — Basic blink sketch, Working on F0, F1 and F4
• Simple serial print stream, Working on F0 (external hardware), F1, and F4
• Digital Gpio input – TBW – may be inherited directly from HAL
• Analog Gpio input – TBW – need to set up interrupt callbacks through HAL
• PWM outputs – TBW – Some messyness with mapping pin functions with AVR emulation – requires interrupt callbacks.
• uSecont timer timeouts – TBW – May need to be part of the sketch.

— High level peripherals
• USB
— Serial CDC
— MIDI
• SPI — (SPI with DMA)
• I2C
• TFT controller – As per STM429I-Discovery
• CANBUS — Low priority, but is is mostly already in HW —

— High level libraries
• FATFS — (There are also Arduino FAT libraries, but FATFS is well supported and stable)
• USB-OTG — not sure where to place this

Note 1: there are a myriad of shields and devices like Ethernet controllers, Wi-Fi, Bluetooth, Mems gyros, zigbee radios, GPS, etc. That all require high level libraries to make work. Many of these are “register” devices, which communicate via shift registers or DMA. Each of these devices better fits into a separate roadmap.
Note 2: There are also devices like the ubiquitous Hitachi HD44780 LCD controller, and the ever present MMC/SD card interface, which basically one gets for “free” once GPIO is up and running. The HD44780 does require an extra negitive supply when used at 3V to generate a negative bias on the contrast control. This can be easily implemented with a charge pump, either from a PWM pin or an external fixed frequency source.

Thanks for the roadmap.

Just a thought, but can we borrow much from Koduino (https://github.com/avikde/koduino) e.g. there are already libraries and a whole load of other functionality we may be able to benefit from.

Note. K0duino uses the old Standard Peripheral Library not the HAL one, so we’d need to update it to use the HAL version, and I’m not sure how heavily Avik modified the SPL its self, from what I recall it was definitely not just a case of using the old SPL library files straight from STM, there needed to at least be some restructuring of the file organization and possibly a lot more changes
But its still worth looking at.

Personally I think getting CDC needs to be quite high on the list as it would mean a lot more people could easily participate, even if its just for testing.

sheepdoll wrote:
The HD44780 does require an extra negitive supply when used at 3V. This can be easily implemented with a charge pump, either from a PWM pin or an external fixed frequency source.

zmemw16 wrote:sheepdoll wrote:

HD44780’s with an extended temperature operating range also require a negative supply with 5V, I got two via an oops wrong one:-)
with a 3v3 supply i don’t know, but i’d guess yes.

stephen

using the legacy SPL (ST’s Standard Peripheral Library) – has the big pitfall that ST is focused on/supporting the HAL rather the SPL. They haven’t declared the SPL as depreciated or at EOL, but they do have lots of web pages urging people to not use SPL for new designs. And new chip types likely won’t have SPL support but will, in the HALs.

Also, the HAL, in my experience, as all three mode variants for most every peripheral: polled I/O (blocking), interrupt driven (no-blocking), and DMA (non-blocking). Only DMA-driven for high speed things like SDIO at up to 48Mbps. DMA for ADC, DAC, chained-DMA for these two, DMA even for pin changes and timer capture counts. And so on.

It’s an important decision… wrapper APIs to simplify these. Use CubeMX to auto-generate all the drivers and initialization variant for a certain project and board/MCU.

Today’s users, many accustomed to PCs and RPi/Linux, struggle with blocking I/O and slow-events limitations. They may not know about DMA and so on, but they do wonder why their API call hangs.

Worse, they get frustrated and go away, if they hit things like Arduino’s lack of shared use of SPI. All I’ve seen is PJRC’s SPI Transactions driver to solve this problem. It’s good for Arduino users. Not so good for a multi-threading environment such as FreeRTOS brings to ST32F. That RTOS, done properly for newbies’ viewpoint, can eliminate a lot of non-engineer users’ frustrations about MCUs.

@stevech

Thanks for the insight into the HAL, I hadnt realised there was multiple options even for GPIO.

The only thing I noticed so far as that we need to be careful when writing the Arduino API code that it doesn’t use HAL options that are not available on all the devices we intend to support. e.g. From what I recall with the GPIO clock/speed settings the F4 has more options I think that @sheepdoll’s initial code used a F4 only speed option, which woudln’t compile on the F1 (I think this may now be fixed).

But it does make me wonder how many other differences there are, between the F4 HAL and the F1 HAL etc

RogerClark wrote:

But it does make me wonder how many other differences there are, between the F4 HAL and the F1 HAL etc

sheepdoll wrote:
I fixed the OP to include some words I thought I typed, but forgot to, as I was writing this late at night.

RogerClark wrote:@stevech

Thanks for the insight into the HAL, I hadnt realised there was multiple options even for GPIO.

The only thing I noticed so far as that we need to be careful when writing the Arduino API code that it doesn’t use HAL options that are not available on all the devices we intend to support. e.g. From what I recall with the GPIO clock/speed settings the F4 has more options I think that @sheepdoll’s initial code used a F4 only speed option, which woudln’t compile on the F1 (I think this may now be fixed).

But it does make me wonder how many other differences there are, between the F4 HAL and the F1 HAL etc

sheepdoll wrote:
You are probably correct relating to users accustomed to PCs and RPi/Linux. I learned to program nearly 40 years ago. I noticed that tech workers do not even call them selves programmers any more, they are now coders and API developers.

stevech wrote:

A lot of professionals jump-start learning it by attending training classes and workshops. I did it without such.

Sheepdoll & All,

I am attending a STM32F7xx HAL course in Cambridge (UK) this Thursday. Free to attend, and they give you a STM32F7 Discovery to take home

I really need to switch over to the HAL way of thinking, because although so far using the Standard Peripheral Libraries has worked for M3 and M4 they are not supported on the M7.

Atmel have a blistering 300MHz M7 available in a 144 pin LQFP. http://www.atmel.com/products/microcont … sam-e.aspx

I guess that is a good candidate for a future descendant of Arduino.

Ken

A couple more sites to watch:

Lots of useful routines using HAL:

https://github.com/MaJerle/stm32fxxx_hal_libraries

Should soon release support for the STM32L4 (don’t know if they will use HAL):

https://www.tindie.com/products/onehors … out-board/

Supposedly the mbed code uses the HAL.

The STM32L476G-DISCO is only $19.50.

monsonite wrote:Sheepdoll & All,

I am attending a STM32F7xx HAL course in Cambridge (UK) this Thursday. Free to attend, and they give you a STM32F7 Discovery to take home

I really need to switch over to the HAL way of thinking, because although so far using the Standard Peripheral Libraries has worked for M3 and M4 they are not supported on the M7.

Atmel have a blistering 300MHz M7 available in a 144 pin LQFP. http://www.atmel.com/products/microcont … sam-e.aspx

I guess that is a good candidate for a future descendant of Arduino.

Ken

monsonite wrote:
Atmel have a blistering 300MHz M7 available in a 144 pin LQFP. http://www.atmel.com/products/microcont … sam-e.aspx

I guess that is a good candidate for a future descendant of Arduino.

Ken

Microchip policy against Atmel’s product line is a mystery yet. I think, the main cleanup will be done in 8 bit world, as there are too many chips with similar specifications. In 32bit portofolio, the Microchip has no ARM products, there is no reason to kill ARM business. On the other side, I believe that Microchip will improve the supply chain of Atmel chips… (at least for the cherry picked…)

jonr wrote:A
Should soon release support for the STM32L4 (don’t know if they will use HAL):

https://www.tindie.com/products/onehors … out-board/

Hi All,

Is the port alive?

I see 3 separate branches:
– rogerclarkmelbourne’s one seems too be original. Has USB Serial , I2C and SPI modules. Work is mostly happen around F103CB (which is one I am interested in)
– sheeldoll’s fork has more recent CMCIS for NucleoF103
– ekawahyu’s branch is focused on NodinoF072. Has number of examples and Tone core module. CMCIS is located on a HALMX/drivers lever, not on each variant directory. Same thing for USB device libraries.

Each version has something interesting for me. But none of them is looking like a master branch, which is frustrating.

I found also https://github.com/danieleff/STM32GENERIC which seems to be quite good structured.

I’d like to try porting my project to a HAL based Arduino. But having so different variants I really can’t decide where to go.

Any insights on future plans for HALMX project?

This port has been superseded by the “Official” STM port and the STM32Generic port.

This was more of a proof of concept that it was possible to combine HAL and Arduino libraries.

There is another part on my github https://github.com/sheepdoll/XSTMScrips.git which is one of the scripts I was creating to build new variants. I use the printer language postscript for general purpose scripting as postscript has some powerful parsing options.
The STM port took this idea and changed the scripts to use python to create the needed mapping files directly from the CubeMX xml and setup files.

As for the branches. This was an attempt as a way to have multiple development boards in the Arduino tools menu without clutter.

I have sort of moved more of my effort to coding directly in Eclipse without using the Arduino IDE.

Thank you for the answer.
What do you mean under ‘official’ STM port?