Board Manager again

I created board manager packages for the stm32duino code: http://dan.drown.org/stm32duino/package … index.json

If you want to use it, put that URL in File->Preferences->Additional Boards Manager URLs. And then under Tools->Board->Boards Manager, find the stm32f* entry you need and hit the install button on it.

I’m interested in feedback and any criticism.

Edit: updated for 2016.9.20 release

I surely will not critize, your effort and sharing is appreciated.

But the issues were never technical construction of the XML but rather the continued maintenance of the XML document with every core change. Then there is the 3 platforms that STM32duino core supports: Windows, iOS, and Linux so the forum would need to be prepared to have experts in those OS’s identified as the validators/go-to members for difficulties.

We do not have a strict SDLC here; changes are via github pull request and those changes soak in the “development” branch, At some point, Rogers mergers the code into “master”. Therefore 2 XML docs are required to manage automation.

But there gave been no volunteers. And, you are not volunteering, so I really do not see the value provided here when a ZIP download of STM32duino can be expanded into /Arduino/hardware.

One very positive thing I see is you have identified the changes in the core structure to support 1.6.7 and that is significant, IMO.

Kind regards and welcome to the forum,

Ray

I surely will not critize, your effort and sharing is appreciated.

While I understand the resource issue to get such things done, a passive-aggressive post saying to the effect, “I’m not going to criticize you but everything you’ve done is a waste of time” isn’t likely to motivate the participation I’m sure we’d all like to see. I, for one, have some contributions I’ve held off releasing here for exactly this reason.

You clearly have a significant amount of time to post on this forum and you certainly don’t hold back on letting posters know what they’ve done wrong. To be frank though, it doesn’t seem very productive. At the same time you clearly have a lot of knowledge and seem to be very invested in STM32Duino and want to see it successful therefore I hope you can agree that it might draw more flies by encouraging such efforts and not focusing on finding fault so much. I don’t know if you own the forum (seems like perhaps you do). If so, you can do whatever you wish I guess.

Fact is, the new board manager stuff will need to be dealt with eventually if STM32Duino is to get a broader base of users – regardless of the resource issue. For instance, the Eclipse folks have an official arduino plug-in that’s pretty clean and it’s supported. However, it doesn’t work with STM32Duino because it uses the board manager JSON architecture to install board support.

I, for one, find the work ddrown has done to a useful start that I can leverage and expand upon so I can make the Eclipse plug-in work. Perhaps with several folks making some incremental effort and having that effort contributed back to the group, it can eventually reach a point were it’s mostly complete and someone will step forward to provide longer-term maintenance. Of course if all the partial contributions get stamped out before they get started we’ll never know…..

ddrown wrote:
This has my changes in it to work under the 1.6.7 IDE – https://github.com/ddrown/Arduino_STM32/commits/master (the important ones are “fix include paths and new ar arguments” and “set library categories”)

@ddrown

Its good to know that the core does work with 1.6.6

I have looked at using the Boards Manager and created a test package that worked with 1.5.5 some time ago, but I just don’t have time to create an automated build system for packages with some way to manage version numbers etc.

On average I think there is at least one change to the core per week, plus we have the Master (stable) and the Development (cutting edge) branches, both of which would need a package.

From what I recall, there were other issues with 1.6.6 and newer as its quite picky about the meta data for the libraries (though I did fix some of the issues with the libs).

Re: package for 1.6.5 and 1.6.6 (or newer)
I’m not sure its possible to have a version which works for both

Last time I looked at the ESP8266 fix it had a side effect of making the IDE rebuild every file every time you compile, which greatly increases the build time on 2nd and subsequent builds, But perhaps they found a better workaround.

With Teensy, I thought Paul was now distributing his own customized version of the Arduino IDE, but I could be wrong.

I’m also starting to question the need to constantly get a new version of the IDE every month. I know some of the changes are bug fixes, but I generally now just use the IDE to build and upload, and I’m using an external editor as the IDE is not a good coding editor.
So I suspect most of the changes in 1.6.6 and 1.6.7 would not be noticeable to me.

@Roger
I generally now just use the IDE to build and upload, and I’m using an external editor as the IDE is not a good coding editor.

would you please expand on that? i’m rather curious about how you do that.

re the xml aspect, a major version jump would have been better, 1.7.0 for example
along with a big ‘this breaks things, but it is the way we’d like to go’ message.
ps 1.6.5r5 is the last revision, bar security fixes

stephen

RonC wrote:I surely will not critize, your effort and sharing is appreciated.

While I understand the resource issue to get such things done, a passive-aggressive post saying to the effect, “I’m not going to criticize you but everything you’ve done is a waste of time” isn’t likely to motivate the participation I’m sure we’d all like to see. I, for one, have some contributions I’ve held off releasing here for exactly this reason.

You clearly have a significant amount of time to post on this forum and you certainly don’t hold back on letting posters know what they’ve done wrong. To be frank though, it doesn’t seem very productive.
<…>

– Standard unZIP of STM32duino from mid-December Master github
– Standard installation in /Arduino/hardware/STM32
– Test platform Windows 8.1 fully patched, 4G ram

Summary: compiled successfully a variety of examples, personal sketches, and forum posts totaling over 20 examples which included SPI and I2C libraries.

More here

Ray

Ok, this posting generated a lot more activity then I was expecting. Thank you to everyone that is helping with the testing.

To make creating packages easier, I wrote a program to do it: https://github.com/ddrown/Arduino_STM32 … er/package

It pushes packages to a “testing” url: http://dan.drown.org/arduino/testing/pa … index.json

If everything checks out, then this program can be run to promote it from the testing to the normal URL: https://github.com/ddrown/Arduino_STM32 … te-version

I’ve tested it on Windows 10 and Fedora 22. In Fedora, I had to install the 32 bit compatibility libraries (glibc.i686 and libusbx.i686). I do not have a MacOSX system handy to test it on, so it’d be nice if someone could test that.

Here’s what changed in the versions so far:

1.0.1 – include the Arduino’s arm gcc in the install, include the git submodule projects
1.0.2 – experiment with automated package generation, correct the tools paths
1.0.3 – generate separate tools packages per OS, and use .tar.gz for the Linux/MacOSX tools packages to preserve permissions
1.0.4 – fix the MacOSX package

I could also create packages for the development branch on a different url, right now it’s just the master branch.

@ddrown

I will read the links when I get time (sorry very busy with work at the moment)

Re:zmemw16

There is a preference setting called Use External Editor, when you tick it, all the code windows turn grey and you can no longer edit them.
If you change a file externally, and save it, then go back into the IDE, it updates what you see.
I don’t think it does anything else.

So I just open the .ino file in Notepad++ and set the language to C++ and use that as my editor.

There may be better programming editors out there, but Notepad++ has c++ highlighting (albeit not the IDE built in commands or objects like Serial) (but there may be a plugin to do this)

There are probably better coding editors available.

I still do some development work using Adobe’s ActionScript 3, and there is an excellent external editor called FlashDevelop, which has loads of really good features, like code completion and easy ways to find function definitions etc etc etc that I also have grown used to using on MS Visual Studio.

I guess I could probably use MS Visual studio as an external editor and get some of those functions, but I don’t want the massive bloat that installing VS would cause

RogerClark wrote:@ddrown

I guess I could probably use MS Visual studio as an external editor and get some of those functions, but I don’t want the massive bloat that installing VS would cause

blimey – when did they tumble?

istr 256G shading £200

with ssd, especially 500G; bloat does tend to fade

stephen

I used a 64GB SSD for a long time. Never close to full. Because of the NAS.
Only work in process files stored on SSD. Auto-copied to NAS by Centered Systems’ “Second Copy” (terrific software, long used by me).
256GB SSDs are the price sweet spot now.

I buy only Samsung SSDs. They get a premium for these over their competition. But since most of my PC use is professional, I don’t skimp.

The SSDs make the difference between night and day. And do more for speed and ease of use than a faster CPU in a new PC.
Same for MACs.

I published a new version for this

Changes in 1.0.5
– now supports GD32F1, STM32F3, and STM32F4
– Sebastian Kostka’s update for dfu-utils for OS X 10.11.2

I’ve verified that the board manager works on a borrowed Mac OS X machine and compiles for the various targets. I see a few of the flashing tools (stlink and dfu-util) depend on the library libusb-1.0.0.dylib, which the test Mac does not have. I don’t have full-time access to this machine, so I wasn’t able to fix any of it.

Pushed a new version

Changes in 1.0.6
– Remove */libraries/LiquidCrystal_I2C/
– set the library category for STM32F1/libraries/TFT_ILI9163C (to silence the IDE warnings)

Thanks

I must get around to trying it, but I am rather time poor at the moment, mainly because of work.

I keep considering if we should have this as the official download, but I think everyone’s concern is that, having a non-techie way to install, would swamp the forum with silly questions, like “Why doesn’t this work on my STM32F103xxx board”

We see this sort of thing a bit at the moment, where for unknown config reasons, boards like the Blue Pill don’t seem to work with some Windows machines (as the USB doesn’t reset properly)

I noticed someone else had a W10 driver issue today, and I’m still not sure if that has been resolved.

But I see more and more of this on the horizon and I don’t like being rude to people by explaining this is not a commercial product and there is no guaranteed support and they are likely to have to find and fix the problem themselves, by reading the forum etc

maybe move all similar threads into a top level ‘Windows nn issues” with topics having prominent ‘SOLVED’ tags when resolved?
srp

RogerClark wrote:Thanks

I must get around to trying it, but I am rather time poor at the moment, mainly because of work.

I keep considering if we should have this as the official download, but I think everyone’s concern is that, having a non-techie way to install, would swamp the forum with silly questions, like “Why doesn’t this work on my STM32F103xxx board”

We see this sort of thing a bit at the moment, where for unknown config reasons, boards like the Blue Pill don’t seem to work with some Windows machines (as the USB doesn’t reset properly)

I noticed someone else had a W10 driver issue today, and I’m still not sure if that has been resolved.

But I see more and more of this on the horizon and I don’t like being rude to people by explaining this is not a commercial product and there is no guaranteed support and they are likely to have to find and fix the problem themselves, by reading the forum etc

Pushed a new version

Changes in 1.0.7
– uart fixes by stevstrong
– stm32flash_serial fixes by Jean-Claude Wippler
– support Nucleo w/o and w/ crystal by Jean-Claude Wippler
– delay() fix by Jean-Claude Wippler
– additional function updateSettings() to replace the call to begin() (SPI.cpp) by stevstrong
– added defines of external event selections for regular and injected groups (adc.h) by stevstrong

Fantastic

Thankyou

BTW. I have one outstanding PR I hope to get to this week, which is a fix for some USB issues.

However I’m so busy with work, I may not get around to it until next week

RogerClark wrote:
<…>
But I see more and more of this on the horizon and I don’t like being rude to people by explaining this is not a commercial product and there is no guaranteed support and they are likely to have to find and fix the problem themselves, by reading the forum etc

Changes in 1.0.8:

• rngkll – add defines for LEDS 3-8 on the stm32f4discovery
• rngkll – fix stm32f4/stlink upload for macos
• Pito – fix stm32f4 PWM on the stm32f4discovery’s LEDs

Guys

As it looks like IDE 1.6.9 may work with our existing files (the same files that work with 1.6.5), I am trying to build a boards manager package that will work for both 1.6.5 and 1.6.9, (but won’t work for 1.6.6, 1.6.7 and 1.6.8)

At the moment however, I can’t get the JSON file to work at all in 1.6.5 (nothing to do with the core files, its something to do with the json file causing a null pointer exception in the IDE – I guess something is missing)

Pito – fix stm32f4 PWM on the stm32f4discovery’s LEDs
Mind there is an another PWM bug for F4discovery – with pwm’s setPeriod() – the routine calculates with MCU clock frequency (it is ok with F103), but it shall do with MCU/2 with F407..

I think I would only have the F1 in the board manager package.

The F4 is not maintained by the community to the same level, so its best if people download manually to get it.

F3 support is even less than F4, and I almost feel like I should remove it completely, especially as the HALMX core probably now could supersede it.

Changes in 1.0.9:

major change notes: GD32F1 branch was merged into STM32F1, a new “fake” library has all the stm32 examples: A_STM32_Examples, and initial linux64 support was added

• WereCatf – Install udev-rules for ST-link
• Slammer – fix for issue with USB Serial on GCC 4.9
• WereCatf – Bugfix Adafruit_ILI9341_STM
• WereCatf – Update Adafruit_ILI9341_STM.cpp
• Roger Clark – Fixed broken URL to leaflabs docs
• Roger Clark – Changed defines for MOSI, MISO etc into const static vars, to address compatibility issues
• Roger Clark – Updated ‘category’ in library.properties files, to shop the IDE complaining that this key is missing
• Roger Clark – Added new file WCharacter.h, and updated String files to add missing Arduino API functionality
• Rick Kimball – fix compiler warnings related to __always_inline
• Roger Clark – Changed stm32f1 boards.txt to include vid and pid value for maple serial, so that the ‘Get Board Info’ feature shows all stm32duino bootloader boards as Maple mini.
• Roger Clark – Added experimental support for generic GD32F103C inside the STM32 tree
• Roger Clark – Added missing cpu speed menu for GD32
• Roger Clark – removed submodules TFT_ILI9163C, Ether_STM, stm32duino-bootloader
• Roger Clark – Add missing definitions for MISO etc to F4 core
• Roger Clark – Add recipe for ‘Export Binary’ feature
• Roger Clark – Tidied up platform.txt
• Roger Clark – Started to add linux 64 bit support
• Roger Clark – Added missing API functions microsecondsToClockCycles etc
• Roger Clark – Add dummy / shell library to allow IDE access to the examples
• Roger Clark – Moved examples to new dummy library item
• Roger Clark – Renamed MrBrunetteExamples to General examples, and removed boards.txt
• Roger Clark – Fixed issue with GD32 USB reset time being too short, and not enumerating on some PCs
• Roger Clark – Increase generic boards USB reset delay to fix issue with newer PC’s
• Roger Clark – Update README.md

Thanks Dan

I’ve been away at Maker Faire for the last 2 weeks (only getting home yesterday), so I’ve not had chance to work out the best way for me to generate these myself

Also…

I’ve realised that the repo doesnt work with Arduino.org’s version of the IDE as they have not incorporated any of the changes to platform.txt, and are effectively using the version of the IDE from back around V1.5.8 or some other version prior to 1.6.4 (possibly 1.6.3 or 1.6.2)

As Arduino.org are bringing out STM32 based boards, I can see this may become an issue, so I’ll need to work out a way to handle this.

It could be that I need to have a different branch for Arduino.org (which has a different platform.txt)

Looking on the bright side, it looks like 1.6.9 is fairly stable and in a few weeks I may merge the changes that are currently only in the development branch, which completely remove the compile warning in 1.6.9

But I’ll let the dust settle a bit longer on 1.6.9 and let more people move to it, before doing anything.

RogerClark wrote:
I’ve realised that the repo doesnt work with Arduino.org’s version of the IDE as they have not incorporated any of the changes to platform.txt, and are effectively using the version of the IDE from back around V1.5.8 or some other version prior to 1.6.4 (possibly 1.6.3 or 1.6.2)

As Arduino.org are bringing out STM32 based boards, I can see this may become an issue, so I’ll need to work out a way to handle this.

It could be that I need to have a different branch for Arduino.org (which has a different platform.txt)

Dan

I agree that usng a branch is problematic, but I think its only one file that needs to be different.

The only other way however would probably be to host the zip for arduino.org elsewhere and use a script to download the master version and make the small changes necessary to platform.txt and then re-zip it

It could be also a script that user execute after install to tweak the board.txt and/or plateform.txt.

Martin.

Good idea.

I wonder why Arduino.org have not updated thier IDE to match Arduino.cc’s version

IMHO They would be better off pulling a lot of changes from Arduino.cc’s version.

But I guess its hard to change this stuff without bringing in the whole of the Boards Manager

If i get chance I will email Angelo or Federico at Arduino.org and see what they have to say.

I’ve made a bunch of changes to my Board Manager generation. I’ve switched from my own branch of stm32duino to the official master branch. I’ve switched version numbers to a “YYYY.MM.DD” format. Because there have been so many changes, I’ve switched the URL to http://dan.drown.org/stm32duino/package … index.json The old URL has the old versions.

If you have the current board manager version installed, you’ll need to uninstall it before switching.

It’ll check for master branch changes every night and build a new package when it finds one.

I’ve posted the slightly modified tool to https://github.com/ddrown/Arduino_STM32_release_tools

Thanks Dan

Someone posted an issue about this on github yesterday, so perhaps he tracked your files down.

BTW. I’m not sure if you read the announcement but STM have produced their own core, complete with board manager package.

But it only supports Nucleo boards (and only 1 board per MCU series)

However we are hoping to be able to add the usual boards to it in the fullness of time. In which case we’ll almost certainly need to created an updated boards manager package.
So I’m probably going to need to get to grips with your Perl files to create the BM package for that core.

RogerClark wrote:Thanks Dan

Someone posted an issue about this on github yesterday, so perhaps he tracked your files down.

BTW. I’m not sure if you read the announcement but STM have produced their own core, complete with board manager package.

But it only supports Nucleo boards (and only 1 board per MCU series)

However we are hoping to be able to add the usual boards to it in the fullness of time. In which case we’ll almost certainly need to created an updated boards manager package.
So I’m probably going to need to get to grips with your Perl files to create the BM package for that core.

Hi Dan

Thanks

I still need to do a load more changes before we’re close to needing another release.

STM have put all the tools in the same folder, which is OK when they just supported one simple upload type (USB Mass storage) but not much use when we support multiple upload methods on multiple boards etc

So the boards manager package will need to generate different upload “Tools” for each OS

But, as we have quite a few issues with refactoring the STM core, I don’t think we’ll need to look at it for several weeks, if not longer

Thanks

Roger

I’m not sure if this is the right place for this, but I have just installed the latest Arduino.cc IDE (ARDUINO 1.6.12) 32 bit, and added Dan’s excellent board manager package.

Everything appears to work, except for this issue when I try to upload using my st-link adapter.
java.io.IOException: Cannot run program "/home/andrew/.arduino15/packages/stm32duino/hardware/STM32F1/tools/linux/stlink_upload": error=2, No such file or directory
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
at java.lang.Runtime.exec(Runtime.java:620)
at java.lang.Runtime.exec(Runtime.java:485)
at processing.app.helpers.ProcessUtils.exec(ProcessUtils.java:11)
at cc.arduino.packages.Uploader.executeUploadCommand(Uploader.java:129)
at cc.arduino.packages.uploaders.SerialUploader.uploadUsingPreferences(SerialUploader.java:206)
at cc.arduino.UploaderUtils.upload(UploaderUtils.java:78)
at processing.app.SketchController.upload(SketchController.java:707)
at processing.app.SketchController.exportApplet(SketchController.java:680)
at processing.app.Editor$DefaultExportHandler.run(Editor.java:2176)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException: error=2, No such file or directory
at java.lang.UNIXProcess.forkAndExec(Native Method)
at java.lang.UNIXProcess.<init>(UNIXProcess.java:248)
at java.lang.ProcessImpl.start(ProcessImpl.java:134)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
... 10 more
An error occurred while uploading the sketch


Andy

I have not removed anything from the github repo for ages, so the problem is likely to be in the compressed tool package for linux64, i.e it could be missing a file

Or its a path issue in platform.txt as the paths to board manager tools is different from the path if you use the repo

Or it could exist and isn’t a 64 bit executable. @ahull have you checked to see if it is a 32 bit executable? Do you have the 32 bit libs installed?

It is probably an issue with the board manager package in that case, the file is completely missing, although the mac_os and windows equivalents are there.

The mac os version is much simpler, as it doesn’t attempt to wait for the board’s USB serial port to re-enumerate, which is the purpose of all the extra (bloat?) code I added to the linux version.

It looks like this.
#!/bin/bash
$(dirname $0)/stlink/st-flash write "$4" 0x8000000


Rick Kimball wrote:Or it could exist and isn’t a 64 bit executable. @ahull have you checked to see if it is a 32 bit executable? Do you have the 32 bit libs installed?

I did a fresh install on a Linux Mint 64 bit system within the last couple of weeks using the boards manager method. I got the same errors about “no such file or directory” when trying to compile and upload.

I made a symbolic link to linux64 and it seems to allow the system to compile and upload to a board with the bootloader installed.
cd ~/.arduino15/packages/stm32duino/tools/stm32tools/1.0.9
ln -s linux64 linux


fredbox wrote:I did a fresh install on a Linux Mint 64 bit system within the last couple of weeks using the boards manager method. I got the same errors about “no such file or directory” when trying to compile and upload.

I made a symbolic link to linux64 and it seems to allow the system to compile and upload to a board with the bootloader installed.
cd ~/.arduino15/packages/stm32duino/tools/stm32tools/1.0.9
ln -s linux64 linux


It looks like some issue with the naming of the tools packages

The IDE does not seem to have a concept of Linux 32 vs Linux 64 at compile / upload time. i.e in platform.txt there is no way to run different binaries for 32 / 64

But the Boards Manager does know if you are on 64 or 32, so it downloads different tools packages based on your OS

Which means that for the BM version , the whole concept of sub folders under the tools folder,e.g. tools/win tools/linux tools/linux64 etc is redundant and the tools e.g. maple_upload, are supposed to be installed as separate platform dependent packages, so that the IDE just references the tool by name e.g. maple_upload and doesn’t care whether its windows or OSX or linux

(Actually I’m not sure how the bat vs the script name is handled, I guess in theory all the linux / osx scripts could be renamed to .bat so that this was not an issue, but I think what actually happens, is that platform.txt still detects which overarching platform you are using, and varies the script name based on that paramater, but linux and linux64 would have the same script name.

So..
I suspect @ddrown needs to change something in his perl script so that the linux64 folder is packaged as “linux” when he makes the linux64 tools package.

ahull wrote:fredbox wrote:I did a fresh install on a Linux Mint 64 bit system within the last couple of weeks using the boards manager method. I got the same errors about “no such file or directory” when trying to compile and upload.

I made a symbolic link to linux64 and it seems to allow the system to compile and upload to a board with the bootloader installed.
cd ~/.arduino15/packages/stm32duino/tools/stm32tools/1.0.9
ln -s linux64 linux


ddrown wrote:ahull wrote:fredbox wrote:I did a fresh install on a Linux Mint 64 bit system within the last couple of weeks using the boards manager method. I got the same errors about “no such file or directory” when trying to compile and upload.

I made a symbolic link to linux64 and it seems to allow the system to compile and upload to a board with the bootloader installed.
cd ~/.arduino15/packages/stm32duino/tools/stm32tools/1.0.9
ln -s linux64 linux


ahull wrote:
I don’t see 1.0.9a as an option in the Boards Manager, how do I access that? When I access the board manager, I do see these errors…
...
Invalid version found: 1.0.9a
Invalid version found: 1.0.9a
Invalid version found: 1.0.9a
Invalid version found: 1.0.9a
Invalid version found: 1.0.9a
Invalid version found: 1.0.9a
Invalid version found: 1.0.9a
Invalid version found: 1.0.9a
...


(facepalm) Stranger and stranger.

Invalid version found: 1.0.9.1
Invalid version found: 1.0.9.1
Invalid version found: 1.0.9.1


ahull wrote:(facepalm) Stranger and stranger.

Invalid version found: 1.0.9.1
Invalid version found: 1.0.9.1
Invalid version found: 1.0.9.1


Clearly I am very good at finding new and interesting ways to break this.

My 32 bit install is fine, but the 64 bit install is nicely broken.
If I remove and reinstall the board manager package, it *sometimes* works, but 99% of the time I end up with it broken.
When I select any of the STM32F103XX boards, maple, maple mini etc I see something like..

/home/ahull/PersonalApps/Arduino.cc/arduino-1.6.12/arduino-builder -dump-prefs -logger=machine -hardware /home/ahull/PersonalApps/Arduino.cc/arduino-1.6.12/hardware -hardware /home/ahull/.arduino15/packages -tools /home/ahull/PersonalApps/Arduino.cc/arduino-1.6.12/tools-builder -tools /home/ahull/PersonalApps/Arduino.cc/arduino-1.6.12/hardware/tools/avr -tools /home/ahull/.arduino15/packages -built-in-libraries /home/ahull/PersonalApps/Arduino.cc/arduino-1.6.12/libraries -libraries /home/ahull/Arduino/libraries -fqbn=stm32duino:STM32F1:genericSTM32F103C:device_variant=STM32F103C8,upload_method=DFUUploadMethod -ide-version=10612 -build-path /tmp/arduino_build_449201 -warnings=default -prefs=build.warn_data_percentage=75 -prefs=runtime.tools.arm-none-eabi-gcc.path=/home/ahull/.arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1 -prefs=runtime.tools.stm32tools.path=/home/ahull/.arduino15/packages/stm32duino/tools/stm32tools/2016.10.17 -verbose /tmp/untitled1190250828.tmp/sketch_oct18a/sketch_oct18a.ino

Board genericSTM32F103C (platform STM32F1, package stm32duino) is unknown

Error compiling for board Generic STM32F103C series.

ahull wrote:Clearly I am very good at finding new and interesting ways to break this.

My 32 bit install is fine, but the 64 bit install is nicely broken.
If I remove and reinstall the board manager package, it *sometimes* works, but 99% of the time I end up with it broken.
When I select any of the STM32F103XX boards, maple, maple mini etc I see something like..

/home/ahull/PersonalApps/Arduino.cc/arduino-1.6.12/arduino-builder -dump-prefs -logger=machine -hardware /home/ahull/PersonalApps/Arduino.cc/arduino-1.6.12/hardware -hardware /home/ahull/.arduino15/packages -tools /home/ahull/PersonalApps/Arduino.cc/arduino-1.6.12/tools-builder -tools /home/ahull/PersonalApps/Arduino.cc/arduino-1.6.12/hardware/tools/avr -tools /home/ahull/.arduino15/packages -built-in-libraries /home/ahull/PersonalApps/Arduino.cc/arduino-1.6.12/libraries -libraries /home/ahull/Arduino/libraries -fqbn=stm32duino:STM32F1:genericSTM32F103C:device_variant=STM32F103C8,upload_method=DFUUploadMethod -ide-version=10612 -build-path /tmp/arduino_build_449201 -warnings=default -prefs=build.warn_data_percentage=75 -prefs=runtime.tools.arm-none-eabi-gcc.path=/home/ahull/.arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1 -prefs=runtime.tools.stm32tools.path=/home/ahull/.arduino15/packages/stm32duino/tools/stm32tools/2016.10.17 -verbose /tmp/untitled1190250828.tmp/sketch_oct18a/sketch_oct18a.ino

Board genericSTM32F103C (platform STM32F1, package stm32duino) is unknown

Error compiling for board Generic STM32F103C series.

ddrown wrote:
Hm, I had seen something like this when I switched my local IDE from the 1.0.x branch to the 2016.x.x branch, but clearing the arduino15 folder and re-downloading the stm32duino package fixed it for me. I’ll see if I can recreate this and figure out what’s going on.

ahull wrote:Clearly I am very good at finding new and interesting ways to break this.

My 32 bit install is fine, but the 64 bit install is nicely broken.
If I remove and reinstall the board manager package, it *sometimes* works, but 99% of the time I end up with it broken.

I even resorted to removing and re-installing the ide and removing and re-creating the /home/ahull/.arduino15 folder.
I’ve run out of flat surfaces to bang my head against, so I thought I’d share my pain. Any ideas?

zmemw16 wrote:ahull wrote:Clearly I am very good at finding new and interesting ways to break this.

My 32 bit install is fine, but the 64 bit install is nicely broken.
If I remove and reinstall the board manager package, it *sometimes* works, but 99% of the time I end up with it broken.

I even resorted to removing and re-installing the ide and removing and re-creating the /home/ahull/.arduino15 folder.
I’ve run out of flat surfaces to bang my head against, so I thought I’d share my pain. Any ideas?

(facepalm) Finally I understand why this fails if I add the symlink.

/home/ahull/.arduino15/packages/stm32duino/hardware/STM32F1/tools/linux/maple_upload ttyACM3 2 1EAF:0003 /tmp/arduino_build_558946/STM32-O-Scope.ino.bin
java.io.IOException: Cannot run program "/home/ahull/.arduino15/packages/stm32duino/hardware/STM32F1/tools/linux/maple_upload": error=2, No such file or directory

just to check what i thought was correct, i googled >(facepalm)<; the images returned are interesting
srp

In summary there are two problems.

First, if you install the staging package, then the release package, we end up with two packages, and the IDE gets confused.

Second, the upload methods point to …

$PATH/.arduino15/packages/stm32duino/hardware/STM32F1/tools/linux/{TOOLNAME}

But they should point to …

$PATH/.arduino15/packages/stm32duino/tools/stm32tools/{VERSION}/linux64/{TOOLNAME}

or

$PATH/.arduino15/packages/stm32duino/tools/stm32tools/{VERSION}/linux/{TOOLNAME}

or better still

$PATH/.arduino15/packages/stm32duino/tools/stm32tools/{VERSION}/linux{PROCESSOR_BITS}/{TOOLNAME}

… where {VERSION} , {TOOLNAME} and {PROCESSOR_BITS} are assumed to be variables in the build script.

If the tools all run on both 32 and 64 bit, we could simplify to…

$PATH/.arduino15/packages/stm32duino/tools/stm32tools/{VERSION}/linux/{TOOLNAME}

ahull wrote:In summary there are two problems.

First, if you install the staging package, then the release package, we end up with two packages, and the IDE gets confused.

Second, the upload methods point to …

$PATH/.arduino15/packages/stm32duino/hardware/STM32F1/tools/linux/{TOOLNAME}

But they should point to …

$PATH/.arduino15/packages/stm32duino/tools/stm32tools/{VERSION}/linux64/{TOOLNAME}

or

$PATH/.arduino15/packages/stm32duino/tools/stm32tools/{VERSION}/linux/{TOOLNAME}

or better still

$PATH/.arduino15/packages/stm32duino/tools/stm32tools/{VERSION}/linux{PROCESSOR_BITS}/{TOOLNAME}

… where {VERSION} , {TOOLNAME} and {PROCESSOR_BITS} are assumed to be variables in the build script.

If the tools all run on both 32 and 64 bit, we could simplify to…

$PATH/.arduino15/packages/stm32duino/tools/stm32tools/{VERSION}/linux/{TOOLNAME}

I just tried a test sketch on both the 32 bit machine and the 64 bit one and that appears to have done the trick.
I didn’t have a board to hand to test with, but it calls the correct upload methods on both platforms, and we get the correct error from the upload binaries as a result of them being unable to connect to the selected board.
I’ll do more in depth testing, this time with a board attached. when I get some spare time, but that does appear to have resolved the issue.
Thanks.

High five from the bear.. it works!
Just uploaded a sketch via stm32bootloader and ST-Link and it works perfectly.

I recently purchased a NUCLEO-F070RB board with the Arduino UNO connectors on the board, but I have yet to find an Arduino board support package for it. Does one exist? If not, is it relatively easy to port an existing support package?

this isn’t a board manager issue. please ask in new thread. You are looking for an stm32f0 core.