stm32duino in Arduino on Raspberry Pi

[odo2063]

Is your feature request/improvement related to a problem? Please describe. yes

Describe the solution you'd like Being able to install stm32duino in Arduino on Raspberry Pi.

Describe alternatives you've considered none

Additional context It would be nice to be able to compile and flash stm32duino boards from a Raspberry Pi. At the moment we doing a longterm test where all devices are only available by wifi or GSM. So it would be nice to be able to implement improvements in field. It would also great in schools. the raspi4 is powerful enough to be cheap desktop for schoolusage and then it would be nice if your boards could be used besides it.

[fpistm]

Hi @odo2063, As I do not have a Raspberry, I will not be able to work on this stuff. I guess the main works is to have an arm-none-eabi-gcc toolchain for this target and also check all tools used by the core for upload.

If anyone want contribute to this this will be greatly appreciated.

[odo2063]

the arm-none-eabi-gcc seems easy... https://packages.debian.org/buster/gcc-arm-none-eabi

What else do you need?

i could also give you SSH to Raspi if you like...or you find something with https://www.st.com/content/st_com/en/products/microcontrollers-microprocessors/legacy-mpus/spear-arm-cortex-a9-microprocessors.html

[fpistm]

Thanks but I will not have access with SSH due to security policies. About arm-none-eabi-gcc this require several investigations:

• Which one have to be used depending of the host arch? Honestly, I don't know Raspi ecosystem, what I know is Arduino seems able to handle twice of them (arm64 and armhf)
• arm64
• armel
• armhf
• Which options has been used to build ? (libraries provided? lto support?....), moreover this is not the same version and unfortunately I don't think Arduino IDE was able to deal with as we are able to only reference one.
• Test if all options used is well supported
• Need to be repackage to be installed thanks Arduino but I'm not be able to test.
• ...

What else do you need?

All tools (binaries and scripts) tested and updated in the https://github.com/stm32duino/Arduino_Tools repo.

[odo2063]

Hi I found this one https://github.com/vanbwodonk/gcc-arm-embedded-build-armhf

[odo2063]

Which one have to be used depending of the host arch? Honestly, I don't know Raspi ecosystem, what I know is Arduino seems able to handle twice of them (arm64 and armhf)

For now consider Raspian as standard Debian on armhf....this will maybe change to arm64 for the Raspi4 in the future

[odo2063]

./dfu-util --version
dfu-util 0.8

...seems to compile

I can run any script you want me to...but I am a newbie when it comes to build up a toolchain with my own hands...

[fpistm]

Currently, I've no time frame to investigate this at least until next year. If anyone wants try to work on this will be welcome.

[koendv]

Just FYI: Raspberry already has the following debian packages:

• binutils-arm-none-eabi
• gcc-arm-none-eabi
• libnewlib-arm-none-eabi libnewlib-dev
• libstdc++-arm-none-eabi-newlib

After installing these packages, you can compile stm32 code on Raspberry. Eg. you can compile this: gdb debugger for blue pill. I've added a list of available commands and the output of arm-none-eabi-g++ -v: gcc-output.txt

What's missing (I think) is the STM32 arduino libraries and their headers in the arduino IDE. HTH.

[fpistm]

@koendv the main issue is to have n all in one toolchain package (aligned with the gcc version used by other host OS) and as I said I could not test it. So I could integrate it if someone is able to provide and test it.

[koendv]

Fine. If you provide a STM32 board package that assumes arm-none-eabi-g++, arm-none-eabi-ld, dfu-util, ... are in /usr/bin, I can try to compile some examples ("blink") on raspberry and get the examples running on black pill/blue pill. OK?

[fpistm]

When I said "integrate", I mean store it on GitHub and reference it in the boards JSON files. Not provide it.

[koendv]

OK. odo2063, if I put an arm-none-eabi toolchain up, are you willing to test it?

[odo2063]

I could give you SSH to a raspi if you like...with X-Forwarding...

[koendv]

OK. Your turn. https://github.com/koendv/stm32duino-raspberrypi

gcc-arm-none-eabi-9-2019-q4-major, dfu-util 0.9, hid-flash 2.2.1, built for armv7l-linux-gnu (raspberry in 32-bit mode). Build takes 16.5 hours. I could recompile this for aarch64 if needed.

[odo2063]

I'll compile it that weekend...can we meet at IRC or something like that so I can hand you over the login credentials, because I don't know what to do any further?

[koendv]

OK. I've got a raspberry, I've already compiled the toolchain, and you can download toolchain and stm32tools for 32-bit raspbian "Buster" from my github. What comes next is installing toolchain in the arduino ide.

If I look at the package_stm_index.json file, there are 4 things needed for a functioning toolchain.

• "STM32 Cores 1.7.0" can be used mostly as-is. Maybe need to edit platforms.txt because compiler version changed.
• "arm-none-eabi-gcc" Already compiled for raspberry. Download from my github. Probably need to change the name of the top-level directory so the naming convention stays the same.
• "STM32Tools" Already compiled for raspberry. Download from my github.
• "CMSIS" no changes needed.

There are some issues here: it seems arduino packages need to be signed before they can be installed. And because I've compiled arm-none-eabi-gcc-9.2.1 you'll probably need to change "8.2.1-1.7" in platforms.txt to "9.2.1". But, summarizing: it's no longer a problem of compiling, it's a problem of packaging and installing. Perhaps it would be best if some small .json package index file were created for the arm/raspberry platform, for testing.

I will try to compile toolchain and tools for aarch64 this weekend, so we don't have to go through this again when raspbian goes 64-bit.

Does this seem logical to you?

[odo2063]

i got a raspi4 ;-) and if this goes productive we could do a crosscompile...

[fpistm]

You can use the platform.local.txt to override some config. About the toolchain, thanks the help of @ilg-ul, I moved to 9.2.1. He is currently thinking to provide an toolchain for arm host, see https://github.com/stm32duino/Arduino_Core_STM32/issues/708

[koendv]

OK. That is good news. You can download the gcc-arm-none-eabi 9.2.1 toolchain and STM32Tools for armv7l (raspberry pi in 32-bit mode) and aarch64 (raspberry pi in 64-bit mode). There's also build notes. Anything else needed?

[ilg-ul]

I did some research and I learned that the first time arm64 was supported by a major Debian distribution was Debian 9 Stretch (ldd --version -> 2.24), and Ubuntu 16.04 (which unfortunately picked a slightly older ldd --version -> 2.23).

Due to the relative order of the system libraries versions, I would say that binaries built on Debian 9 might fail on Ubuntu 16.

Thus, although personally I'd prefer to base my binaries on Debian distributions, it is safer to go for the oldest, which means that for Arm we'll probably have to use Ubuntu 16.04.

This is in line with the Arm build procedure, which also uses Ubuntu 16.04 for the aarch64 binaries, available starting with 9-2019-q4-major.

And, for consistency reasons, I'd use the same 16.04 for both 32 and 64-bit variants (armhf and aarch64).

Any comments on this?

For the moment I installed an Ubuntu 16.04 arm64 on QEMU and I'll use it to update my xPack build scripts to add support for Arm binaries.

Later on I'll probably need a hardware solution, since I expect the build times to be unbearable long in emulation.

[koendv]

OK. Estimate 2.5 days build time. I guess the advantage will be the 32-bit build will be the more general armhf, and not the raspberry-specific armv7l. Does this imply the STM32Tools have to be recompiled under Ubuntu?

[ilg-ul]

I guess the advantage will be the 32-bit build will be the more general armhf, and not the raspberry-specific armv7l.

right

Does this imply the STM32Tools have to be recompiled under Ubuntu?

I know nothing about these tools, but if stm32duino is to run on generic Arm 32-bit machines, i guess they have to be armhf too.

---

The comment about avoiding the raspberry-specific armv7l is a good point and should be a gain if indeed armhf binaries run on all Raspberry Pis, large and small.

But the question has another meaning too, if choosing Ubuntu 16.04, anything with ldd --version older than 2.23 probably will not work. I have no idea if there are such systems, for 64-bit probably not, but for 32-bit there might be, I really have no idea.

On the other side, given that making a build environment based on the old Ubuntu 16 is already difficult, and going even further back in time to Ubuntu 14 is almost 'mission impossible', if there are such very old Arm 32-bit systems not able to run Ubuntu 16 armhf binaries, I'm afraid they'll be collateral damages...

[fpistm]

Does this imply the STM32Tools have to be recompiled under Ubuntu?

I know nothing about these tools, but if stm32duino is to run on generic Arm 32-bit machines, i guess they have to be armhf too.

Yes some binaries will have to be built for the targeted hosts (ex: DFU utils).

But the question has another meaning too, if choosing Ubuntu 16.04, anything with ldd --version older than 2.23 probably will not work. I have no idea if there are such systems, for 64-bit probably not, but for 32-bit there might be, I really have no idea.

On the other side, given that making a build environment based on the old Ubuntu 16 is already difficult, and going even further back in time to Ubuntu 14 is almost 'mission impossible', if there are such very old Arm 32-bit systems not able to run Ubuntu 16 armhf binaries, I'm afraid they'll be collateral damages...

I'm not aware of arm based distribution anyway I guess supporting all possibles arch is not possible. So, I guess your proposal seems reasonable and aligned with ARM choice to use Ubuntu 16.04

[koendv]

Yes some binaries will have to be built for the targeted hosts (ex: DFU utils).

OK. The latest version of dfu-utils is v0.9. If we have to recompile for armhf, let's compile on the same os used for the toolchain, and let's compile the latest version, so we don't have to revisit the subject for a year or longer.

[ilg-ul]

seems reasonable and aligned with ARM choice to use Ubuntu 16.04

Good, we'll stick to Ubuntu 16.04.6 LTS, ldd --version -> 2.23 for both armhf and aarch64 for now.

Yes some binaries will have to be built for the targeted hosts (ex: DFU utils).

Probably it would be good to build them using the same Ubuntu 16. The binaries do not need to be build necessarily on a Pi, since I'm not sure there is such an old official Ubuntu 16 running on Pi (http://cdimage.ubuntu.com/releases/16.04.6/release/), but can also be build on QEMU; for usual projects the speed should not be a limitation, as it is for toolchains; I'll publish the details of my build environments on a separate page, for those who want to play with it.

[beta-tester]

i just tried to install STM32 Cores 1.9.0 on my Raspberry Pi (newest Raspbian Buster updated and upgrades and Arduino IDE 1.8.12).

but i get the error message Tool STM32Toolsis not available for your operating system.

does it mean that there is still no support for STM32 on a Raspbian Pi or am i missing something?

ESP32 and Digispark support i could add sucessfully to Arduino IDE on my RPi. ir would be nice to have STM32 as well.

[koendv]

On Thu, 21 May 2020 04:13:49 -0700 beta-tester [email protected] wrote:

i just tried to install STM32 Cores 1.9.0 on my Raspberry Pi (newest Raspbian Buster updated and upgrades and Arduino IDE 1.8.12).

but i get the error message Tool STM32Toolsis not available for your operating system.

does it mean that there is still no support for STM32 on a Raspbian Pi or am i missing something?

ESP32 and Digispark support i could add sucessfully to Arduino IDE on my RPi. ir would be nice to have STM32 as well.

I've just updated. Maybe you tried to install just when I was updating the git?

koen

[beta-tester]

i deleted every stm related stuff from my RPi and re-tried the process:

• in Arduino IDE i added the link to the package json file:
• and then tried to install the STM32 Cores: but the installation does not go on, because of the message: Tool xpack-arm-none-eabi-gcc is not available for your operation system. (the message now is different to the previous one - maybe i messed too much around previously)

do i have to compile something before i can continue installation?

[beta-tester]

i think i got it... i took the regular link for package json (https://github.com/stm32duino/BoardManagerFiles/raw/master/STM32/package_stm_index.json).

when i take the raspberry pi specific link /https://raw.githubusercontent.com/koendv/stm32duino-raspberrypi/master/BoardManagerFiles/package_stm_index.json) the installation succeeds.

[koendv]

On Thu, 21 May 2020 08:21:16 -0700 beta-tester [email protected] wrote:

i think i got it... i took the regular link for package json (https://github.com/stm32duino/BoardManagerFiles/raw/master/STM32/package_stm_index.json).

when i take the raspberry pi specific link /https://raw.githubusercontent.com/koendv/stm32duino-raspberrypi/master/BoardManagerFiles/package_stm_index.json) the installation succeeds.

OK. Good.

koen