HALMX roadmap.

Development of new Cores using the STMCubeMX and HAL
User avatar
sheepdoll
Posts: 234
Joined: Fri May 22, 2015 12:58 am
Location: Silicon Valley Vortex
Contact:

HALMX roadmap.

Post by sheepdoll » Mon Sep 07, 2015 2:50 am

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.
Last edited by sheepdoll on Mon Sep 07, 2015 4:44 pm, edited 1 time in total.

User avatar
RogerClark
Posts: 6692
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: HALMX roadmap.

Post by RogerClark » Mon Sep 07, 2015 3:18 am

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.

zmemw16
Posts: 1369
Joined: Wed Jul 08, 2015 2:09 pm
Location: St Annes, Lancs,UK

Re: HALMX roadmap.

Post by zmemw16 » Mon Sep 07, 2015 8:46 am

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

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

Re: HALMX roadmap.

Post by sheepdoll » Mon Sep 07, 2015 4:46 pm

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
I fixed the OP to include some words I thought I typed, but forgot to, as I was writing this late at night.

stevech
Posts: 441
Joined: Thu Aug 27, 2015 6:32 am

Re: HALMX roadmap.

Post by stevech » Tue Sep 08, 2015 3:23 am

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.

User avatar
RogerClark
Posts: 6692
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: HALMX roadmap.

Post by RogerClark » Tue Sep 08, 2015 3:54 am

@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

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

Re: HALMX roadmap.

Post by sheepdoll » Tue Sep 08, 2015 6:41 am

RogerClark wrote:
But it does make me wonder how many other differences there are, between the F4 HAL and the F1 HAL etc
There are some really great pdf documents on the ST chip variant web pages I think I linked to one of these in one of the threads here. I have been working through studying them when I have time. While they do seem to be built with doxygen and duplicate stuff in the header and c code files, having it in one place on the PDF helps.

As far as the port setups, there is a bug in the OS X cube MX, that does not allow the pin functions like the speed to be changed. On the flip side, is the issues you mentioned were from the aborted attempts to adapt the Areoquad core. With using git to control the variants. (each variant can have it's own temporary branch) these differences become moot.

It was not until I went into the demo board configurations, that I realized that all the mouse buttons and modifier keys work in CubeMX. This way pins can be labeled, alternates can be mapped, and IO configured.

stevech » Mon Sep 07, 2015 8:23 pm wrote:That RTOS, done properly for newbies' viewpoint, can eliminate a lot of non-engineer users' frustrations about MCUs.

I wrote a small kernal RTOS for AVR to do MIDI stuff between 2001 and 2005. This was to handle floppy access through a memory map. It took many years to debug. I sure learned a lot.

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.

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

Re: HALMX roadmap.

Post by mrburnette » Tue Sep 08, 2015 11:58 am

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.
I resemble that remark !
---- The Three Stooges :lol:

Ray

https://www.youtube.com/watch?v=tEM7I5VSVjY

stevech
Posts: 441
Joined: Thu Aug 27, 2015 6:32 am

Re: HALMX roadmap.

Post by stevech » Wed Sep 09, 2015 2:59 am

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
Using CubeMX, you'll see that the each chip's repertoire of on-board peripherals and the features/modes of each are in the CubeMX GUI. You DO NOT have to spend hours rummaging through 1,000 page ST reference guides. Eliminating all that was the impetus from going from the ST Standard Peripheral Library (SPL) to HAL as a GUI based tool where your options and settings are right there in front of you on the screen.

Once all the choices are made, you hit MAKE PROJECT FOR IDE-xxx, and in 30 seconds all the library code and init code is auto-generated. It takes a few days to learn how to use this. And it's a different mindset. Much, much easier with example videos of which there are few. If I had time...
A lot of professionals jump-start learning it by attending training classes and workshops. I did it without such.

stevech
Posts: 441
Joined: Thu Aug 27, 2015 6:32 am

Re: HALMX roadmap.

Post by stevech » Wed Sep 09, 2015 3:08 am

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.
Me too. I learned with FORTRAN II. Then 20 years of assembly language on mini-computers then microprocessors. Then Pascal. Then C for decades. Only 4 years ago did I tackle C++. I won't be learning MS's C# any time soon, nor Apple's equivalent.

"Coders". I learned that coding is 30% of the task. Well after requirements definition, UI design, vetting, coding, testing, documenting. Today, people get a glimmer and start hacking code. 400% of it gets thrown out before the coder is done. Well, I'm sounding like an old f**t. It's just that back then, we never had enough time, money and computer access to Design At The Keyboard.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest