Using CubeMX HAL inside Arduino IDE

Hi,

I am somewhat confused. I found the repo at https://github.com/sheepdoll/HALMX_Arduino_STM32.

When I read the line “HALMX is a variation of Arduino_STM32” in the readme, I initally drew the conclusion that this repo can be used within the Arduino IDE, and use the CubeMX HAL inside the Arduino IDE to program different boards. I hope this is true, because that is exactly what I would like to do…

If so, how do I actually install this? The instructions in the docs in the aren’t very clear to me.

Or is this repo meant to enable the usage of Arduino functions withing CubeMX (hence bypassing the Arduino IDE…)

Cheers,

David

David,

STM32duino was originally spawned from a 176 page large thread on Arduino.cc … the initial platform was the clone Maple Mini. The original code base was the public open source (and abandoned) LeafLabs.com libmaple and pre-Arduino 1.0 core files.

A great effort of sweat generated the ArduinoIDE 1.5+ compatible core. libmaple is still used in this sense. Original documentation can be found in the “Resources” section of this page: https://www.leaflabs.com/maple

Prior to 18 months ago, a number of members desired to morph a codebase using the official STM CubeMX/HAL. Various attempts ensued and Sheepdoll was one of the out-in-front and aggressive members. To my knowledge all of these efforts have gone stale.

18 months ago, STM offered to come in and build an Arduino version for their official line of Nucleo Boards. This effort was successful and we have an STM employee that is supporting and evolving same. This codebase is supported in a couple of sections of this forum.
You should therefore utilize the supported codebase from here: https://github.com/stm32duino/Arduino_Core_STM32

I would strongly suggest you stay away from other github code bases as you will be supporting yourself in that event… unless Sheepdoll comes out of hiding (she is very busy and engaged in numerous projects) and decides to offer you some tidbits of her time.

Ray

That’s a pretty clear advice. Thanks.

Cheers,

David

file under ‘to be investigated’ when you acquire a stm32f4xx board is perhaps better.
Steve Strong has a F4 libmaple core that seems to have a following, there are a couple or three HAL based ones, subject to a low update rate currently, but that i attribute to perhaps a measure of stability.
srp

I have played with this core recently, and compared with others (though not Sheepdoll’s). Roger’s STM32_Arduino is still good for Mapleleaf, but limited beyond that. STM32GENERIC was also based on HAL but does not seem to be supported any more. It produces a lot of compiler warnings, which I don’t like, but it works at least as far as a blink test.

STM32_Core_Arduino seems to be the most comprehensive to date (it has two layers of menus to select a board), and “cleanest” in that it produces few compiler warnings. The fact that it seems to be supported is a major plus! I hope this continues. So I am a fan already.

A limitation is that it only supports ST boards, not Chinese clones like my DIYMROE (yes, spelled like that) STM32F407VGT board (see elsewhere on this forum). One small extra I would like is an option to select an embedded chip as an option (a.k.a. bare board). I am currently working with an STM32F103C8T chip on a breakout board on a breadboard, with my own ceramic resonator and power supply, hand-wired STLink, reset, USB, and a Led for blinking. There is a “Generic STM32F101 Series” option, but the only sub-option at the moment is “Blue pill”, which is not exactly the same as I have. I would like a similar option for the F4 series. If nothing else, such an option could be used as a catch-all for all boards that are not otherwise supported. It would simply mean that the user would have to define items like LED_BUILTIN.

Regards,
Andy

[AndySymons – Wed Nov 14, 2018 6:17 pm] –
… One small extra I would like is an option to select an embedded chip as an option (a.k.a. bare board). …

As if testing the current core on 3 OS platforms with more than 10 32 ST quality manufactured development boards isn’t tedious enough.

A big “-1” from me.

AndySymons wrote: One small extra…

[AndySymons – Wed Nov 14, 2018 6:17 pm] –
…
A limitation is that it only supports ST boards, not Chinese clones …
…
Regards,
Andy

Andy,

STM has made allowances for end-users to adapt the Official Core to most anything STM:
https://github.com/stm32duino/wiki/wiki … nt-(board)

I don’t expect Intel to support every notebook that uses an Intel CPU, it is not practical. STM has created a Swiss-Army-Knife of a product in the STM32_Arduino Core.

From a housekeeping prospective, I usually recommend not responding to threads over 6 months old …. there is simply too much that changes in 180 days. Let sleeping threads sleep.

Ray

Perhaps I muddled my wording a bit, but if you read what I said carefully I did not ask STM to support boards they don’t make, I simply said that it is a limitation.
Overall I was speaking in favour of this core!
What I did suggest is that they offer an option for just the chip on its own, not on a board at all. That clearly is an ST product and could be supported (as they do in STMCubeMX).

I actually have already made my own board definitions and variants for both my Chinese board and the “embedded” option. However I did it by copying the entire core and deleting what I did not need to make a new core. It is thus not updated when STM updates their core. It looks at though the solution you pointed to would allow me to integrate my custom part with the existing core and thus keep me in step with the latest version. I thank you for that. I’ll give it a go.

Cheers,
Andy

[AndySymons – Wed Nov 14, 2018 6:17 pm] –
A limitation is that it only supports ST boards

This is a wrong limitation. The core support all STM32 based boards (except H7 at this time).
There are several non ST manufactured boards in the core:
BluePill F103C8 (Basic support, no USB)
MapleMini F103CB (Basic support, no USB)
Black F407VET6
Blue F407VET6 Mini
RAK811 LoRa Tracker (Basic support)
RemRam v1

and in the next release:
STM32F030F4 Demo board
Armed V1

I am not really hiding. Just have not had much to contribute lately. I still check in daily.

My Git was a proof of concept, which others were able to add value to. It showed it was possible to call the HAL code from the Arduino IDE. As noted with the release of the official core many of these early efforts have fallen by the wayside. This is a good thing as it shows the value of the contributions of the group as a whole.

As I was debugging inside the Eclipse IDE, with openOCD, I have moved more in that direction, which is outside the scope here.

1. fpiSTM is right, there are also non-STM boards included in the Arduino_Core_STM32 package.

2. Ray’s link is very useful. There are very clear instructions about how to add another board within the Arduino_Core_STM32 package. I got mine working in less than half an hour. This method keeps the new definition within the existing core, so you do not need to implement your own core (as I had previously). However, it it not entirely clearly to me what happens when STM issues an update through Boards Manager. Could some of the changes be lost?

So we all seem to agree that Arduino_Core_STM32 is now the best core for most purposes!

3. One small niggle is that the HAL-based systems apparently assume Microsoft naming; on a Mac you get an error message if you use space, dollar — or other special symbol that is allowed by Mac but not by Microsoft — in any folder or file name in the path to your sketch. This does not happen when selecting an Arduino_STM or a standard ARM Arduino board. It does also happen with STM32GENERIC (which is also HAL-based).

The message is a ‘bash’ error when compiling, with a message like ‘too many arguments’ or ‘binary operator expected’. This does not stop compilation and may not matter at all (?), but is a little messy. The simple workaround is to remove special characters from all file and folder names in the path to your sketch.

I traced the problem to a line in platform.txt:
recipe.hooks.prebuild.1.pattern.macosx=bash -c “[ -f {build.opt.sourcepath} ] || (mkdir -p {build.path}/sketch && touch {build.opt.path} )”

I am not a scripting expert, but I guess a solution would be quoting the file name; however, I have not figured out how to do it here as quoting is already used. Can quoting be nested? Or am I barking up the wrong tree in the first place?

Regards,

Andy

Those line is a pre build hook, which is call before the build. On windows there is no solutions if path contains space or special character. Maybe on mac this could be fixed. If you have a fix do not hesitate to share but As the path is handled by Arduino ({build.opt.sourcepath}) I guess this could be hard to fix.
Other cores do not have this issue as they do not use this feature.

More info about this: https://github.com/stm32duino/wiki/wiki … uild_opt.h

Once in an alternate reality, I was a MCSE. I left Windows in the 8.1 days.

However, you should be able to create a symbolic link for the location path with offending spaces.

You can also investigate the subst Windows command.

Ray

[fpiSTM – Fri Nov 16, 2018 5:37 am] –
… If you have a fix do not hesitate to share but As the path is handled by Arduino ({build.opt.sourcepath}) I guess this could be hard to fix.

I would add a bash command in the tools directory tools:

$ cat tools/linux/touch_opts
#!/bin/bash
set -x
[ -f "$1" ] || (mkdir -p "$2" && touch "$3" )


Thanks Rick but I wouldn’t add a script.
Thinking about that maybe quoting should be enough for Linux and MAC. I Thought about windows when I wrote my answers…

You should add the quoting, it is broken on linux. I unsuccessfully tried a variety of approaches to fix this without using a script. I’d love to see how to fix this properly.

On Nov 14, 10:21 Ray supplied a very useful link to instructions on how to add new boards or variants to ST’s Arduino_Core_STM32: (https://github.com/stm32duino/wiki/wiki … 28board%29). The instructions are very clear, but they do not state what happens when there is an update. I therefore did a test today and confirmed my fear that if you update Arduino_Core_STM32 using Boards Manager, the old version, including all the custom modifications you made, is erased.

There are several options to avoid this, none of which is particularly attractive:

• Don’t do any updates. It’s not automatic, so if you do not press the update button in Boards Manager, the old version will remain indefinitely.

• Keep a back-up somewhere of the customised files, i.e. boards.txt, and the variant folders you added. After doing an update in Boards Manager, recover or re-update boards.txt by hand and re-introduce the variant folders.

• Instead of installing Arduino_Core_STM32 using the Boards Manager, download the files from https://github.com/stm32duino/Arduino_Core_STM32, unzip them and put them in a folder in your …/Arduino/hardware directory. Note that boards.txt must be two levels down from …/Arduino/hardware. This will isolate the definitions from Boards Manager and prevent accidental erasure. Of course, if you also install Arduino_Core_STM32 using Boards Manager, you end up with two sets of definitions.

• Install Arduino_Core_STM32 using Boards Manager in the usual way, and do not edit it; you can use automatic update at will. Copy Arduino_Core_STM32 to a new folder structure, Arduino_myCore_STM32, say. Give it a different name (in platform.txt) so you can find it in the boards menu. Adapt this copy according to the instructions in https://github.com/stm32duino/wiki/wiki … 28board%29. Then delete all the boards and variants that you do not need, because you still have those in the original Arduino_Core_STM32. If there is an update to Arduino_Core_STM32, it will work for all boards except your specials. For those, you will have to re-copy all the files to Arduino_myCore_STM32 except for boards.txt.

Whichever of these you use, it amounts to an awkward manual merge of new and old code, with a risk of errors or unexpected compatibility issues. What we could do with is an include-like instruction in boards.txt that has the effect of including one or more board/variant definitions from separate user-defined boards.txt sub-files and variant files in a separate folder structure that Boards Manager will not erase. I don’t think anything like this already exists, does it?
Good luck!
Andy

This is how Arduino handles the update, it purely removes the directory then extract the new one. Theoretically, user should not modify core.
To avoid this you have several possibilities:
1 – Use git repo then fetch it to get the latest update this allow you to also locally commit your changes. Ideally do it on a fork.
https://github.com/stm32duino/wiki/wiki … repository
2 – Better, you can provide a PR to merge your change in the repo.
3 – Create your own package using the core like tomvdb do:
See:
https://github.com/stm32duino/Arduino_C … /issues/67
https://github.com/tomvdb/edubot_arduin … index.json
https://github.com/tomvdb/edubot_arduin … ds.txt#L21

Thanks for those extra suggestions! 1 and 2 presumably require the changes to be fully tested and either supported by the author (1) or by ST (2). I am not quite at that stage yet for 1, either in testing of my changes or in experience with github. I do not know if ST would accept 2, a PR, though it would be great if they did! That would indeed be the best long-term solution. fpiSTM, is it you that represents ST? If so, perhaps you can point me to the PR procedure…
I think 3 is essentially the same as my last bullet.
Regards, Andy

Yes I’m working for ST and maintains the core.
The core is open source and all contributions are welcome.
Several boards were already provided by contributors.
If you are not comfortable with git, you can create an issue and provide as attachment the zip file for you variant then I will create the PR.

Option #4:

Use the stm core but create your own core directory that references it. All you need in the directory is a simple boards.txt, platform.txt and variant directory containing your variant differences.

Read the section “Referencing another core” in:
https://github.com/arduino/Arduino/wiki … cification

Referencing another core, variant or tool

Inside the boards.txt we can define a board that uses a core provided by another vendor/mantainer using the syntax VENDOR_ID:CORE_ID. For example, if we want to define a board that uses the “arduino” core from the “arduino” vendor we should write:

[….] myboard.name=My Wonderful Arduino Compatible board
myboard.build.core=arduino:arduino
[….]

This allows you to update the ST core without destroying your own. You get the best of both worlds. You can edit your own version to your hearts delight but you get the latest fixes and updates the ST core makes.

Thanks Rick’ in fact this is what I would tell with option 3, this is what tomvdb do

Yes, thanks Rick. I didn’t know that, and it does indeed look like the best way of adding own definitions without defining a whole new core. As fpiSTM says, it is distinct from and better than my option 3. Perhaps the instructions on github could be updated to reflect this?

I would like to raise some more questions about own definitions of boards, especially around the way pin numbers are defined and used. Is this the appropriate place to do that? Or is there a specific part of this forum for Arduino_Core_STM32 issues? Actually we could do with a thread for board definitions, a thread for the Arduino core, and another for tools!

I guess you should open a new thread here:
http://stm32duino.com/viewforum.php?f=48

[fpiSTM – Tue Nov 20, 2018 5:50 am] –
Thanks Rick’ in fact this is what I would tell with option 3, this is what tomvdb do

Sorry fpiSTM, I saw the words “create your own package” and I thought it was talking about making a new json file and I really didn’t click on the link.

Yes, tobmvdb is doing the same thing I suggested. He is being much more thorough and taking it to its full conclusion. What I was suggesting is more limited. It is meant for someone who just wants to use your core but apply their own custom board changes for their personal setup. I wish I knew about this approach a couple of years ago, I would have created my own custom bluepill board core for Roger’s code. It would have saved me a lot of hassle.

I am trying to make my own board definition that refers to Arduino_Core_STM32 using the instructions at https://github.com/arduino/Arduino/wiki … cification as Rick suggested. Unfortunately, the instructions do not say where to find VENDOR_ID and CORE_ID for the statement myboard.build.core=VENDOR_ID:CORE_ID. Does anybody know?

I assume CORE_ID is “arduino” because that is what it is in the original; but what is the VENDOR_ID?

I tried several guesses based on directory names, or the name given in platform.txt but none work. When I select the board from the Arduino IDE (after restarting it), I get an error message of the type
“The current selected board needs the core ‘STM32:arduino’ that is not installed”

Can I refer from a boards.txt defintion in Arduino/hardware to a core that is installed as a package (/Users/<myname>/Library/Arduino15/packages)? The directory structure in packages is different form that in Arduino/hardware, but the github instructions seem to assume everything is under Arduino/hardware?

VENDOR_ID in this case is “STM32”, core is “arduino”. For my custom core, i used ‘kimballsoftware’ in $HOME/Arduino/hardware/kimballsoftware/stm32. In that directory, I put the boards.txt, platform.txt, and variant directory. The boards.txt references STM32: in several entries.

On linux using the stm32duino json file and the Board Manager menu item for stm32, it installs the package in $HOME/.arduino15/packages/STM32

On Windows, I don’t really know but I thought it was somewhere in C:\Users\{user}\AppData\Local\Arduino15\

I’m not sure how using something under your (/Users/<myname>/Library/Arduino15/packages) would work? Why not just use the json file and let the board manager install in the normal fashion?

Here is my platform.txt:
# CUSTOM STM32 ARM Core and platform.
# ------------------------------
#
# For more info:
# https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5-3rd-party-Hardware-specification

name=STM32 Boards (kimballsoftware)
version=1.0.0

Rick,
That was indeed my first guess, and as far as I can tell I am doing exactly the same thing as you. This is on Mac OSX. My path is ~/Arduino/hardware/a3_core/stm32core/boards.txt. The same folder contains two variant folders and a platform.txt file.
The error message is The current selected board needs the core ‘STM32:arduino’ that is not installed.
The core clearly is installed because I can select boards from it. It was installed by Boards Manager so is at location ~/Library/Arduino15/packages/STM32/hardware/stm32/1.4.0.
I’d be happy to share the code here, but have not yet figured out how you insert it!
The key line is
GenF1.build.core=STM32:arduino

[AndySymons – Thu Nov 22, 2018 9:07 pm] –
path is ~/Arduino/hardware/a3_core/stm32core/boards.txt.

From the “Arduino IDE 1.5 3rd party Hardware specification”:

a3_core – the first level is the vendor/maintainer
stm32core – the second level is the supported architecture

The STM32:arduino package has an stm32 architecture. Because you called your architecture ‘stm32core’, I think the arduino builder is going to look in packages for the STM32 vendor directory for a directory named ‘stm32core’ and not find it. Try renaming your arch directory from ‘stm32core’ to ‘stm32’

Edit: I actually tried changing my working example from ~/Arduino/hardware/kimballsoftware/stm32 to ~/Arduino/hardware/kimballsoftware/stm32core. It broke the build. I get the same message as you when I try to compile:

“The current selected board needs the core ‘STM32:arduino’ that is not installed.”

Rik,

I find this rather confusing. I did not read into the instruction the second level is the supported architecture that this in any way had to match the directory I want to refer to in the core. Indeed, I chose a different name because I thought otherwise it might confuse the IDE and cause it to look in the wrong place. Nevertheless, I made the change and re-compiled it, and it worked!

However, I then had a new error message /Users/<usrename>/Library/Arduino15/packages/STM32/hardware/stm32/1.4.0/system/Drivers/STM32F1xx_HAL_Driver/Inc/stm32f1xx_hal.h:46:32: fatal error: stm32f1xx_hal_conf.h: No such file or directory
#include “stm32f1xx_hal_conf.h” The file is there in the variant folder, so I concluded there must be something wrong with the link back from the core to the new external variant.

In the spirit of experimentation, I then capitalised the folder name i.e. changed it from stm32 to STM32, so that it exactly matches that in the core. That fixed that problems as well!

I have arrived there by experimentation, but I do not understand fully how the system is working. The instructions need to be made a lot clearer.

Thanks for helping !

Andy

[AndySymons – Fri Nov 23, 2018 7:59 pm] –
In the spirit of experimentation, I then capitalised the folder name i.e. changed it from stm32 to STM32, so that it exactly matches that in the core. That fixed that problems as well!

I can imagine it working for someone running Windows using a case-sensitive file systems. You got lucky and got an error now instead of having to try and figure out why someone else didn’t work. I think you are the perfect person to write up what you think the instruction are I arrived here by trial and error too. It is hard to imagine all the different scenarios that would cause you to fault.

I’ll try to put up my example customized bluepill on github in the next couple of days after some more testing. However, I’m not going to make sure it works on Windows or OSX.

Edit:
sample bluepill core here: https://github.com/RickKimball/vendor
and an avr example https://github.com/RickKimball/mightyohmex that uses something other than an arduino core.

Can anyone edit the github text? Or should we put instructions on this forum?

Thanks for the compliment, but though I could write up what I did, I am really only speculating about how it works exactly; so what I say might be misleading in different circumstances. It would be better if someone who built it gave more information.

Andy

[AndySymons – Sat Nov 24, 2018 2:14 pm] –
Can anyone edit the github text? Or should we put instructions on this forum?

Probably the best place for this information would be in the stm32duino wiki.

[AndySymons – Sat Nov 24, 2018 2:14 pm] –
.. I am really only speculating about how it works exactly ..

Welcome to our club, that is what we are all doing

@AndySymons let me know if the README.md https://github.com/RickKimball/vendor here is sufficient.

Rick,

Nice.

Ray

Rick, yes that is an excellent example of how to do it, though I remain curious as to why it works — i.e. how exactly the links backwards and forwards are made. That information would useful for debugging when it doesn’t work!

Though platform.txt is optional, I would recommend using it; if only to name the sub-menu that contains the new boards; otherwise they might be hard to find in the IDE.

I certainly think this a powerful feature that needs a high profile on this site — the ability to add a custom board to an existing core; modifying the minimum necessary and therefore not taking over responsibility for code other than one’s own. Thanks for that!

Cheers,

Andy

[AndySymons – Sun Nov 25, 2018 8:17 pm] –
Rick, yes that is an excellent example of how to do it, though I remain curious as to why it works — i.e. how exactly the links backwards and forwards are made. That information would useful for debugging when it doesn’t work!

Did you read this documentation? https://github.com/arduino/Arduino/wiki … cification

What in there is fuzzy?

Yes, that’s where I started, following a tip from you! What’s not explained — fuzzy — in that document is the whole conversation we just had about where the names of VENDOR_ID and CORE_ID come from.

1. Under the title Hardware Folders structure, the folder structure is described as “hardware/<vendor>/<architecture>”. This is only correct for cores added by hand into the folder Arduino/hardware, not for those installed by Boards Manager.
2. The structure for cores installed by Boards Manager is different and not described at all. By inspection it appears to be something like /Users/<username>/Library/Arduino15/packages/<architecture>/hardware/<something else>/<version>/
3. Under the title Referencing another core, variant or tool is the instruction to “use the syntax VENDOR_ID:CORE_ID”. There is no clue as to what is meant by CORE_ID there or (as far as I can tell) in the rest of the text above. If VENDOR_ID means the same <vendor> mentioned above, then it is plain wrong.

By my analysis (if I got it right), we need the following changes to remove the fuzz:
1. Under the title Hardware Folders structure: The folder structure for new board definitions installed by hand is Arduino/hardware/<vendor>/<architecture>/cores/<core_id>
2. (same section) The structure for cores installed by Boards Manager is /Users/<username>/Library/Arduino15/packages/<architecture>/hardware/<something else>/<version>/cores/<core_id> (in fact core_id is always “arduino”)
3. Under the title Referencing another core, variant or tool: use the syntax <architecture>:<core_id> (nothing to do with vendor)
4. (same section). The new variants must be placed in a folder named Arduino/hardware/<yourname>/<architecture>/… where <yourname> is anything you like, but <architecture> must exactly match, including the case, the name of the architecture used in the core to which you refer (see 2).

You might go and refresh my README.md to see if my modifications addressed your questions combined with the answers below. However, I see most of your questions are focused on the 3rd party hardware specification. Let me see if can answer them.

[AndySymons – Sun Nov 25, 2018 10:14 pm] –
Yes, that’s where I started, following a tip from you! What’s not explained — fuzzy — in that document is the whole conversation we just had about where the names of VENDOR_ID and CORE_ID come from.

1. Under the title Hardware Folders structure, the folder structure is described as “hardware/<vendor>/<architecture>”. This is only correct for cores added by hand into the folder Arduino/hardware, not for those installed by Boards Manager.

True, the board manager has added version numbers so you can install specific versions.

[AndySymons – Sun Nov 25, 2018 10:14 pm] –
2. The structure for cores installed by Boards Manager is different and not described at all. By inspection it appears to be something like /Users/<username>/Library/Arduino15/packages/<architecture>/hardware/<something else>/<version>/

True, and not documented that I have found.

From a board manager package install it looks like this:
/Users/<username>/.arduino15/packages/STM32/hardware/stm32/1.4.0/boards.txt
STM32 == vendor
stm32 == architecture {build.arch}
1.4.0 == version number
{build.platorm} in this case becomes /Users/<username>/.arduino15/packages/STM32/hardware/stm32/1.4.0

For $HOME/Arduino/hardware it is $HOME/Arduino/hardware/STM32/stm32/boards.txt
{build.platorm} in this case becomes $HOME/Arduino/hardware/STM32/stm32

The <something else> in your path above is explained here, again STM using the name ‘STM32’ as the vendor name causes a lot of confusion:
README.md wrote:The directory name ‘stm32’ identifies the architecture of this core. The architecture name is an arbitrary value however the arduino builder uses to set the global {build.arch} variable. When you reference other vendors cores like we are doing here the {build.arch} determines which architecture is used in the referenced core. Library files also use the {build.arch} setting to see if they are compatible.

Well, I think I made the point that it is not clear!!

I do not mind which item is called “vendor” and which is called “architecture”, but it has to be consistent. I continue this narrative on the assumption that STM32 is the “vendor” and stm32 the “architecture” as you described in relation to the library path (which was not previously available).

You are right that ST confuses the issue by using STM32 as the vendor; “ST” would have been better. To verify the distinction, I tried changing the name by hand in the library path and my boards.txt file. It did not work (“core not installed”), but that may be because the installation puts the vendor name elsewhere too?? Dunno. So I put it back to STM32.

I then tried changing the STM32 in my $HOME path to ‘stm32’, so that I have $HOME/hardware/<myname>/<architecture> as described at the top of the README (<myname> being equivalent to vendor, I assumed). boards.txt is using STM32 as the vendor. Once again this allowed the board to be selected in the IDE (it found the core), but compilation failed when including the variant. So I think I confirmed that the $HOME path has to be $HOME/hardware/<myname>/<vendor>, where <vendor> matches the name of the vendor in the library, and not $HOME/hardware/<vendor>/<architecture> as described at the top of the README!

Of course you are right that $HOME does not have to be called Arduino, that is just the default.

Regards, Andy

In all those discussions you forgot that Arduino use the JSON file to know what is installed or not:

Vendor:
https://github.com/stm32duino/BoardMana … ex.json#L4
Arch:
https://github.com/stm32duino/BoardMana … x.json#L14

So even if you change in the boards.txt and the path Arduino always use the JSON input.
I know vendor “STM32” is confusing, this was already discussed, this is legacy issue since first delivery from Wi6labs.
As the core is open source, for the community and available on stm32duino GitHub organization, STM or ST is not the the right choice (moreover it does not support only ST boards). I think “STM32duino” should be better.

[fpiSTM – Mon Nov 26, 2018 7:55 am] –
In all those discussions you forgot that Arduino use the JSON file to know what is installed or not:

Thanks @fpiSTM. You are right, those json file references are a much better place to derive the vendor name and architecture than what I suggested.

I’m not sure that “stm32duino” would be the best vendor name. When I think of stm32duino, I think of the leaflabs core this site was started to support. Maybe that is just because I was here from the start. Do you have any plans for changing the vendor name in the json package? I do have one suggestion about the “help” link in the json file. Maybe it should be pointed to the “STM Core” subsection of the forum instead of pointing generically at the top.

“help”, “www.stm32duino.com/viewforum.php?f=48”

This change might produce less confusion about the right place to ask questions and get answers.

Does STM plan to take over the stm32duino.com domain at some point?

I don’t think ST will take over the domain name (that is my personal opinion and not engage ST )
About updating the JSON, this will raised an issue when user would like update because I guess the menu will appears twice (one for the STM32/ (old name) and one for the new vendor name)

About STM32duino name, I understand you. Anyway for many people it is also all stuff related to STM32 in Arduino.
Later, JSON could be extend to propose other core for the same name:
arch: stm32 (Arduino_Core_STM32)
arch: stm32f1 (Arduino_STM32/STM32F1 from Roger)
arch: stm32f4 (Arduino_STM32/STM32F4 from Roger or Steve…)
….

fpiSTM,

Thanks for the json info. That clarifies a lot.

I agree with Rick, the name STM32duino has a branding track record with this site and an association with the original Roger Clark Core (Arduino_STM32). Roger also uses the name on GitHub — https://github.com/stm32duino (though it links to your Core as Arduino_Core_STM32). As you are not proposing to take over this forum, it would be therefore confusing.

I would support the use of ST or STM as vendor name because it correctly represents the maker of the core, and of course the chips on the boards, if not the boards themselves. It would raise the profile of ST as a company and lend legitimacy to the core as being the ‘official’ ST core. That adds a lot of trust! You don’t need to add ‘~duino’ because you already have ‘arduino’ as the architecture.

You can best judge if maintenance is most easily managed by subdividing the product range (STM32F1, STM32F2 etc. as you suggest). I would be happy to have everything in one menu, but it is not a big deal as long as the sub-menus have clear names (I am comfortable with Roger’s next to yours). Since there is now a way of adding custom boards to your standard core, we can always make our own additions and publish them separately through GitHub as very small packages.

Cheers. Andy.

As I said it is my personal opinion. ST has ST community so no reason to admin an other site.
ST join STM32duino community to contribute and never want take the lead.
The Arduino_Core_STM32 is not ST core, it is supported by ST which is not the same thing.
Roger give ST (me) access to STM32duino GitHub organization to provide the core implementation and libraries as it do not use it.
I know I’m the main maintainer, anyway as said regularly any contribution is welcome and hope to get more contributors and why not maintainer.

You do not understand my thought about the JSON. This is not a subdivising. I talk about release the other core in the same JSON file or splitted JSON file with the same name (vendor or maintainer). This is only my thought to easily install one or more “STM32duino” cores easily.
As I said before, you forgot to take in account how Arduino IDE handle core installation and board manager stuff and we are not responsible how it does that.

Yes, I confess I am not very competent in the Arduino installation method, so I will shut up about that — other than to say it sounds like you have a good idea to give newcomers and established users a way of installing “the best of STM32 cores” in one go.

I do not feel very strongly about the name either. My main concern was that having the same name for both the vendor and the architecture (apart from capitalisation) is rather confusing. “STM32duino” would not be so bad if Roger is OK with it (so Github, this forum and the core are consistent) and if you are including the other packages you mentioned anyway.

Thanks for your constructive thinking on this and good luck!

Andy