-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No support for the ARM toolchain on... ARM? #29
Comments
Hi @jnorris , I close this one as an issue is already opened for this. |
actually there is something unofficial...https://github.com/koendv/stm32duino-raspberrypi |
I know @odo2063 but I would like a maintain able solution. |
me too...but sometimes having at least something is better than nothing... |
Right, but If I release this I will have to support it and answer to all related issue... |
Currently I'm waiting xpack support for arm then I will considered to add this support as mentionned in stm32duino/Arduino_Core_STM32#708 |
Hi Frederic, Right now I am using stm32duino on a Raspberry Pi 4, 4gb ram, running 32-bit raspbian "buster". The Arduino IDE is stable. The built-in IDE editor is sometimes a bit slow. But in general, things work. The upcoming version of the xpack gnu arm embedded gcc will support 32 and 64 bit arm linux hosts. To run stm32duino on arm linux, the only missing component is STM32CubeProg. Could you consider compiling STM32CubeProg for arm linux? Since the introduction of the Raspberry Pi 4, these small arm linux systems are quite capable, and I believe that this market will grow rapidly, with more and more use cases, including for STM32 embedded software development, where the Arduino IDE is a major tool. In the meantime, I don't mind sharing my solution. If you want to try stm32duino on raspberry, go to https://github.com/koendv/stm32duino-raspberrypi, copy the url of the .json file and paste the url in the Arduino IDE, File->Preferences "Additional Board Manager URLS". There are binaries for 32-bit (armv7l) and 64-bit arm (aarch64) linux. regards, koen |
I confirm, work on the next release of the xPack GNU Arm Embedded GCC (v9.2.1-1.2), which will add support for aarch64 and armhf, is under way. The target date is end of March; I'll let you know when available. But, as Koen mentioned, it would probably be useful to start preparing and build the other tools (STM32CubeProg?) for 32/64-bit Arm. |
Unfortunately, I could not "compile" it myself. I'm an user like you 😉
Thanks @ilg-ul |
This will probably take more time than getting the toolchain run on Arm. If this is an open source project, perhaps it should not rely entirely on STM tools and also provide open source tools, like the ones used in Koen's solution. |
Probably...
The main issue is that OSF does not support all STM32 series. Moreover it is only one upload method they are other provided. It is planned to provide the DFU utils for all. |
I'm a bit confused. Are you managing this project as a hobby? According to your GitHub account, you seem to be working for STMicroelectronics, so I expected this to be a project officially supported by STMicroelectronics.
Can you elaborate a bit? What STM32 series are not supported by the OSF tools? I'm not an Arduino user, so correct me if I'm wrong, but, as for upload methods, I saw in Koen's solution several upload methods, using various bootloaders, in rom or in flash. What else would be needed? And what do you mean by 'provide the DFU utils for all'? I'm asking this because I'm trying to understand if I can further help this project. I have a very elaborated build environment (called the xPack Build Box), which allows me to build binaries for Linux Intel 32/64, Linux Arm 32/64, Windows 32/64, macOS, and maybe we can use this to provide a consistent set of tools for the Duino users, in addition to the STM specific tools. |
No it is not a hobby even if several time I'm working at home even the week end... And yes it is supported by STMicroelectronics but it is first a community project. And a I said I'm a user of the STM32CubeProgrammer. Moreover, main ST Software ecosystem mainly support 3 OS as far as I know, that's why I said the bet way is to request on ST community to have STM32cubeProgrammer support for ARM arch.
STM32H7, STM32WB, STM32L5, STM32L4+,... some of the OSF projects start to introduce some of them but not stable yet or does not support all value line.
yes, that's why I said STM32CubeProgrammer is not the only way to upload so for those one this will be OK. I never said I will not add the ARM tooclchain just answered the STM32CubeProgrammer would not be possible while there is not ported on this arch.
Currently, DFU utils is used only for some target and I would generalize them for all.
Any help are welcome, as said this is a community project. 😉
Thanks, that would be nice. I will get back to you if I need to made some build when I have a time slot to work on this, it will be very appreciated. |
Don't you think that, from the internal STM procedures point of view, it is a bit weird (to not say terribly wrong) if, in order to communicate to your colleagues working on the STM32cubeProgrammer you need us to go to the ST community, instead of contacting them directly and getting an estimate when their tool will also be available for Arm 32/64-bit? If it is only a matter of a reasonable time, we'll wait, otherwise we need to consider alternate solutions. And what exactly do you mean by 'ST Community'? I remember some time ago I reported some issues with compiling the STM packages with more recent GCCs, on a site that looked like a forum, but all that happened was that after several months the moderator mentioned that the issue will be passed to someone to investigate, and since then nothing else happened. |
Well, I could not forward all request internally else I will spent my time to do this, the way to go is to use https://community.st.com/
Well this one: https://community.st.com/ |
Here the answer:
So, my advice is to request it on ST community as I suggest... |
In other words, that tool will take like forever to be available, thus the whole effort to provide the Arm toolchain was practically useless since without that tool you cannot release an Arm version of stm32duino. Is this correct? Since waiting for a favourable outcome from a message posted in the ST community is like watching another episode of Mission Impossible. :-( |
No this is not correct. |
Yes, there are other methods, but will this project use them? Since for now it seems all those methods were discontinued and replaced with the STM32CubeProgrammer. As far as I know, the IDE works on any possible platform. The toolchain runs on all major platforms, Intel Linux 32/64, Arm Linux 32/64, Windows 32/64, Intel macOS 64. Normally you should also release stm32duino on all 7 platforms, accompanied by existing open source tools, also built for all 7 platforms. If STM provides STM32CubeProgrammer on a limited set of platforms, it should be added where available, not the other way around, to limit the number of supported platforms to follow those of STM32CubeProgrammer. I'm convinced the community will appreciate using stm32duino on all 7 platforms. At least from my part, the toolchain will support all of them. |
It seems like we can't understand each other.
For example, OK it runs on win32/64 but there is no way to differentiate them so the only way to support both is to release the 32 bits versions for windows. About the limit of supported platform, you don't understand my point which was to avoid having to support all related issue because one or other tools does not support a dedicated series or value line. Anyway, as I said they are other way which are already provided to support that and I will extend DFU utils usage and probably add open OCD way. I do my best to have a coherent set of tools which can be maintainable and I always take in account all contributions (PR, ...) or suggestions to improve and help the community. |
You mean the IDE does not know when running on win64? What a pity... Anyway, I'll provide you the toolchain which already runs on all platforms (I did not release it since I'm still woking on gdb-py and gdb-py3, but this does not affect your IDE anyway). I hope you'll do the best out of it, including using the new Arm binaries, since I worked quite a lot to build them. I'm not happy that you are not using the win64 binaries, since this messes the analytics, but this is a different story. |
I guess it known but it does not allow us to specify which tools to install/use....
I understand, but related to to IDE itself... maybe one day it will be supported or maybe it can be considered 32bits should no be provided anymore and switch to 64 bits... But I guess some user still having a 32 btis... |
Definitely. And as long as Microsoft will continue to support Windows on 32-bit machines, my binary tools, including the arm-none-eabi-gcc, in addition to the expected 64-bit binaries, will have their 32-bit siblings. As for Arm, at this moment, most Raspberry Pi machines run 32-bit Linux-es, and although I do not like 32-bit OS-es very much, I think that both Linux 32 and Linux 64 deserve attention. Can your IDE differentiate between Arm 32 and Arm 64, to install the proper binaries? |
This is not my IDE 😉 |
Anyway we can hope the future release of the new Arduino Pro IDE will handle that. |
Ok, thank you for the details. The chances for me using Arduino in the near future are low, but I'll continue to support you with the toolchain. Good luck with your projects. |
Hi Frederick.
Thanks for your help. At least we tried. |
Welcome and thanks also for asking. |
for what do you need STM32CubeProgrammer anyway if you use Arduino?(just asking I have absolutly no clue, "onetime" Firmware update can be done on x86) |
It is not mandatory... It is supported that's all and allows to flash over: SWD, DFU and Serial. |
Trying to install the STM32 boards in Arduino on a Raspberry Pi, but no luck: "Tool xpack-arm-none-eabi-gcc is not available for your operating system."
The text was updated successfully, but these errors were encountered: