List of cores currently available

Cores are the underlying magic that make the Arduino API possible
User avatar
RogerClark
Posts: 5466
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

List of cores currently available

Postby RogerClark » Fri May 08, 2015 4:46 am

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 Sept 2016

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

STM have produced an Arduino Core, which currently supports 2 of their Nucleo range boards.
The NUCLEO-F103RB and the NUCLEO-L476RG

The core is based on the STM HAL, and is expected to be deployed as a Boards Manager package.

Currently this is a work in progress, with support for more Nucleo boards to be released in the latter parts of 2016.

STM contacted me when they were going to release this Core and I suggested that it be deployed by the stm32duino github account, of which I'm admin.
I have created separate repos for each MCU core, and for the Tools, so it is now also possible deploy by copying the Core files and the tools into the Arduino/Hardware/STM_Core folder, in the same way that LIbmaple can be deployed.

I have also added support for all the upload tools used by LibMaple.

My understanding is that once all major Nucleo boards have been created by STM, that they will not be adding any new boards, but there may be some support for bug fixes for a limited time.
So it will be up to the community to continue development of this core.

Advantages
  • Uses the STM HAL, so hopefully 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
  • Much greater RAM and Flash usage than non HAL cores (i.e much more than LibMaple0
  • Not available for GD32 boards, because of the usage license on the STM HAL (though may work in practice)
  • Currently only 2 Nucleo boards are supported - but hopefully the community will be able to add support for the popular chinese boards like the BluePill and the Maple Mini clones



My conclusion

Currently the Arduino_STM32 (libmaple) repo gives the best functionality for the majority of users, especially those using Maple Mini boards

However its possible that the STM Core will supersede the libmaple core at some time in the future.

But the STM Core is always likely to take more RAM and more Flash than libmaple, so don't expect people to migrate to the STM core unless they want to make use of the HAL or unless the STM Core supports peripherals like CAN or SDIO which LibMaple doesn't.


As Koduino is already based on the Standard Peripheral Library, (the predecessor of the HAL), I suspect it will mostly be superseded by the STM Core.

Likewise and to a greater extent, the MakerLabMe core, as it has not been supported for some considerable time
Last edited by RogerClark on Mon Sep 26, 2016 4:49 am, edited 1 time in total.

User avatar
RogerClark
Posts: 5466
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

MakerLabMe

Postby RogerClark » Fri May 08, 2015 6:29 am

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

Drakelive
Posts: 44
Joined: Fri Jun 05, 2015 10:29 am
Location: Italy

Re: List of cores currently available

Postby Drakelive » Fri Jun 05, 2015 12:51 pm

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

User avatar
sheepdoll
Posts: 216
Joined: Fri May 22, 2015 12:58 am
Location: Silicon Valley Vortex
Contact:

Re: List of cores currently available

Postby sheepdoll » Fri Jun 05, 2015 5:39 pm

Drakelive wrote:Hi

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

I have spent some of the last week looking into this myself. CubeMx does run on all major operating systems through java, so that is a plus.

I forked the STM32F4 code to create a F401 Nucleo folder. I have a STM32401 Nucleo and a STM429Discovery. The existing code works with I think a 407Discovery. I have not had time to try my branch on the hardware yet.

I am finding, that to be useful on the smaller pin devices like the 401RE, that I am going to have to re-write some of the low level code. Over the last few days I attempted a monkey merge between the F1 Nucleo and the F4 Nucleo. At the moment I got it to compile, But sections of the NVIC and timers are not working and #ifdefed out to see what compiles. A lot of the low level serial and SPI needs some work. Things like alternate functions are done different between F1xx and F4xx.

A lot of the existing code is targeted to a specific processor, with the peripherals hard coded. I was expecting to see a number of #ifdefs, instead there are just hacks to get stuff working. Nothing wrong with this, it is the existing code usable and easy to read. Roger and others did great work getting it to the current state.

CMSIS does now look promising, It is not all that human readable, easy to machine parse. Currently on the Nucleo board version C-01, the clocks are not connected and straps need to be soldered. Using the CubeMx code, there is a whole section on clock tree setup, which is needed for USBOTG.

I have limited time this weekend away from my hardware, I am looking more and more into building a variant, that uses some of the auto generated code to see If I can get it to compile under the IDE.

User avatar
RogerClark
Posts: 5466
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: List of cores currently available

Postby RogerClark » Fri Jun 05, 2015 9:18 pm

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

Drakelive
Posts: 44
Joined: Fri Jun 05, 2015 10:29 am
Location: Italy

Re: List of cores currently available

Postby Drakelive » Mon Jun 08, 2015 12:04 pm

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.

User avatar
mrburnette
Posts: 1769
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: List of cores currently available

Postby mrburnette » Mon Jun 08, 2015 12:36 pm

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

Drakelive
Posts: 44
Joined: Fri Jun 05, 2015 10:29 am
Location: Italy

Re: List of cores currently available

Postby Drakelive » Mon Jun 08, 2015 1:56 pm

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?

Drakelive
Posts: 44
Joined: Fri Jun 05, 2015 10:29 am
Location: Italy

Re: List of cores currently available

Postby Drakelive » Mon Jun 08, 2015 2:14 pm

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

User avatar
mrburnette
Posts: 1769
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: List of cores currently available

Postby mrburnette » Mon Jun 08, 2015 4:53 pm

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?


I think the IDE can call out to an exec that performs the updates for the end-user. I think this is very permissible. I would also agree on such a facility being event driven: on opening or on a schedule. This is all sensible.

BUT: I would also think such an exec should provide the end-user with an upgrade log; at a minimum what files were added, which overwritten, etc. I also think before the update, a backup (ZIP works and is free) should be performed to provide for manual roll-back. All of that can easily be scripted for any of the 3 environments: Windows, Linux, OSX.

Ray


Return to “Cores”

Who is online

Users browsing this forum: No registered users and 1 guest