List of cores currently available

Arduino STM32
https://github.com/rogerclarkmelbourne/Arduino_STM32

This is the main repo that people on this site are using. However its just one of a number of different “cores” that allow the Arduino IDE to compile for STM32.

Advantages

• Works with Maple mini including being compatible with the Maple / USB bootloader
• Works with IDE 1.6.3 +
• Has a long history and most bugs have been sorted out.

Disadvantages

• The original code was written in around 2011 and does not use STM’s own standard headers and the Standard Peripheral Library. This means adding new hardware functions e.g. CAN Bus or I2S are harder as they need to be coded from scratch. (STM’s own code was not available for F103 until the start of 2015)
• Harder to port to other processors like the STM32F4 because all code needs to be written, rather than being able to use code written by STM

Arduino STM32 is a derivative of libmaple, (https://github.com/leaflabs/libmaple) which was first developed by LeafLabs for their Maple and Maple mini boards. LibMaple was written in 2012 and only supports the Arduino 0022 API (pre Arduino 1.0).

LibMaple and hence Arduino STM32 only support the STM32F103 series of processors, however various other groups have build modified versions, including the AeroQuad team who did a port of the original LibMaple to the STM32F4 processor
This is the port of LibMaple which is in the Arduino STM32 repo

There have been many other ports / updates to libmaple, but as far as I’m aware Arduino STM32 is the only one which is active at this time and supports the Arduino 1.0 API

MakerLabMe

https://github.com/MakerLabMe/STM32_Arduino_Cores

This appears to be a totally independent implementation of an STM32 core for the Arduino IDE.
I did try to contact the author in December 2014 but didn’t get a response.
But there does appear to be recent work in this repo.

This code seems to use code from ARM holdings and not specifically code from STM.
The license on these files is unclear

One advantage that I can see is that perhaps the F4 core provides Arduino 1.0 API support

Unfortunately it looks like last download is targeted at Arduino 1.5.8, and the only STM32F103 boards that are listed are produced by MakerLabMe

I’m sure it would be possible to build variants and change the boards.txt to support other generic boards.
I will need to do a test build as they boards seem to have support for USB, but I’m not sure how that works.

Koduino

https://github.com/avikde/koduino

Koduindo is written by Avik De. Its another independent core, but draws some ideas from libmaple.

Advantages

• Uses headers and c code from STM themselves (CMSIS and STD Peripheral Libs)
• Should be easier to port to other STM32 processors and add new hardware e,g, CAN and I2S etc

Disadvantages

• Currently only supports one custom STM32F103 board built by Avil
• API doesnt seem to be totally standard (see below about compile issues)

I have tried to build some standard example sketches using, Koduino, however I have found a number of problems, and a lot of things don’t compile due to small differences in the API that Koduino uses and the Arduino API, this seems to mainly be arguement types, but at the moment things like

digitalWrite(PA0,!digitalRead(PA0));

won’t compile

Updated June 2017

STM Core boards
https://github.com/stm32duino

STM have produced an Arduino Core, which now supports multiple MCUs in the STM32 family of products.

See https://github.com/stm32duino/Arduino_Core_STM32

The core is based on the STM HAL, and can be installed either using the files from github or via a Boards Manager package

Advantages

• Uses the STM HAL, so it should possible to port to most STM32 MCU’s
• Uses the STM HAL, so addition of libraries for advanced functions like SDIO should be easier than writing them from scratch
• Built by professional developers (Wi6Labs), against the latest Arduino spec

Disadvantages

• Probably uses more RAM and Flash usage than non HAL cores (i.e much more than LibMaple)
• Not available for GD32 boards, because of the usage license on the STM HAL (though may work in practice)

STM32 GENERIC by @danieleff

https://github.com/danieleff/STM32GENERIC

Generic implementation of Arduino for STM32 boards

This core also uses the STM HAL, but the structure and architecture of the core differs from STM’s implementation.

Guys,

To save you the trouble, I downloaded the zip file from the MakerLabMe repo, and virtually nothing even compiles

The F407 Discovery that I was interested in looking at doesnt compile, but nor do most of the other boards in their list. Well if the compile, they seem to get linker warnings, which I don’t like the look of

BTW. It looks like it only works on Windows, there are no upload tools or scripts for other platforms…
I must add that as an advantage for my repo

Edit.
I tried to fix the issues that were causing the F407 to not compile, but even after I got rid of the compile errors there were some worrying warnings.

I added the code to upload via stlink (from the Arduino STM32 repo), and managed to upload, but surprise surprise even GPIO doesnt seem to work.

They don’t seem to have pin number defines e.g. PD12 wasn’t defined.
In their variant.cpp it looks like its mapped to “pin” 4 but that didnt seem to cause the LED on my board attached to PD12 to do anything

So at the moment (and for the immediate future) I don’t think that repo is worth bothering with unless you have one of the few boards it works with

Hi

Things very interesting.

I need some information. Why not use the CubeMx Core offered by ST? Their packages contain everything you need for this hardware.
I would love that our CORE supports natively the main ST Boards Nucleo and Discovery:

Boards —> MCU
————————————————
Nucleo-F103RB —> STM32F103RB
Nucleo-F401RE —> STM32F401RE
Nucleo-F411RE —> STM32F411RE
Discovery-32F401C —> STM32F401VC
Discovery-32F411E —> STM32F411VE
Discovery-32F429I —> STM32F429ZI
Discovery-STM32F4 —> STM32F407VG

Unfortunately I do not know the mechanisms to achieve the compatibility layer of Arduino but I can certainly study.

Drake

Drakelive wrote:Hi

… Why not use the CubeMx Core offered by ST? …
Drake

Drake

I think you should look at Avik De’s repo called Koduno. It uses the STMCube files for its core.

However after looking at all the currently available cores, I don’t think using the STMCube is an especially easy way to achieve multi processor support.

As @sheepdoll has said… The files created by STMCube are technically great, but what it output appears to be designed to compile into a single target solution.

When you change the settings e.g. change from a F103CB to. F103RB, STMCube appears to output completely separate sets of headers.

With Koduino, I tried to add support for the F103CB, but found it hard to get the correct headers to be included, even though I know Avik intended Koduino to support multiple processors.

Perhaps when Avik has finished his Phd he will have time to document precisely how to add processors to koduino using the files from STMCube

Hi RogerClark

A few weeks ago I took a look at CubeMX to use my Nucleo Boards. I remember that there are falgs to generate an output with separate headers.
But CubeMx use of packages for specific MCU family ( F1, F3, F4 ), and adds support for hardware devices, initializes the Pin and configures all part of the clock that the user has enabled (omit the part of the energy consumption for the moment).

In theory it should not be so difficult to extract the files from the ST Package. Working with the original ST files allows us to always have the latest updated versions and that’s good.

I think this is the best way.

Drk.

Working with the original ST files allows us to always have the latest updated versions and that’s good.

@Drk.

I work with Cypress PSoC and their build system is ‘connected’ for updates. For non-commercial or even lab use, this is a nice feature to ensure all the systems are updated and all the component classes have the latest VHDL.

However, in a corporate code mill, SDLC would require that a stick in the sand be identified and all development beyond that point be on tool sets that are identical; an automatic update could be disastrous. Somewhere, someone on the corporate ladder should be the gatekeeper for tool versions; their job, working with the development team is to analyze issues and tool ‘fixes’ and the overall impact on a project. The break-fix team for the application (not development) should be looking at the long-term tool versions and the implications on the contractual requirements for maintaining the application once it goes to market. The break-fix team is also the likely (but not always) the group that will deal with application enhancements in the future; so tool versions and timing for introduction falls on their shoulders unless a development defect is discovered that a tool refresh will ‘fix’.

Now different commercial houses revamp the above based on their development/support budget, but there is always some general form (often compressed from the Individual developer/Module/System Test/Pre-production/Production). Small shops may assign one or two developers to a project instead of 30+ on a big team. But, my point is that tools that use the Internet connectivity to automatically update themselves are simply a nice feature but not generally permitted in a corporate shop outside perhaps architecture and R/D.

Ray

Hi

@Ray

Yes, you’re right …… I’ve probably been a little too hasty in writing.
What I meant is that in the face of official releases could take the time to upgrade. I did not mean this to be automatic.
But with a little time and with the help of the community I think that this is feasible.

What do you think about it?

Hi

I tried to do a test with CubeMx. I created a project called Test_F401, based on Nucleo-F401RE
I enabled the following options :

1) Inizialize all IP with their default Mode
2) Digtal I/O
3) Toolchain IDE —> SW4STM32
4) Code Generator –> “Copy all used libraries into the project Folder”
–> “Generate peripheral initialization as a pair of .c/.h files per IP

I created the package; The following files were simply copied from the package CubeMx without applying changes…

…\Test_F401\Drivers\CMSIS\Device\…
…\Test_F401\Drivers\CMSIS\DSP_Lib\…
…\Test_F401\Drivers\CMSIS\Include\…
…\Test_F401\Drivers\CMSIS\RTOS\…
…\Test_F401\Drivers\STM32F4xx_HAL_Driver\…

The only difference is :

…\Test_F401\Inc\stm32f4xx_hal_conf.h
…\Test_F401\Inc\stm32f4xx_it.h

…\Test_F401\Src\main.c
…\Test_F401\Src\stm32f4xx_hal_msp.c
…\Test_F401\Src\stm32f4xx_it.c

…\Test_F401\SW4STM32\Test_F401 Configuration\.cproject
…\Test_F401\SW4STM32\Test_F401 Configuration\.project
…\Test_F401\SW4STM32\Test_F401 Configuration\STM32F401RETx_FLASH.ld

…\Test_F401\SW4STM32\syscalls.c

…\Test_F401\.mxproject
…\Test_F401\Test_F401.ioc

Drk

Drakelive wrote:<..>
What I meant is that in the face of official releases could take the time to upgrade. I did not mean this to be automatic.
But with a little time and with the help of the community I think that this is feasible.

What do you think about it?

Hi Drake

I agree that STMCube now gives us HAL files to use.

I’m not sure if its been discussed in this thread, but F103 support in STM32Cube is a recent addition in the last month or two, prior to that we could not use STMs HAL because of its restrictive license

Anyway.

I’m not sure what you are proposing.

Do you mean that we should manually make projects for the supported devices and output the files from STM32Cube?

There are 12 types of F103 processors we currently target. I’m not sure if the STM32Cube would generate different files for each variant, e.g. Even if the only difference was flash size

Can you try outputting for F103C8 and F103CB and see how many files are different (I.e different content and or different names)

Then would the next step to be to include code for all variants in the repo ?

I’m not sure how we’d switch from variant to variant in the IDE. I don’t think the IDE exec’s anything when switching menu options.

The only thing it does that would be useful in this instance is to change the variant folder that is used. So I suppose the Stm32cube code could be put into the variant folders

Of course we’d also need to do some major changes to the code in libmaple, and remove all direct access to the hardware, because at the moment libmaple tries to act as a HAL (but AFIK it never really managed this very well – hence the F3 and F4 ports ended up not attempting to retain F1 support)

We would also need to move some code currently in libmaple to the variants, e.g. All the vector tables are in libmaple not their respective variant folders, because at the moment all the vector tables would be the same, and hence a support nightmare if there were multiple copies.

Also, I think there are a lot of assumptions in many of the libmaple files about for example the number of timers. In the current code it uses #ifdefs to handle for example how many timer handler callbacks are needed, but all of that would either need to be changed to support F4 or perhaps the whole structure changed to use the STM HAL code generated by the cube.

Whichever way its done, I don’t think its going to be a quick or easy change.

I’d recommend you look at both Kudiono and MakerLabMe cores, to see if either of them would be easier to update to stm32cube. I know kuduino uses stm32cube files already, and Avik says he has a version working for F4 but he has not made those files available in his repo yet as he is too busy.
MakerLabMe also have a F4 port, but it doesn’t compile, and I the author has told me, he doesn’t have plans to fix this, as he is doing other things.

The big problem with both kudiono and makerlabme is they are both unknowns. I.e we don’t know what issues either of them have with their structure or operation.
Neither have USB serial support e.g for use with the bootloader.

libmaple is the “devil we know”

libmaple is the “devil we know”

It’s nof all that bad – IMO.

Now is a terrible time to reinvent the wheel – it would bring our current progress to a halt simply from human resource concerns.

As an (retired) IT architect, there is always a draw for the new, better, faster; but, reality must include the delta-t to make the transition. The solution is out there, any one of us can go seek it. We could also jump to Visual Studio or jump down to the command line and makefiles (there is full support for bare-metal Arduino.)

But, we started this effort to support STM32 through the Arduino 1.5.x GUI and I think most here run 1.6.3 or greater. I would love to see a parallel effort/spinoff dumping the current core and implementing a BIOS.

There is, IMO, a legitimate need to continue with hacking libmaple as it satisfies the immediate need. 6 monghs from now, we may have all lost interest in the STM32 and moved on to greener pastures. So, while the interest is great and the need is immediate, I say let move forward with the current engineering design.

Technology tomorrow may just make this effort boring; but let’s leave this effort in a far better condition than we found it! Others coming behind us will benefit from our perseverance.

Ray

Hi Ray,

I think perhaps I should have said “Better the devil you know”

i.e thats what I meant, i.e libmaple is not perfect, but nor is anything else

I think the only thing worth doing for the F4 guys is to duplicate the F1 code and replace the F1 specific low level code with the F4 low level code.

I think that would be a much simpler job than trying to re-engineer the whole thing from the ground up to use a different HAL

The STM32 cube is still useful, as i can give is code for things like the SDIO on the larger chips e.g. F103RET or better, but I wasnt planning on having to replace libmaple with teh STM32 HAL, I was just going to extract out the low level code and put into new functions in libmaple

RogerClark wrote:
<…>
The STM32 cube is still useful, as i can give is code for things like the SDIO on the larger chips e.g. F103RET or better, but I wasnt planning on having to replace libmaple with teh STM32 HAL, I was just going to extract out the low level code and put into new functions in libmaple

Ray

Yes. The problem is managing this is taking most of my time, and I don’t get time to use it.

There are still a load of things in the pipeline that need to be actioned, e.g. Ricks fix for warnings due to __always_line definition macro clashing with __always_inline gcc internal name

But I was trying to get the most critical things working first, which includes sorting out the ISRS.S issues with hardware timers, and getting the Chip Select line working on PA4 (NSS) etc

Worrying about other stuff is a long way down on my list, but I know some people seem pre-occupied with wanting to use the STM32Cube as in theory using the STM HAL sounds a great idea, but in practice I think its another can of unknown worms !

RogerClark wrote:
Worrying about other stuff is a long way down on my list, but I know some people seem pre-occupied with wanting to use the STM32Cube as in theory using the STM HAL sounds a great idea, but in practice I think its another can of unknown worms !

I feel a bit out of place, only being here a few weeks.

Ah, you fit right in!

Ray

Hi everyone

Only now I can write a few words. I probably got carried away by the enthusiasm and I probably did not express well my overall view.
Ok, I try to do it now.
For a moment we forget CubeMx.
Here we speak of “Arduino for STM32” and then a “CORE” that should allow us to schedule an STM32 MCU using Arduino IDE. (This is right?)
This “CORE” must be installed in Arduino IDE (simply) allowing us to use the classical syntax and code C Arduino.
Typically Arduino IDE ponders Board Specifications: Selezioando a Board automatically we all definition and all the characteristics to it.
We can start with this approach. We add support to the NUCLEO and DISCOVERY Board:
…
Nucle-STM32F1xxxxxxxx
Nucle-STM32F4xxxxxxxx
…..
Discovery-STM32F1xxxxxxxx
Discovery-STM32F4xxxxxxxx
….

We can add support for Custom Borad based dulle MCU:
…
“Generic STM32F1xxxxxxx”
“Generic STM32F4xxxxxxx”
…

Now the question CubeMx.

When “Arduino for STM32” will be ready and running I will not use CubeMx to write my sketch. Everything has to be transparent.
CubeMx has all official packages of ST MCUs that allow us to have definitions of the mappings of the pin, the device interiors and all the functions ready for use. Now I do not know if these files actually complicate life but I can certainly help us. Obviously it is said that we have to use compulsory packages CubeMx but I fear that in the future might become a standard. However, this argument should we decide together here on the Forum.

Drk

Drakelive wrote:
<…>
Now the question CubeMx.

When “Arduino for STM32” will be ready and running I will not use CubeMx to write my sketch. Everything has to be transparent.
CubeMx has all official packages of ST MCUs that allow us to have definitions of the mappings of the pin, the device interiors and all the functions ready for use. Now I do not know if these files actually complicate life but I can certainly help us. Obviously it is said that we have to use compulsory packages CubeMx but I fear that in the future might become a standard. However, this argument should we decide together here on the Forum.
Drk

I think people underestimate how complex it is to write a core to support the Arduino API.

I think the best option for anyone who wants to use the Cube is not to use libmaple at all, but use Koduino.

I will contact Avik and ask him to publish his F4 files to his repo, so that all the F4 users on here can try a different core. I.e one that uses the Cube.

BTW. @sheepdoll posted onto another F4 thread about the Cube, and from what I understand, there may be licensing issues on the linker scripts it generates.
Though @sheepdoll may have been also referring to OpenSTM32 workbench , and I’m not sure where it gets its files.

RogerClark wrote:

BTW. @sheepdoll posted onto another F4 thread about the Cube, and from what I understand, there may be licensing issues on the linker scripts it generates.
Though @sheepdoll may have been also referring to OpenSTM32 workbench , and I’m not sure where it gets its files.

@sheepdoll

Thanks for the clarification.

Re: Koduino

OK.
I did try to produce a F103 variant for Koduino a while ago, but got bogged down with which headers, from the Cube, needed to be included where, and eventually after 3 or 4 hours I gave up as I was getting nowhere

Avik claims to have a F4 version of Koduino working, but has not pushed his code. But as currently Koduino only works on Aviks own custom F3 board there is no way to evaluate even its most basic operations.

I will pester Avik to push whatever F4 code he has, even if its only partially working

Edit. He appears to have pushed a F4 board last week

I will pull and test

I just spent the last hour or so playing with Koduino.

What I see after getting the cubeMX to compile, is that there would be a lot of work to implement the 401 Nucleo. Avik seems to be attempting a one size fits all. A lot of the files have been moved around from the tree that cube generates. The docs say not to do this. The way I have it set is to point the CubeMx at the variant folder. CubeMX is providing the logic to give the IDE what it needs.

A lot of the Koduino F4 stubs are just cut and paste from the F3. The core library looks to be derived from maple so there are still a lot of low level structures rather than callbacks into the HAL. Did not dig too deeply.

I did look at some of the Arduino.cc core. That might be a better starting place to work from. None of this is going to be pretty.

@sheedoll

A lot of the files have been moved around from the tree that cube generates.

Ah…

That explains a lot.

My presumption was that I could just copy the folders generated by the Cube into a variant folder and away it would go.

But of course it didn’t.

I wonder why Avik chose to start restructuring the folders. I presume he’s also had to change some of the headers so that they include from the correct path, or perhaps he managed to handle that using the include directives on the command line.

It could be that looking at the Arduino SAM folders may be one line of attack, but its probably worth contacting Avik, because form what I understand he evaluated libmaple, and makerlabme and a few other cores before deciding to do it again from scratch.
So I guess he has logical reasons for doing what on the face of it seems a bad idea (i.e restructuring the output from the Cube)

RogerClark wrote:

My presumption was that I could just copy the folders generated by the Cube into a variant folder and away it would go.

Re:CubeMX

Ah.. Again.. Its not something I’m familiar with.

I downloaded the STM32Cube and have exported files from it, but thats about all.

The other dev env I tried for STM32, a while ago, is CooCox, which seems to have its own HAL type system, which looks a lot like the Cube HAL, but I suspect pre-dates the STM32Cube, as there has been F103 support in CooCox for quite some time, i.e prior to F103 becoming part of the STM32Cube.
Consequentially I suspect the license on the CooCox files would be problematic – not that I think its worth trying to use their files.

There is also Em:Blocks, but I’ve only very briefly looked at it, and didnt get as far even as compiling a blink program, so I’ve no idea which files they use

Re: Poison pill

I suspect if you have found different versions of the linker script with different licenses, this may just be an oversight by STM, and not their intention to have a restrictive license on a system where all the new files appear to have a much more open license.

However I have asked questions about the license on the old HAL files, (on the STM32 community forum) and not got a response, as STM only seem to staff the BBS with tech people ( “clive” ) and not anyone who knows about licenses

You are at a bit of an advantage to me however, as I think there is an STM office in Berkeley isn’t there ? I noticed an advert for an “evangelist ” some time last year, when I was looking for someone I could contact. So you may be able to get some information out of a local representative that you’d not get from STM central (China)

Guys,

I came across a recent posting on the old LeafLabs forum, referencing that active development of libmaple was now going on under the Rambutan project

https://github.com/rambutan32/librambutan

http://rambutan.cc/

http://forums.rambutan.cc/

There does seem to be some recent modifications going on to this repo, but no activity on that forum since March this year.

It just looks like its one guy, bryan newbold , who is running with this. So I think I may contact him, as I doubt its worth his effort re-doing what we’ve already mostly done, and if he wants to use the CMSIS or HAL, then he’d be better off looking at what @sheepdoll has done.

It looks like he has no interest in arduino using wirish. You might read his development roadmap post on his forums. http://forums.rambutan.cc/t/roadmap-and-priorities/56 He doesn’t really like bootloaders or usb serial either : )

-rick

Rick,

i did read the “roadmap”, but it didn’t make much sense.

If he is not fussed about the Arduino API, then libmaple is not a good starting point.

Not using the native usb on the STM32 seems a bit odd as well. STM provide their own usb code if he doesnt like the stuff leaflabs wrote.

BTW.
Re:Bootloader
it looks like the BlackSphere guy(s) wrote their own DFU bootloader using libopencm3.

if i get chance i will have a go at compiling it, to see if its any better than the modified Maple bootloader.
But as fas as i can see its no smaller and i doubt its any faster ( as the majority of the upload time appears to be the delay while the STM32 erases the pages of flash )

Looks at something in seedstudio yesterday, I found they have another core for STM32 mcus.
They have this board called UF0, which has a cortex M0 STM32F051.
Their core libraries are here:
https://github.com/BestU/STM32_for_Arduino_BSP

I had a quick look, and seems they used CMSIS and the standard peripheral library.

Then there is the makerlab.me core, which I dont remember if it has been linked here before, so just in case:
https://github.com/MakerLabMe/STM32_Arduino_Cores

It is for F103 and F4xx as far as I can see, again based on CMSIS and std peripheral library apparently.
The core was updated about 3 months ago, but looks like in the meanwhile they have added support for the board manager, and that has been updated recently:
https://github.com/MakerLabMe/STM32_Arduino_Board_index

Posting them in case they are of use to anyone.

Victor,

I’m pretty sure the guy doing MakerLabMe said he was no longer actively developing any of it. (I have listed it in a previous posting)

The only Core that i was not aware of, is the SeeedStudio one.
I took a quick look on GitHub and the CMSIS dates back to Dec 2014, and when i did a search for HAL on the repo, there were only a few comments.

So ad far as I can tell, its not a HAL based implementation, and consequentially we cant directly use it without modifying all the calls in the Wiring code to the Standard Peripheral Lib .

So at the moment I think our best option is to continue with @sheepdoll’s excellent work

RogerClark wrote:Victor,

I’m pretty sure the guy doing MakerLabMe said he was no longer actively developing any of it. (I have listed it in a previous posting)

The only Core that i was not aware of, is the SeeedStudio one.
I took a quick look on GitHub and the CMSIS dates back to Dec 2014, and when i did a search for HAL on the repo, there were only a few comments.

So ad far as I can tell, its not a HAL based implementation, and consequentially we cant directly use it without modifying all the calls in the Wiring code to the Standard Peripheral Lib .

So at the moment I think our best option is to continue with @sheepdoll’s excellent work

how to work on STM32F401RE with arduino? please help me

dharmendra wrote:how to work on STM32F401RE with arduino? please help me

If you don’t have F401 hardware yet, I would suggest to go with an F405, since it is already proven working.

But if you have some F401 hardware, maybe you should start by adding a new variant in STM32F4/board.txt that would match with your hardware.
RAM size, FLASH size needed to be tweaked as well as F_CPU.

Also, check the crystal frequency of your board, since maybe you will have to tweak that too in STM32F4/cores/maple/libmaple/rccF2.c

Then, start slowly with simple Blinker sketch, and gradually ramp up with more stuff like Serial, USB, etc.

martinayotte wrote:If you don’t have F401 hardware yet, I would suggest to go with an F405, since it is already proven working.

sheepdoll wrote:As noted the non F1 Cores are based on an older version of lib maple which does not support some of the more recent Arduino features like serial stream.

Core based on MX is a nightmare to support it….
MX is actually a code generator for a specific device and for a specific configuration, for generic use a vast number of IFDEFs would be very difficult.
The only viable alternative to maple lib is opencm3. It is stable and it supports many devices.

I do not think it is the core that is the issue.

With Arduino and STM there are baseline processors, the Mega328 and the STM32F103. This is how one gets around the nightmare of too many options with new one announced everyday.

I am quite happily using the cubeMX tool to learn more about STM32. It has also helped me understand things with my day work, which I can produce quicker and with more reliability on the AVR platform. In the mean time I continue to do small incremental things with the STM stuff.

Where the outlier is is in the bootloader. I prefer to use a program dongle. It is what I learned with. STM32 does not lend itself to a universal boot loader the way AVR does. I still remember that when AVR came out it could be programmed with a parallel port and some paperclips.

Now we have DFU loaders and code management systems like Git.

Can you say more about the status of your cubeMX core?
CubeMX is the official way to talk to the chip and ST is very active to support it. This is a big plus, for sure.
I have used the CubeMX way for some small projects but I love to use stm32duino as a fast way to do things specially testing of new hardware using libraries.

@slammer

Does openCM3 use the Standard Peripheral Lib / CMSIS from STM, or is does it use a clean room implementation

The one drawback we have, with using the LibMaple core (Originally written by Leaflabs, way back in 2012), as that they developed their own API to the low level functions.

So its not possible to add SPL or HAL function calls to the Arduino code, hence we can’t use any example that uses those calls

Also we don’t benefit from updates/bug fixes to the CMSIS / HAL that may be released by STM.

Looking at LibOpenCM3, it looks like its also not using STM’s code; so although its got a lot more people supporting it than LibMaple, it looks like it would still have the same issues about not getting updates direct from STM’s code and also you can’t use examples written using the SPL or HAL – can you???? )

Slammer wrote:Can you say more about the status of your cubeMX core?

sheepdoll wrote:
<…>
At the same time I am also learning more about the arduino world. As an advanced AVR programmer I had dismissed the Arduinos. Now I am starting to understand some of the mindset behind it.

may you update the first message adding the ST core ?

testato wrote:may you update the first message adding the ST core ?

I couldn’t agree more.
I like use the same very easy set up environment for compiling in few clicks with Arduino IDE.
I recently tried to do some hacks in betaflight code and try to setup eclipse to build it in windows.
OMG sometimes I felt like shooting myself in the head so many settings tweaks ,add Java JDk ,downloading/installing specific eclipse build( not anyone works),install GCC ARM Embedded toolchain,add GNU ARM Eclipse Plugins,install OpenOCD,install QEMU,download/install msys or cygwin, add them to the PATH,configure eclipse(PATH,compile settings, linker settings),. aso…ohhh.Terible experience.I think it is impossible for a newbie to do that even with the manual how to in front of their eyes..

In comparison I compiled multiprotocol_STM32 in Arduino IDE 1.6.12 with few clicks.Indeed is not perfect but fast compiling/testing is invaluable for me . It saved me so much time.
I do the same with arduino libraries I fast tested some sketches using some arduino libraries , and on real deal I like go on low level working directly with registers.
I worked also with avr before and Arduino is/was not very popular with many avr purists.But maybe this feeling will change when passing to STM32 chips.

mrburnette wrote:sheepdoll wrote:
<…>
At the same time I am also learning more about the arduino world. As an advanced AVR programmer I had dismissed the Arduinos. Now I am starting to understand some of the mindset behind it.

That’s all correct.
Just one huge thing is missing from Arduino IDE: the debug interface…

stevestrong wrote:That’s all correct.
Just one huge thing is missing from Arduino IDE: the debug interface…

STM32GENERIC

Advantages

• Uses much less RAM than maple core
• Already enabled FPU
• Generate a smaller code 8~15% on Os

Disadvantages

• Complex GPIO and HAL initialization aren’t noob friendly

would be interesting to see how much space a typical job takes under various cores.

with my ARMduino: a blinky compiles to 3.5KB, slight smaller with -Os and bigger with -O0 on F1, and 2 – 3Kb on F0.

I wonder how much it compiles to on other cores.

edit: one more data point – blinky compiles to 13kb under stm32duino / arduino 1.6.

Complex GPIO and HAL initialization aren’t noob friendly

it depends on how you approach it. most users have a few limited “modes” under which they access GPIO. if you packages those modes into easy-to-use routines / macros, the set-up isn’t that big of a deal. aka Arduino-style.

The most complex to me is Timers initialization, I have been ported Speeduino code to STM32, I have to use up to 16 comparators to make all injectors , coils, VVT, IDLE and others PWM channels working. That is a big deal for me

The most complex to me is Timers initialization

i think if you look at what you do with timers, the majority of them can be stylized. So rather than doing x y and z, you can simply do A which will do x y and z for you.

that’s basically what modular programming / libraries are all about.

I think an Arduino framework is useless without a lot of easy to understand code examples.
That is the reason why I did many for STM32GENERIC.

Roger I think you should take this line out of the disadvantages of the official STM core:
Not available for GD32 boards, because of the usage license on the STM HAL (though may work in practice)

And perhaps move it up the least above the makerlabme core since that’s not active or very usable. If you agree you can just delete this post.

Victor

Where is that text?

I think references to GD32 need to be completely removed

hi roger,
i’m thinking we could perhaps update the first post moving STM’s core and STM32 GENERIC by @danieleff up just after Arduino STM32 – libmaple core
then the rest become ‘older stuff’

@admin just wanted to know the status of “official” https://github.com/stm32duino/Arduino_Core_STM32 vs the the more popular https://github.com/rogerclarkmelbourne/Arduino_STM32 in 2018

If I am not wrong if your board is supported by the official core it’s better to use that one. If not, you have to use roger core or one of the others.

[iotnode – Sun Apr 15, 2018 1:37 pm] –
@admin just wanted to know the status of “official” https://github.com/stm32duino/Arduino_Core_STM32 vs the the more popular https://github.com/rogerclarkmelbourne/Arduino_STM32 in 2018

The “official” core is growing and under active development, but it does not include none of the customized user libraries in Rogers repo (like the superb ILI9341 TFT lib). I don’t know if they will work with the “official” core. But you can read all issues and pull requests on github for getting an overview.

and yet there is one more “core” i came across: https://github.com/BSFrance/BSFrance-stm32 see here, has support for hardware hal. support for stm32f103

They seem to have copied all the tools from the LibMaple repo but the core files seem to be HAL so are probably copied STMs official core

Not sure why they bothered to do this, as I would have thought forking STM32 GENERIC would have been a better option

Looks like it’s to support specific hardware

Yes it is for some specific hardware. here is where i found some discussion: https://www.thethingsnetwork.org/forum/ … opic/13391

This is the hardware page:
https://bsfrance.fr/58-lora-long-range?page=1

It’s seems to be based on STM32GENERIC.

iotnode, mains differences about Roger’s core and STM core is STM core is designed to support all STM32 MCU families (F0/F1/F2/F3/F4/F7/H7/L0/L1/L4). H7 coming soon .
Roger’s one is mainly for F1 based board (oriented on F103 for BP and MM) and also F4 with active support from stevestrong .
Basically if you planned to work on BP or MM, I advise you to use Roger’s core which wonderfully support all features of those boards and are very well documented and supported on this forum.
STM core is young and still required some development /enhancement and documentations.

Anyway, I saw the STM core description need to be updated as it told to be Nucleo oriented but it not more the case.

Frederic

I keep forgetting to update that.

Can you remind me where its posted and I will change it

[RogerClark – Tue Apr 17, 2018 5:57 am] –
Frederic

I keep forgetting to update that.

Can you remind me where its posted and I will change it

In the OP of this topic

OK

Removed references to Nucleo

thanks everyone for responding. i think there should be a “wiki” page outlining the main differences/similarities between at least the popular cores stm32official and the wonderful work done by roger clark on the leaflabs. i think any person coming from arduino background (the real arduino or the esp8266) will be overwhelmed. of course, the contents of the wiki could populated over a period of time by anyone (in the spirit of the wiki)

@iotnode: There is a discussion running, which “Roger” cores are further supported or dropped (looks like the F3 is/would be dropped), so the Wiki should be written when the result is certain.
But indeed, a wiki entry for the different cores would be helpful. (btw: the stm32duino wiki is mostly roger-core-related!)

[fpiSTM – Tue Apr 17, 2018 5:08 am] –
It’s seems to be based on STM32GENERIC.

BSFrance-stm32 appears to be based on this STM32GENERIC fork: https://github.com/huaweiwx/STM32GENERIC

Here is another core, non-HAL for STM32L0 (it includes a nice LoRaWAN library):
https://github.com/GrumpyOldPizza/ArduinoCore-stm32l0