Strategy in keeping architectures in sync

The official STMicroelectronics Arduino core
danieleff
Posts: 105
Joined: Thu Sep 01, 2016 8:52 pm
Location: Hungary
Contact:

Strategy in keeping architectures in sync

Postby danieleff » Thu Nov 17, 2016 9:07 am

I think the code for F1, L4, and other soon to come chips should be kept as close as possible together.
Currently in the 2 repositories:
  • cores/arduino/* files are exactly the same (except the new libstm32f1 folder)
  • libraries/* files are exactly the same
  • system/* the structure of building HAL is the same
  • variant/* the structure of variant files is the same
  • platform.txt is same(?), boards.txt has the same structure
  • libstm32f1/* / libstm32l4/* files are very similar
I would hate to see them drift apart. (The code is generic enough that I was able to use L4 GPIO/SPI code for F411 and L053 just by changing the #includes, ldscript, and clock)

My questions are:
  1. Do you actually want to keep them in sync?
  2. If yes, any plans?
  3. Does the other not yet released arch code have the same structure as F1/L4?

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

Re: Strategy in keeping architectures in sync

Postby RogerClark » Thu Nov 17, 2016 10:01 am

Daniel

At the moment I don't have a plan, mainly because I didn't know that we'd need to refactor the STM core as much as we have had to.

I think that some other quite substantial changes are still needed to the F1 core, as the memory usage in global structures is far to high and is going to be very wasteful on the STM32F103R, V and Z series.
(its almost unusable on the VL series at the moment (STM32F100))

I agree we should probably refactor the L4 in the same way as the F103. I suppose we could do this now, as whatever changes are needed for the global vars issue could be applied later to the L4 core as they are independent of any restructuring


Re: HAL
The code that was delivered by STM, was always split up into separate folders, e.g. a folder for the F103 and a folder for the L4, with duplicate copies of the HAL etc.

I have not compared the F1 HAL files to the L4 HAL, I presumed the files had different contents, even if the filenames where the same ???

STM seems to treat the HAL files for each MCU in isolation, e.g. from the STM32Cube you have to download each MCU series HAL separately, and they are not at the same versions.

I think whats important with the HAL files is to not modify them too much, as it makes it hard to update to a new version of the HAL if there have been extensive changes. And even small changes need to be documented and applied by hand to a set of updated HAL files.


Re: duplicate files in libraries

It may be possible to use git submodules to have linked folders e.g. for libraries into a separate "libraries" repo, but with the LibMaple repo I tried doing this and it didnt work, because 95% of people downloading from github, download via zip rather than running git and cloning the repo, and unfortunately github zip files to not contain the contents of the submodules, so people end up with empty folders.

So as the libraries are probably fairly stable, I think we'll probably have to live with duplicate files.

With core files, its currently hard to know how divergent they may become. As really we've only been looking at a small subset of the possible STM MCU series, F1, L4 and your own F4 trials.

(and I can't see a way to do this via submodules even if submodules didnt have the download via zip problem)


Re: 3

I think Wi6Labs will use some of the bug fixes etc from the F1 and L4, but I don't know if its in their remit to re-structure to match the new F1 structure.
I presume that we will need to restructure the code after its delivered by STM (Wi6Labs)
But I have no control over this - STM just let me know when they have something new to release.

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

Re: Strategy in keeping architectures in sync

Postby zmemw16 » Thu Nov 17, 2016 2:04 pm

@Roger
It may be possible to use git submodules to have linked folders e.g. for libraries into a separate "libraries" repo, but with the LibMaple repo I tried doing this and it didnt work, because 95% of people downloading from github, download via zip rather than running git and cloning the repo, and unfortunately github zip files to not contain the contents of the submodules, so people end up with empty folders.


maybe add a 'DO THIS' file in those directories? in theory a once only thing :)

also anyone cloning without --recursive would have same issue as well?
does --recursive give different results to the sub modules route?

stephen

Ollie
Posts: 129
Joined: Thu Feb 25, 2016 7:27 pm

Re: Strategy in keeping architectures in sync

Postby Ollie » Thu Nov 17, 2016 3:57 pm

My vote is to avoid opportunistic sharing structures. Even if the F1 and L4 could be merged in more areas, we should have an architecture that allows new families without modifying the existing libraries. Only the common things on top of HAL should be shared.

danieleff
Posts: 105
Joined: Thu Sep 01, 2016 8:52 pm
Location: Hungary
Contact:

Re: Strategy in keeping architectures in sync

Postby danieleff » Mon Nov 21, 2016 7:36 am

Ollie wrote:My vote is to avoid opportunistic sharing structures. Even if the F1 and L4 could be merged in more areas, we should have an architecture that allows new families without modifying the existing libraries. Only the common things on top of HAL should be shared.


The F1 and L4 don't need to be merged, as one is a copy of the other with modifications.
Here is a diff of them: http://danieleff.com/stm32/diff.php (This was done a while back actually)
The biggest differences are in config structures (and a lot in comments), not actual code.

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

Re: Strategy in keeping architectures in sync

Postby mrburnette » Mon Dec 19, 2016 4:12 pm

@danieleff:

This is a tremendously valuable analysis.
http://danieleff.com/stm32/

Bravo on the effort.

Ray


Return to “STM Core”

Who is online

Users browsing this forum: No registered users and 1 guest