UECIDE with Roger’s core and latest gcc 7

Wuuuhaaa!
I talked to Matt years ago about porting the STM32duino core (I don’t remember why it stucked).
I think many people didn’t even know about “UECIDE” except all guys played with PIC32 and chipkit.

All I can say is: Give UECIDE a try, it’s an amazing IDE with much improvements and stunning features.

AND: Don’t forget: On THIS board there is no support for UECIDE, okay?

[madias – Thu Dec 06, 2018 4:55 pm] –
AND: Don’t forget: On THIS board there is no support for UECIDE, okay?

Indeed. UECIDE has its own forums. If you have problem with UECIDE (unless they’re some general fault with the libmaple core) then post them there.

As far as the “improvements” go – it’s just the sorting out of the `inline __always_inline` problem – nothing else.

I just gave it a try.

Good:
– Simple to use

Bad:
– very young, full of bugs,
– cannot install libmaple F1 libraries since they are not contained in the core.

==> not usable.

I would recommend to use the core as it is, and parse the Arduino-related files, similar to Sloeber.

I have just this moment uploaded the stm32f1 library packages. Next will be the f4 libraries. I still need to port most of the board configurations.

I’m just happy to have the core working… After having an F4 discovery board lying around for 4 or 5 years I finally made the LED blink the other day

TBH I wasn’t planning on announcing the port just yet, since it’s not that ready for consumption. Not until all the parts are finished being ported…

Sounds interesting.

I wonder what you mean by “ported”

Do you mean forked and modified, if so are the changes extensive? Are they backwards compatible with the Arduino IDE?
Are they just in files like boards.txt and platform.txt, or are they to the c/c++ files?

By “ported” I mean creating the configuration files. The code remains the same – except the “inline __always_inline” thing, which is all I modified in the code. Everything else is configuration files and packaging.

I can’t just take the existing Arduino configuration files since the way that UECIDE works is completely different to the Arduino IDE. It splits the core from the compiler and allows you to have different combinations of board, core and compiler. Also programmers are separate items. And then it’s all packaged in “.deb” files for the internal package manager (my own implementation of “apt” in Java) to control.

Much of what is in UECIDE pre-dates similar things that are now in the Arduino IDE. The Plugin Manager of UECIDE pre-dates the “Board Manager”. UECIDE had a grapher (now defunct, I need to re-write it…) before the Arduino IDE had a graphing tool. Coincidence…? And of course UECIDE has so much that the Arduino IDE can never hope to have. The first thing we did away with was that god-awful serial “monitor”, and replaced it with a real ANSI serial terminal…

Fyi:

Hello World.JPG

Hello World.JPG (46.66 KiB) Viewed 486 times

[majenko – Thu Dec 06, 2018 7:44 pm] –
By “ported” I mean creating the configuration files. The code remains the same – except the “inline __always_inline” thing, which is all I modified in the code. Everything else is configuration files and packaging.

I can’t just take the existing Arduino configuration files since the way that UECIDE works is completely different to the Arduino IDE. It splits the core from the compiler and allows you to have different combinations of board, core and compiler. Also programmers are separate items. And then it’s all packaged in “.deb” files for the internal package manager (my own implementation of “apt” in Java) to control.

I presumed you must have changed the config files (boards.txt etc)

Whats the issue with always line.

I recall some debate about this a while ago but I can’t remember the outcome

In GCC 7 you can have “inline” or you can have “__always_inline” – you can’t have both. It complains about “duplicate inline” if you do. And logically it makes no sense to have both. You’re saying on one hand “Have a go at inlining it if you fancy”, and then on the other hand “You MUST inline this! OR ELSE!”. And the compiler ends up schizophrenic. So I took out the “inline” and left the “__always_inline” since, logically, the imperative would override the suggestive.

And no, I don’t modify the boards.txt file – in UECIDE a board is a separate entity with its own configuration (board.txt file – singular) in its own folder structure. A completely separate thing to the core. The core has its core.txt file, which has portions adapted from platform.txt, and then the compiler has its own compiler.txt, and the programmers have their own programmer.txt files. Each is a separate entity (a UObject in internal programming terms) and the sketch sees them layered over each other (board -> core -> compiler from top to bottom, each overriding data in the one below it, or complementing settings with additional variables).

The structure makes sense, just that is not compatible with the actual libmaple core file structure.
How will updates from Roger’s core flow into your structure? Will you have to update each time when a new commit takes place? This is more than cumbersome. Can’t be the core files ported somehow manually to this different structure?
You could still generate those extra layer txt files from the core txt files and IDE settings.

BTW, this is where the inline stuff is discussed: https://github.com/rogerclarkmelbourne/ … 2/pull/551

In the early days of a core port yes, it means manually copying things across and making tweaks when things are committed. However, as the port matures I usually script all the work, and it’s just a case of typing one command to get the latest data, parse the config files for the information I need, and bundle up all the packages. By doing it manually at first I can assess the stability of the port better, and learn what can be scripted for scraping, and what can be left as static and tweaked manually on the very rare occasions that it would ever change. It tends to be easier to script when the core is already packaged for the Arduino IDE using the .json file system since I can monitor that file for new versions and download them as a package to then repackage and generate config files from. It’s a little harder when it’s just a github repo, since commits to the repo may have nothing to do with my packages at all – and may not even be stable and desirable to push out until fully tested – especially when there are multiple cores in one repo like Arduino_STM32.

It would be helpful if there was a release structure in place for the Arduino core, but alas not – so it falls on my shoulders to keep my end up to date. For some cores I have, in the past (and I need to re-create this) had nightly builds of the core direct from the source github repository which have been published in a separate Nightly Builds UECIDE repository for those that like bleeding edge software. That was (and will again be) all 100% scripted and unattended. But only for cores that I have written the scripting for.

I try and keep the variable names in the configuration files the same where possible – although UECIDE does impose some special names of its own – and variables are in the bash format ${…} instead of just {…}, and there are extra-special variable that I call “varcmds” which are small executable scripts that get replaced with whatever the script returns (programmed in Javascript) which give you ultimate flexibility to build really quite complex command structures in the config files – something Arduino can never do

So yes, once I have finished porting the boards and things over and I know just what is needed in the porting, I will be scripting it. And then I may add it to the nightly repository too with automated builds, when I resurrect it. But really that needs the upstream core to have “releases” for “nightly” to make any sense.

in UECIDE a board is a separate entity with its own configuration (board.txt file – singular) in its own folder structure. A completely separate thing to the core. The core has its core.txt file, which has portions adapted from platform.txt, and then the compiler has its own compiler.txt, and the programmers have their own programmer.txt files..
As an UECIDE beginner I tried to add a new Maple Mini1 board, and a new stm32f1A core – and it was easy (sure, I asked Matt for a hint outside this forum) – I made copies of the Maple Mini and stm32f1 folders (called the Maple Mini1 and stm32f1A) and edited those board.txt and core.txt files located inside those new folders (on my Win7 in C:\Users\pito\AppData\Local\UECIDE\..)
All those config txt files start with a “name and description..” which need to be changed accordingly
name=maple-mini1
description=Maple Mini1
core=stm32f1A
..

Yea, this info should go under a wiki entry: how to install a new board.
And maybe there will be a script available which allows a user to generate his own board, core and compiler variant.
Then one could eventually “manually” (per script) update/add UECIDE core and libs with his own (core/lib taken directly from git repo).

Eventually it will be all in the WiKi. I only started the WiKi the other day though. It’s been on my todo list for the past 5 years.

@majenko Are you going to come back and ask for other modifications when it turns out that gcc 7 has issues with this code? Is this the only issue with gcc 7 you have found?

This is the only issue that I know of, and it’s not me that found it – it’s been hanging around for a while (See the link above).

And I am quite capable of debugging my own issues thank you without having to come here and pester you. Besides, I use gcc7 with numerous different ARM boards – Due, Teensy, etc, and this is the only core I have had so far that has needed modification to work with it.

Also I would sooner trust the compiler provided by ARM than one thrown together by Arduino. After all, they can’t even get AVR GCC 5.4.0 working right on Windows…

Oh, and the beauty of UECIDE is you’re not tied to GCC 7. You can use the Due compiler if you really must (although it’s not set up for that at the moment). UECIDE has one simple underlying rule: the user chooses what they run – I just provide the choice.

I tried your code on linux 64, it seems like I must install the .deb to be able to use it.