Windows/Linux/Mac Eclipse plugin to compile and upload arduino sketches

belzebuthb:
I saw, but I don’t understand how to link boards.txt to my program. :confused:
For example, if I put an option to choose CAN (1 or 2 or 3), how can I get it back in my program?

if it is an option in platform.txt the you can set its value.
and you can set -D with ‘extra’ flags over platform.txt

Juraj: if it is an option in platform.txt the you can set its value. and you can set -D with 'extra' flags over platform.txt

Thanks a lot :D :D :D

Sorry I ask a lot of questions :smiling_imp: Is it possible to do write conditioner in boards.txt?

For example if CAN1 select, display baudrate selector

Thanks :)

belzebuthb: Sorry I ask a lot of questions :smiling_imp: Is it possible to do write conditioner in boards.txt?

For example if CAN1 select, display baudrate selector

Thanks :)

I think it is not possible, but I am not an expert in this.

Juraj: I think it is not possible, but I am not an expert in this.

Ok thanks :)

belzebuthb:
Is it possible to do write conditioner in boards.txt?

For example if CAN1 select, display baudrate selector

This is mostly done by using the otion not–used baud rate 1, baud rate 2 … as options for CAN1

I installed, on a windows 10 machine, the windows version 4.3.3 of Sloeber 64-bit bundle as recommended and made sure paths are short and pathnames do not have spaces etc. When I execute Sloeber-ide the first time it shows some errors along with the message that "Failed to configer Sloeber". Here are the errors copied from the Error Log. I repeated the install on a mac and got a similar error message. Is this something I can ignore? I am a beginner at this. I have previously attempted to install the Sloeber plugin on Yakindu SCT and got the same error; that is why I attempted to install using the method recommended in the Baeyens website.

eclipse.buildId=unknown java.version=1.8.0_131 java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US Framework arguments: -perspective io.sloeber.application.perspective Command-line arguments: -os win32 -ws win32 -arch x86_64 -perspective io.sloeber.application.perspective

io.sloeber.core Error Tue Nov 17 07:45:39 PST 2020 Failed to configer Sloeber

eclipse.buildId=unknown java.version=1.8.0_131 java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US Framework arguments: -perspective io.sloeber.application.perspective Command-line arguments: -os win32 -ws win32 -arch x86_64 -perspective io.sloeber.application.perspective

io.sloeber.core Error Tue Nov 17 07:45:39 PST 2020 Failed to install [DEPRECATED] Arduino mbed-enabled Boards

eclipse.buildId=unknown java.version=1.8.0_131 java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US Framework arguments: -perspective io.sloeber.application.perspective Command-line arguments: -os win32 -ws win32 -arch x86_64 -perspective io.sloeber.application.perspective

io.sloeber.core Error Tue Nov 17 07:45:39 PST 2020 Failed to download "http://downloads.arduino.cc/cores/ArduinoCore-mbed-nonexistant.tar.bz2".

java.io.IOException: Failed to download url http://downloads.arduino.cc/cores/ArduinoCore-mbed-nonexistant.tar.bz2 error code is: 404 at io.sloeber.core.api.PackageManager.myCopy(PackageManager.java:778) at io.sloeber.core.api.PackageManager.myCopy(PackageManager.java:740) at io.sloeber.core.managers.InternalPackageManager.downloadAndInstall(InternalPackageManager.java:351) at io.sloeber.core.managers.InternalPackageManager.downloadAndInstall(InternalPackageManager.java:130) at io.sloeber.core.managers.InternalPackageManager.startup_Pluging(InternalPackageManager.java:101) at io.sloeber.core.Activator$2.run(Activator.java:247) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

eclipse.buildId=unknown java.version=1.8.0_131 java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US Framework arguments: -perspective io.sloeber.application.perspective Command-line arguments: -os win32 -ws win32 -arch x86_64 -perspective io.sloeber.application.perspective

io.sloeber.core Warning Tue Nov 17 07:45:39 PST 2020 Failed to download url http://downloads.arduino.cc/cores/ArduinoCore-mbed-nonexistant.tar.bz2

java.io.IOException: Failed to download url http://downloads.arduino.cc/cores/ArduinoCore-mbed-nonexistant.tar.bz2 error code is: 404 at io.sloeber.core.api.PackageManager.myCopy(PackageManager.java:778) at io.sloeber.core.api.PackageManager.myCopy(PackageManager.java:740) at io.sloeber.core.managers.InternalPackageManager.downloadAndInstall(InternalPackageManager.java:351) at io.sloeber.core.managers.InternalPackageManager.downloadAndInstall(InternalPackageManager.java:130) at io.sloeber.core.managers.InternalPackageManager.startup_Pluging(InternalPackageManager.java:101) at io.sloeber.core.Activator$2.run(Activator.java:247) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

eclipse.buildId=unknown java.version=1.8.0_131 java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US Framework arguments: -perspective io.sloeber.application.perspective Command-line arguments: -os win32 -ws win32 -arch x86_64 -perspective io.sloeber.application.perspective

io.sloeber.core Warning Tue Nov 17 07:45:39 PST 2020 Failed to download url http://downloads.arduino.cc/cores/ArduinoCore-mbed-nonexistant.tar.bz2 error code is: 404

eclipse.buildId=unknown java.version=1.8.0_131 java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US Framework arguments: -perspective io.sloeber.application.perspective Command-line arguments: -os win32 -ws win32 -arch x86_64 -perspective io.sloeber.application.perspective

org.eclipse.egit.ui Warning Tue Nov 17 07:44:52 PST 2020 Warning: The environment variable HOME is not set. The following directory will be used to store the Git user global configuration and to define the default location to store repositories: 'C:\Users\vicen'. If this is not correct please set the HOME environment variable and restart Eclipse. Otherwise Git for Windows and EGit might behave differently since they see different configuration options. This warning can be switched off on the Team > Git > Confirmations and Warnings preference page.

Sloeber does not come with any platform (read boards) so it tries to install a platform and the platform sloeber tries to install has been deprecated. Solution install the platform of your choice at window->preferences->arduino->platform&boards press on the > untill you can select a version you want to install select apply and close and wait for it to finish (look at bottom right) You are ready to roll

Thank you Jantje, you solved my problem. I am looking forward to learning to use Eclipse with Sloeber.

Hello everyone and Merry Christmas!

First I want to say thank you for this great tool, it's exactly what I was looking for! Last couple of days I was setting up Sloeber for STM32 programming and debugging. So far I already had the chain working, means I already compiled and uploaded successfully a test sketch (BlinkWithoutDelay) to a BluePill STMF103C8. But somehow something got broken, and I don't know if it's due to sloeber, eclipse, STM32duino or me, so I'll post it here.

I create a new sketch (e.g. BlinkWithoutDelay), select blue pill as STM32 board select blue pill as STM32 board and start the build process. All files will compile, but when it comes to combining them several files cannot be found. Here's the compiler output:

'Starting combiner'
"D:\Programme\Sloeber\arduinoPlugin\packages\STM32\tools\xpack-arm-none-eabi-gcc\9.2.1-1.1/bin/arm-none-eabi-gcc" -mcpu=cortex-m3  -mthumb -Os --specs=nano.specs -u _printf_float -Wl,--defsym=LD_FLASH_OFFSET=0x2000 -Wl,--defsym=LD_MAX_SIZE=65536 -Wl,--defsym=LD_MAX_DATA_SIZE=20480 -Wl,--cref -Wl,--check-sections -Wl,--gc-sections -Wl,--entry=Reset_Handler -Wl,--unresolved-symbols=report-all -Wl,--warn-common "-Wl,--default-script=D:\Programme\Sloeber\arduinoPlugin\packages\STM32\hardware\stm32\1.9.0\variants\PILL_F103XX/ldscript.ld" "-Wl,--script=D:\Programme\Sloeber\arduinoPlugin\packages\STM32\hardware\stm32\1.9.0\system/ldscript.ld" "-Wl,-Map,E:\OneDrive\Technik\_programmierung\sloeber-workspace\BlinkTest\Release/BlinkTest.map"   "-LD:\Programme\Sloeber\arduinoPlugin\packages\STM32\tools\CMSIS\5.5.1/CMSIS/DSP/Lib/GCC/" -larm_cortexM3l_math -o "E:\OneDrive\Technik\_programmierung\sloeber-workspace\BlinkTest\Release/BlinkTest.elf" "-LE:\OneDrive\Technik\_programmierung\sloeber-workspace\BlinkTest\Release" -Wl,--start-group    .\sloeber.ino.cpp.o  .\libraries\SrcWrapper\src\stm32\PortNames.c.o .\libraries\SrcWrapper\src\stm32\analog.cpp.o .\libraries\SrcWrapper\src\stm32\bootloader.c.o .\libraries\SrcWrapper\src\stm32\clock.c.o .\libraries\SrcWrapper\src\stm32\core_callback.c.o .\libraries\SrcWrapper\src\stm32\dwt.c.o .\libraries\SrcWrapper\src\stm32\hw_config.c.o .\libraries\SrcWrapper\src\stm32\interrupt.cpp.o .\libraries\SrcWrapper\src\stm32\lock_resource.c.o .\libraries\SrcWrapper\src\stm32\low_power.c.o .\libraries\SrcWrapper\src\stm32\pinmap.c.o .\libraries\SrcWrapper\src\stm32\rtc.c.o .\libraries\SrcWrapper\src\stm32\stm32_def.c.o .\libraries\SrcWrapper\src\stm32\stm32_eeprom.c.o .\libraries\SrcWrapper\src\stm32\system_stm32yyxx.c.o .\libraries\SrcWrapper\src\stm32\timer.c.o .\libraries\SrcWrapper\src\stm32\uart.c.o  .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_adc.c.o .\libraries\SrcWrapper\src\LL\stm32yyxx_ll_bdma.c.o  .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_sd.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_sd_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_sdadc.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_sdram.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_smartcard.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_smartcard_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_smbus.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_spdifrx.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_spi.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_spi_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_sram.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_swpmi.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_tim.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_tim_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_tsc.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_uart.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_uart_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_usart.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_usart_ex.c.o .\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_wwdg.c.o  .\libraries\SrcWrapper\src\syscalls.c.o  .\core\variant\PeripheralPins.c.o .\core\variant\variant.cpp.o     E:\OneDrive\Technik\_programmierung\sloeber-workspace\BlinkTest\Release/arduino.ar  -lc -Wl,--end-group -lm -lgcc -lstdc++
arm-none-eabi-gcc: error: .\libraries\Srcrapper\src\HAL\stm32yyxx_hal_sdram.c.o: No such file or directory
makefile:96: recipe for target 'BlinkTest.elf' failed
make: *** [BlinkTest.elf] Error 1
"D:/Programme/Sloeber/arduinoPlugin/tools/make/make -j8 all" terminated with exit code 2. Build might be incomplete.

(I needed to delete some of the compiler output lines listing libraries to shorten the message length)

This evening I noticed there's a "w" missing in the link, it says

arm-none-eabi-gcc: error: .\libraries\Srcrapper\src

and I think this must be the cause, but how can it be resolved?

I'm using sloeber 4.3.3 (product) and STM32 1.9.0 platform.

Looking forward for any help as I'm in urge need to transfer my growing projects into Eclipse :)

For stm32 you need the nightly.Amongst others for this bug https://github.com/Sloeber/arduino-eclipse-plugin/issues/1143

Note the nightly needs java 11 where the latest product needs java8. So you will have to upgrade or delete the jre folder

note 2: you can also see all the fixes in sloeber by going to arduino menu->do I need to upgrade This will show you all the fixes and links to the related github issues

Hi Jantje, thanks for your answer. I already went throught the sloeber issues, especially the mentioned #1143, as it seemed to be the same problem as mine, but the conclusion I got from it was that the SrcWrapper issue was fixed; but there was no answer to the missing .h files the other guys had, so I didn't get the idea that it's only possible with the nightly build.

By the way, the wrong compiler output (with missing "w") disappeared when I used STM Core 1.8.0

So, I tried to get the nightly which atm is only available at the inbuilt update function, when I try to download I get following error message: |500x163 full message

Cannot complete the install because one or more required items could not be found.
  Software being installed: Sloeber 4.3.3.202012182318 (io.sloeber.product 4.3.3.202012182318)
  Missing requirement: C/C++ Development Tools Core 7.1.100.202012020953 (org.eclipse.cdt.core 7.1.100.202012020953) requires 'java.package; javax.xml.bind [2.3.3,3.0.0)' but it could not be found
  Cannot satisfy dependency:
    From: Sloeber 4.3.3.202012182318 (io.sloeber.product 4.3.3.202012182318)
    To: org.eclipse.equinox.p2.iu; org.eclipse.cdt.feature.group [10.1.0.202012020953,10.1.0.202012020953]
  Cannot satisfy dependency:
    From: C/C++ Development Tools 10.1.0.202012020953 (org.eclipse.cdt.feature.group 10.1.0.202012020953)
    To: org.eclipse.equinox.p2.iu; org.eclipse.cdt.gnu.debug.feature.group [10.1.0.202010181249,10.1.0.202010181249]
  Cannot satisfy dependency:
    From: C/C++ GNU Toolchain Debug Support 10.1.0.202010181249 (org.eclipse.cdt.gnu.debug.feature.group 10.1.0.202010181249)
    To: org.eclipse.equinox.p2.iu; org.eclipse.cdt.launch [10.1.0.202010181249,10.1.0.202010181249]
  Cannot satisfy dependency:
    From: C/C++ Development Tools Launching Support 10.1.0.202010181249 (org.eclipse.cdt.launch 10.1.0.202010181249)
    To: osgi.bundle; org.eclipse.cdt.core [7.0.0,8.0.0)

It tells something about a missing Java version, but what? As far as I understood the Sloeber product comes with its own Java. On my system I have both Java 8 or 11, and set the current version on PATH variable, and I get error with both..but I don't know if this is the reason.

SOLVED: it should be mentioned that all update sites have to be enabled, but if anyone encounters this/this 11 year old bug the "contact all update sites during install" checkbox should be unchecked. Then the update to latest nightly works.

Now that I got the nightly running, I tried to get STM32 1.9.0 running, but it fails again, same error:

arm-none-eabi-gcc: error: .\libraries\SrcWrappr\src\HAL\stm32yyxx_hal_sdram.c.o: No such file or directory
makefile:96: recipe for target 'BlinkTest.elf' failed
make: *** [BlinkTest.elf] Error

So, my few simple questions: is it somehow possible to get STM32 1.9.0 working with Sloeber? Is there anyone out there who is using this constellation, with success? What is the latest version that can be used?

I can't believe I am the only one trying to get this work. I'm about to switch back from 1.9 to 1.7 for the hundredth time, it's really time consuming to get this running...

Googling

"error: .\libraries\SrcWrappr\src\HAL\stm32yyxx_hal_sdram.c.o: No such file or directory"

leads me to https://github.com/stm32duino/Arduino_Core_STM32/issues/813

Is this used? yes. The issues fixed in the nightly have been reported by a stm32 developer using sloeber before the release of the changes. Same goes for ESP32 Also I run tests and they involve 1000 + boards, STM32 is amongst those.

I should make a release but I'm in the middle of a big change (I'm changing the internal workings of sloeber) and I prefer taking it slow and making a stable release to fixing issues with the pressure of a broken release.

Jantje: I should make a release but I'm in the middle of a big change (I'm changing the internal workings of sloeber) and I prefer taking it slow and making a stable release to fixing issues with the pressure of a broken release.

Jantie, will the change include support for dot_a_linkage of libraries? (issue 1126 https://github.com/Sloeber/arduino-eclipse-plugin/issues/1126)

Juraj:
Jantie, will the change include support for dot_a_linkage of libraries? (issue 1126 optional Library option dot_a_linkage not taken into account · Issue #1126 · Sloeber/arduino-eclipse-plugin · GitHub)

Unfortunately not. But it is a steppingstone towards it. But not the last.
This dot_a_linkage is to be implemented in what is called “managed build” in CDT. There is activity in CDT to replace the current managed build, but it is hard and as always, resources are low.
Basically what sloeber currently does (build a library and executable in one project) is already far away from the original goal.
One of the biggest problems Sloeber has with the dot_a_linkage is that libraries are added at configuration switching time. This is so because each configuration can be a different board and as such can need different libraries.
Currently Sloeber does not save library information between configuration switches. That means that the decision logic to redirect the library code to a archive (which is not supported :wink: in the CDT version ) needs to be done at “make file generation” (Which is currently under scrutiny)
If makefile generator could simply query the project (which it doesn’t have in the CDT version) that would be possible. But at this time the project simply doesn’t know the libraries.
So this means that for each file in the makefile there needs to be a check whether this file is part of a library (Which is not obvious because the library folder in your project only contains links to “origins” and the make file generator only sees the “origin”) and if it is; find the properties file (which may be a couple of parent folders up; and non-existent) read it and decide.
Once the project will contain library information (like it contains board information) it will be far easier to map files on libraries (does the file has the library root as basis) and read the library properties (should be in the library information)
Don’t hold your breath

I've read about this and other build_opt.h issues, but as far as I understood it's associated with the serial com. Also, in the mentioned post the issuer used STM core 1.7.0, and that version works for me. But I'm not yes experienced enough to deal with build options.

It seems that it happens when it comes to linking the compiled files and for any reason doesn't find them. This is the makefile line at which it fails:

@echo 'Starting combiner'
    "D:\Programme\Sloeber\arduinoPlugin\packages\STM32\tools\xpack-arm-none-eabi-gcc\9.2.1-1.1/bin/arm-none-eabi-gcc" -mcpu=cortex-m3  -mthumb -Os --specs=nano.specs -u _printf_float -Wl,--defsym=LD_FLASH_OFFSET=0 -Wl,--defsym=LD_MAX_SIZE=65536 -Wl,--defsym=LD_MAX_DATA_SIZE=20480 -Wl,--cref -Wl,--check-sections -Wl,--gc-sections -Wl,--entry=Reset_Handler -Wl,--unresolved-symbols=report-all -Wl,--warn-common "-Wl,--default-script=D:\Programme\Sloeber\arduinoPlugin\packages\STM32\hardware\stm32\1.9.0\variants\PILL_F103XX/ldscript.ld" "-Wl,--script=D:\Programme\Sloeber\arduinoPlugin\packages\STM32\hardware\stm32\1.9.0\system/ldscript.ld" "-Wl,-Map,E:\OneDrive\Technik\_programmierung\sloeber-workspace\BlinkTest\hwdebug/BlinkTest.map"   "-LD:\Programme\Sloeber\arduinoPlugin\packages\STM32\tools\CMSIS\5.5.1/CMSIS/DSP/Lib/GCC/" -larm_cortexM3l_math -o "E:\OneDrive\Technik\_programmierung\sloeber-workspace\BlinkTest\hwdebug/BlinkTest.elf" "-LE:\OneDrive\Technik\_programmierung\sloeber-workspace\BlinkTest\hwdebug" -Wl,--start-group   $(LINK_OBJ)    E:\OneDrive\Technik\_programmierung\sloeber-workspace\BlinkTest\hwdebug/arduino.ar  -lc -Wl,--end-group -lm -lgcc -lstdc++

So, is it a purely STM32 core related problem, or does it only happen in combination with Sloeber? If it's not yet known and a pure STM32 core thing I'd like to make an issue to the STM32duino project. I already tried to dig deeper into this (as I think it has to do with some cache or wrong linkage issues), but due to my restricted knowlegde of this stuff I can't get very far. Meanwhile no other chance than switching back to 1.7. :(

Another thing I encountered is that Clean is not working. Will this be fixed?

And a third issue, I can't get SPI to work on my blue pill, though this should be an easy task. But that seems to be another story...well, I think I've spent half of my vacation with googling problem solutions :confused:

Looking forward for any new version of Sloeber!

EDIT: @Jantje In your tests, did you have any STM32 boards with core 1.9.0 working with Sloeber? If yes, I know something's wrong with my configuration. But until now I don't know if it's possible at all.

tyllurius: EDIT: @Jantje In your tests, did you have any STM32 boards with core 1.9.0 working with Sloeber? If yes, I know something's wrong with my configuration. But until now I don't know if it's possible at all.

The tests run with the latest available version. I assume the tests are run with a frequency that is higher than normal release frequency. Because I can't make sense of what you are writing I assume that most of your issues are cause by user error. In other ways you are trying to do things in a way Sloeber is not meant to be used.

I don't have this error with STM32 1.9.0 and Sloeber plugin version 4.3.3.202004250422 as you can see the paths on command line are right. something happens in gcc

@Jantje, https://github.com/Sloeber/arduino-eclipse-plugin/issues/1126#issuecomment-573453291

} else if (primaryInputNames[curPath].toString().startsWith("libraries") && (bUseArchiver)) {
  outputNames[curPath] = Helpers.GetOutputName(primaryInputNames[curPath]).addFileExtension("o");