arm-none-eabi-gcc 9.3.1-1.1 was released, with Raspberry Pi support

[ilg-ul]

Following Arm release 9-2020-q2-update from June 1st, the xPack GNU Arm Embedded GCC v9.3.1-1.1 was released:

https://xpack.github.io/blog/2020/07/03/arm-none-eabi-gcc-v9-3-1-1-1-released/

Please give it a try in your environment and, if everything is ok, possibly use it in your next release.

---

To be noted that this version also provides armhf and aarch64 binaries, which means they run on Raspberry Pi in both 32/64-bit variants.

So the major hurdle for releasing the Arduino environment for Raspberry Pi (the toolchain) was overcome, you need only to provide the other tools.

@koendv already has some solutions for this (https://github.com/koendv/stm32duino-raspberrypi).

[fpistm]

Hi @ilg-ul
I saw your release and plan to give it a try. Also for arm host os 😉
Thanks

[ilg-ul]

Ok, please let me know how it goes.

[ubidefeo]

@ilg-ul @fpistm
Good to read this, I was about to post a related issue as a user of our Arduino CLI put me on a scavenging adventure over a failed compilation :)
You can find more info here
arduino/arduino-cli#778 (comment)

Thank you for being on top of this :)

[koendv]

Glad to hear a stm32duino release for arm hosts is planned. To have a complete development environment, you can also run stm32cubemx on raspberry pi:

STM32CubeMX on Raspberry Pi

Download and install Oracle java 1.8.0, arm32 hard float

 cd /opt; tar xvf jdk-8u251-linux-arm32-vfp-hflt.tar.gz

Download and unzip STM32CubeMX

unzip en.stm32cubemx_v5-6-1.zip

Start installer

/opt/jdk1.8.0_251/bin/java -jar ./SetupSTM32CubeMX-5.6.1.exe

Execute STM32CubeMX from install directory

/opt/jdk1.8.0_251/bin/java -jar ./STM32CubeMX

Uninstaller:

/opt/jdk1.8.0_251/bin/java -jar STM32CubeMX/Uninstaller/uninstaller.jar

At startup stm32cubemx says a 64-bit java is preferable, but I have had no problems generating code with 32-bit java on raspberries with 4 or 8gb ram.

[ubidefeo]

@fpistm we look forward to a update
as more folks use arduino-cli we’re seeing quite a few requests for help related to using the tool on Raspberry Pi (Zero and 4) and as I dig into the reports for Blue Pill very often it’s due to missing tools for arm_v6 and arm_v7.
I’m digging STM32duino, by the way ;)

[ilg-ul]

using the tool on Raspberry Pi (Zero and 4)

As for the toolchain, I confirm it works fine on RPI 4 with 4GB of RAM, both 32/64-bit OSes.

However a Pi Zero, with only 512 K of RAM, might be too tight to run builds.

[fpistm]

@ubidefeo, all,

ARM support will be a beta and I could not provide any date on this.

[ubidefeo]

@ilg-ul
We released an armv6 because we were pressured into it but the experience is awful.
Takes minutes to install cores and compiling times seem taken out of an xkcd comic.
Pi4, on the other hand, is an extremely appealing option :)

@fpistm thank you for letting us know.
If you feel like giving us at Arduino access to the Beta we'd be more than happy to test it out as we move forward with CLI

[ilg-ul]

Pi4, on the other hand, is an extremely appealing option

Indeed!

For those interested in performance figures, the dedicated machine I use for building the Arm xPacks is a ROCK Pi 4, which, in December, appeared to be the most performant Arm SBC, mainly because it provides a M.2 SSD interface. The M.2 SSD transfer rate is about 500 MB/s by default, and can reach 1000 MB/s with an advanced setting in the boot rom.

Later on I experimented with Raspberry Pi 4 with a Sandisk Extreme Portable USB 3.1 and I got about 300 MB/s, out of the 500 advertised, the limitation being the USB speed on the Raspberry Pi.

However, the builds are generally limited by the CPU speed, and disk speeds above 200-300 MB/s do not bring much gain, so M.2 is probably an overkill.

Building the arm-none-eabi toolchain for Arm takes 407 minutes for the 64-bit, and 371 minutes for the 32-bit.

Overall, this is about 4-5 times slower than the Intel NUC used to build the similar Intel GNU/Linux xPacks. The difference is explained by the clock increase from 1.5 to 4 GHz, and the double number of cores (even with hyperthreads).

Interestingly enough, the Raspberry Pi supports without problems parallel builds with -j4, and the memory usage generally stays below 1 GB.

If I'd have to order now a new machine for the xPack builds, I'd choose a Raspberry Pi 4 with 8 GB and a Sandisk Extreme Portable Pro USB 3.1, which should be able to sustain even a write speed of 300 GB/s, the USB limit on the Raspberry.

If you have further questions on the build environment, please write me on private.

[ilg-ul]

ARM support will be a beta

Great!

I don't know the specifics of the Arduino IDE, but, if possible, please consider both variants, with 32/64-bit.

The 32-bit is currently mainstream, but the Raspberry Pi OS 64-bit beta is quite functional, and I expect it to reach the stable status in a few months, so better prepare for it from the very beginning. The toolchain at least is available in both variants, so this shouldn't be a limitation.

[ubidefeo]

hey @fpistm
Just letting you know I have begun testing arduino-cli on Raspberry Pi OS 64 bit since we have a release but were not receiving any feedback about it. Seems that more users are interested in having our CLI run on the very slow Zero.
Go figure :)

[fpistm]

Note:
xpack-dev-tools/arm-none-eabi-gcc-xpack#7

New release:
https://github.com/xpack-dev-tools/arm-none-eabi-gcc-xpack/releases/tag/v9.3.1-1.2

[ilg-ul]

Any progress on the arm/arm64 stm32duino?

[fpistm]

Any progress on the arm/arm64 stm32duino?

Unfortunately not. I have to take some time for this. I've personally purchased a RPI4 for this (and also because I want one for other personal project 😉) so I will be able to work on this.

[fpistm]

Close this one as duplicate of #708

[ilg-ul]

BTW, I recently released v9.3.1-1.3, which I hope will remain stable until next Arm release, so this is the recommended version for your next release.

https://xpack.github.io/blog/2020/10/12/arm-none-eabi-gcc-v9-3-1-1-3-released/