List of cores currently available

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

Re: List of cores currently available

Postby RogerClark » Mon Jun 08, 2015 10:26 pm

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"

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

Re: List of cores currently available

Postby mrburnette » Tue Jun 09, 2015 12:03 am

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

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

Re: List of cores currently available

Postby RogerClark » Tue Jun 09, 2015 12:20 am

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

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

Re: List of cores currently available

Postby mrburnette » Tue Jun 09, 2015 12:36 am

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


That seems a prudent approach.
There are still pull-requests to be issued I read tonight from victor and a lots of testing in the F103 arena. With the current productive talent, changes are coming fast, but sanity testing is lagging.
Somewhere in the near future, you need time to construct and enjoy the fruits of your labors.

Ray

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

Re: List of cores currently available

Postby RogerClark » Tue Jun 09, 2015 12:43 am

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 !

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

Re: List of cores currently available

Postby sheepdoll » Tue Jun 09, 2015 1:52 am

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 !


For some of us the pre-occupation is for the "Devil we know." I feel a bit out of place, only being here a few weeks. What I see is that we have a successful group A which is interested in Maple and F103 and inexpensive dev boards which can give one a quick and inexpensive entry into ARM. This is a great path, there is a lot of intertia behind it and I do not want to upset the cart. This should be the primary focus of this group. It is after all a Maple group first and foremost.

The other group B, has STM hardware, which is probably more expensive, that was given out in large quantity as marketing promotion for free. We want better tools. Some of us are willing to jump headfirst into the deep end. We have the hardware, and perhaps limited time, perhaps not the ability to manage projects. More of an at risk group. I am thinking and probably agreeing that these should be two separate projects, with separate downloads. But still under the STM32duino "Arduino for STM32" name. I think there is room for both in these forums. I also think there should be a sticky on the top of the "experimental R&D section" Enter at own risk.

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

Re: List of cores currently available

Postby mrburnette » Tue Jun 09, 2015 12:48 pm

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


Ah, you fit right in!

Ray

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

Re: List of cores currently available

Postby Drakelive » Wed Jun 10, 2015 10:49 am

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

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

Re: List of cores currently available

Postby mrburnette » Wed Jun 10, 2015 1:34 pm

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


The F103 support is in the current STM32duino offering.
The F4xx is being worked on actively and some functionality is currently available.
Maple/Maple Mini based on F103 is complete and in break-fix mode with evolution being made with SPI, I2C hardware. I believe the bit-bang implementations are operating well. Generic board support for F103 is alive and well with custom bootloaders available. Numerous generic boards based of F103 are supported and work effort on pin-mappings is ongoing.

In Arduino, pin mapping is significantly more complex than is a product such as Cypress PSoC where VHDL configures the matrix switches. The goal of Arduino is to be able to use a number of pin references from the physical board edge number to the Port Name + I/O number. Using AVR as an example:
Image

For the Arduino programmer, PC0 has multiple aliases: D18 (the board pin label (not uC!)), A0, and PC0 (UNO or PF7 on Leonardo!)

But, it goes deeper as the pin numbers are integers:

Code: Select all

void loop() {
  // loop from the lowest pin to the highest:
  for (int thisPin = 0; thisPin < pinCount; thisPin++) {
    // turn the pin on:
    digitalWrite(ledPins[thisPin], HIGH);   
    delay(timer);                 
    // turn the pin off:
    digitalWrite(ledPins[thisPin], LOW);   
  }


This concept of 'Arduino' is somewhat unique and while it simplifies for the programmer it complicates for the software engineer working behind the scenes.

Now, back to CubeMX which relies on an abstraction layer that is loosely analogous to as the Arduino 'core'. Creating a HAL for the F1xx series or the F4xx family is going to be a major undertaking. The upper layer code generated by CubeMX is instructional but not very useful as the API layer is in the HAL. The HAL code is instructional but will require much effort to morph the API into something that provides Arduino capabilities. In the end, it would all have to run under the ArduinoGUI and the GNU compiler/linker for ARM.

Just my opinion. I think CubeMX is definitely the way to go for professional uses and I have not looked over how ST is protecting themselves for errors/omissions in the legal sense, but I'm sure there are somewhere in the licenses. As a systems architect, I see beauty in CubeMX and chaos in Arduino, but as crazy as it is, STM32duino works and the F103 seems to be working well. I would not want to trust it right now to be in some life sustaining medical device, but for general Arduino hobby projects, it is adequate; just not efficient.


Ray

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

Re: List of cores currently available

Postby RogerClark » Wed Jun 10, 2015 10:08 pm

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.


Return to “Cores”

Who is online

Users browsing this forum: No registered users and 1 guest