new cores on HALMX_Arduino_STM32

Development of new Cores using the STMCubeMX and HAL
madias
Posts: 813
Joined: Mon Apr 27, 2015 11:26 am
Location: Vienna, Austria

Re: new cores on HALMX_Arduino_STM32

Post by madias » Fri Aug 28, 2015 10:42 am

Personally, I feel that moving away from Arduino / Wiring compatibility,
Right, because this is what STM32duino stands for: Compatibility with the Arduino API.
Personally I think, leaflabs left a big gap in the libmaple: strange codings, like 3-4 different "spi.h" with the same name,...unfinished things like I2S, no real USB stuff like audio device, mass storage... and so on. Another point is, that libmaple has only a "real" support for STM32F1 series.
So my only real important question for moving to a new core:
When it's done, is it easier to set up different series and models (like the new STM32F7) and reconcile them? So this would be the major benefit. We wont have to take care what's on "layer 0" because i.e. cubemx+hal would do the job for us. (updates, bugfixes, new models/series..)
Another benefit could be, that's more easier to convert all the other examples for STM32 found on the web, so STM32duino could be a "glue" for Arduino and the rest of the STM32 world.

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

Re: new cores on HALMX_Arduino_STM32

Post by RogerClark » Fri Aug 28, 2015 12:02 pm

Matthias,

I agree.

Leaflabs seemed to put in all sorts of non-compatible stuff into libmaple which made it harder to use their existing code, e.g. calling Serial , SerialUSB, just because it was via USB. I know at the time there was no precedence like the Arduino Leonardo, but even so, it seems an odd decision.
... And a whole load of other things.

As far as I can see, the key is compatibility with existing code, especially libraries.

Actually, now I come to think of it...
I have been testing Victor_pv's PIN_MAP in flash code, and I think its stable enough to merge into the Master of the repo. Actually its not all the const stuff thats really in RAM, its just a bunch of pointers to the GPIO dev structures, but it looks like it may solve the issues of the libraries that attempt to use pinMode etc in their constructors, and it doesn't appear to have an adverse effects, so I may as well merge it at the weekend. and if it needs more work, e.g. pulling the referenced structures into Flash as well, we can do that afterwards.



BTW. On a related note. The HAL based core is only going to work for STM32 based processors, its not going to work for the new GD32 processors, because GigaDevices doesn't have a tool like the STMCubeMX (well I don't think they do). They have a CMSIS and possibly a Standard Peripheral Lib, but I don't think its a HAL SPL (though I'd need to double check)

I'm not sure whether GigaDevices are going to be a major player, but their F103 line is faster and cheaper than the F103 line, and GD also do a F2, and I guess its possible they may license the F4 at some time (who knows)

I wonder whether its worth considering how, if at all, it would be possible to have a HAL type core for GD32 as well as STM32 ???

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

Re: new cores on HALMX_Arduino_STM32

Post by stevech » Sat Aug 29, 2015 1:55 am

I have worked with ARMs for many years, in embedded (professional work). Used NXP, Freescale, Atmel, and my fav, ST. Never heard of GD.

Skimming their website, I see documents too terse and not in acceptable for for English-speakers.

what's the attraction of the GD32 based boards (not chips)?

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

Re: new cores on HALMX_Arduino_STM32

Post by RogerClark » Sat Aug 29, 2015 2:54 am

GD32's seem to offer more performance for the same or less price, and seem to have close (though not complete compatibility) with STM32's

Strangely, the GD32F103 has a spec'ed max clock of 108Mhz, but now that I have one of these boards and am trying to get the USB working, it looks like you can't run it at 108Mhz and have USB.

This is because the it would need a USB divider ratio of 2.25 but it only had divider ratios of 1, 1.5, 2 and 2.5

So to use USB, you can only run the GD32 at 96Mhz and be within spec, or run it at 120Mhz (11% over clocked) and use the 2.5 divider.

But at the moment I think I must have screwed up the PLL settings as I can't get USB to enumerate at all, even on 72Mhz (div 1.5) :-(


Thinking about it, I wonder why they'd implement a USB divider of 2.5 unless they thought they'd be able to run the GD32 at 120Mhz, but perhaps in production their yield was not good enough to guarantee 120Mhz over the published temperature band, and hence they say they can operate at 108Mhz

But this is just speculation on my behalf

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

Re: new cores on HALMX_Arduino_STM32

Post by sheepdoll » Sat Aug 29, 2015 3:56 am

I am confused. Are GD32 devices pin and peripheral compatible with STM32? The website is not much help. If they are a second source, that is a good thing. If they are using the same part numbers to direct traffic to their site, that is of questionable value.

I did look a bit at what the Due was doing with CMSIS. This CMSIS beats against the CMSIS used in things like Koduino and I think the AreoQuad F4 cores. If GD32 is a separate product, then we should treat it like NXP and TI (Outside the scope of these cores.)

My impression is that wiring and processing are basically front ends to 8bit AVR and atmel style peripherals. So the core basically has to emulate Atmel GPIO etc. This is more straightforward in the Due as there is overlap in the way the peripherals are initialized.

Back in 2012 ST made an attempt to provide some simple "Arduino" libraries for the F0. gpio, serial, and spi. I have been reviewing these. I sort of have a fuzzy recollection attending a seminar about this. At the time ST was pushing the IAR and Kiel toolchains, so the code is written in the same style, but using the wiring/processing function names. The resulting code is next to unreadable.

The real heart of any Arduino core for Cortex is to create the mapping of the pins to what the Arduino user expects them to be. This in turn makes the pin mapping the critical issue. Under maple, this invokes direct access to the register structures (as that is the way it is done in Atmel variants.) This falls apart between F1 and F4 as the CMSIS names differ between the families. With just enough commonality to be confusing.

Then to add sauce to the goose ( I think that is the old expression) One has to deal with small pin devices compared against large pin devices. (Probably why ST came up with Cube.) This means that the pin mapping structures really need to be mutable, as the user expects the resulting device to act as the Atmel AVR would, with dynamic register configurations on the fly. (On AVR I tend to turn LEDs On through the DDR register switching between tristate inputs, and 0 state current sinks.) If I need a second SPI or serial port, I bit bang it. For extended shift registers I use cascaded timers and interrupts. I suspect all this can be done in STM32, with different syntax and mindset.

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

Re: new cores on HALMX_Arduino_STM32

Post by RogerClark » Sat Aug 29, 2015 4:04 am

Re: GD32

AFIK, I thought that the devices were pin compatible and had very close software compatibility. i.e @jaconson999 has been running his using the existing generic STM32F103C core, and only had to change the defined for the delay() stuff.

He's managed this because the board that is on Taobao (which I now have in abundance - thanks to a screwup in the ordering on my part), uses a 12Mhz oscillator / crystal, so the PLL settings are the same i.e 9 x 12MHz = 108Mhz instead of 9 x 8Mhz which gives us the 72Mhz for the STM32

However I can't get USB working :-(.... And it looks like the GD devices don't support USB when they are running at their max clock (as they are lacking the correct clock divider option (2.25) to facilitate this... Anyway I won't cross post ;-)

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

NEW REPO FOR THE HALL MX CORE ?

Post by RogerClark » Sat Aug 29, 2015 4:14 am

NEW REPO FOR THE HALL MX CORE ?

Hi Guys,

Now that I have your attention (BY SHOUTING ;-)....

I think it would be best if I put the HALMX core in a separate repo, as the existing repo is fairly large already, and ideally should have been split into F1, F3 and F4 ages ago.......


I have another GitHub account for stm32duino.com, so I think it would probably make sense if I took Julie's core and created a new master copy in the github stm32duino account.

Probably the best way to do it, is to separate the library into its own repo, and the tools into another repo, and then have one master repo that has the halmx core and the tools as submodules.

Or can anyone think of a better way to do it.

I've also been working out how best to support the Arduino Boards Manager packaging requirement (for future deployment) and had considered splitting the tools into tools_win, tools_linux and tools_osx and possibly tools_source, as the Boards Manager needs separate packages for tools for each platform (well ideally it does, to save Linux users downloading exes they don't need etc etc)

But one other option is the GitHub "Releases" system. I've not used it before, but I have seen release scripts.

So this may be a better way to handle tools deployment for each individual OS.

The other question is libraries.

I presume that an SPI lib written for the HALMX core would work on F1, F2,F3, F4 , F7 etc, but I'm not sure if this is guaranteed, and whether we'd still need to split things up.
E.g. I've noticed for example that the GPIO speed settings on an F1 and F4 are not the same. From what vaguely recall the F4 has more GPIO speed granularity than the F1, and it uses different defines for some speeds.
So care would need to be taken when writing libs etc where the HAL seems to differ between series of devices.

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

Re: new cores on HALMX_Arduino_STM32

Post by RogerClark » Fri Sep 04, 2015 10:51 pm

Guys,

I'm going to try to get to grips with the HALMX code in my repo (which is a copy of SheepDoll,s repo).

Currently I'm unsure of whether the initial selections in the CubeMX make any difference to use, apart from processor selection.

e.g. In the cube you initially need to specify the number of USART channels you want to use, as well as the number of Timers, SPI channels, I2C devices etc etc.
Then in the second stage of the CubeMX configuration, I think you need to make sub selections because of pin allocations for each of the functions, as most pins have multiple functions, and some Timers are dedicated for specific purposes, hence if you enable a specific function, the CubeMX shows some Timers in red to indicate they are no longer available for general use.

However I'm not sure if any of this matters to us, i.e whether this is just used to configure what initialisation code that the CubeMX generates.

I suppose what we need is a generic set of instructions that will let us generate the HALMX files for all the processor variants that we need.
(I think this information is in a posting in the forum, but it needs to be in the wiki for the repo)

In addition, I suspect we will probably need to modify some of the files, either manually or using a script. For example, to use a bootloader, the VECT_TAB_OFFSET which is defined in one of the CMSIS headers as 0x00 needs to be changed to be externally defined.

Ideally the CubeMX would wrap this in #ifndef, but it doesn't in the code in the repo (but I'll need to take a look at the latest files I've exported from the CubeMX just in case STM have improved this).

And of course we need to change main.c to add the calls to setup() and loop() in main.c



Overall, I think we need to start to try this repo, in order to understand what we still need to do ;-)

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

Re: new cores on HALMX_Arduino_STM32

Post by sheepdoll » Sat Sep 05, 2015 3:16 am

I copied some of the setup info from the threads here to several readme.txt files that are in the repo.

https://github.com/rogerclarkmelbourne/ ... _setup.txt

and

https://github.com/rogerclarkmelbourne/ ... ation.txtt

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

Re: new cores on HALMX_Arduino_STM32

Post by RogerClark » Sat Sep 05, 2015 5:58 am

Thanks, I'm copying the text into 2 different Wiki pages in the repo so we can format it and update it more easily

Post Reply