[Deprecated: old core]Introducing the new delivery for STM

The official STMicroelectronics Arduino core
Post Reply
User avatar
Wi6Labs
Posts: 25
Joined: Fri Sep 16, 2016 11:39 am
Location: Rennes, France
Contact:

[Deprecated: old core]Introducing the new delivery for STM

Post by Wi6Labs » Mon Sep 19, 2016 8:35 am

Hello Everybody

It's nice to see the interest of the community about our job on porting the STM32 on Arduino. :D

We would like to introduce our job and to respond to your questions about our choices of implementation.

First of all, the goal of the delivery is to provide the same functionalities that you can have when you buy an arduino Uno and that you need to launch the sketches.
We tried to build something generic and not too much hard to customize.

We decided to divide the project in 2 parts:
-The lib that contains the access to the drivers and to the MCU configuration. The library contains the STM32 HAL. It is compiled independently.
ST requested to use the HAL as it is maintained by the ST teams so you can easily integrate new functionalities :).
-The arduino core with the Wirish interface and the variant.

Their should not have any direct reference to the Hardware registers into the arduino core.

We clearly understand the questions about the memory footprint but this project is a compromise to make the STM32 HAL work the more efficiently with the arduino core, the simpliest way.

So if you have any questions, don't hesitate and we will try to respond.

BR

Wi6Labs team
Wi6Labs team

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

Re: Introducing the new delivery for STM

Post by RogerClark » Mon Sep 19, 2016 10:08 am

Welcome Wi6Labs

Thanks for posting, I think it will be very useful if we can ask questions about the software you wrote.



We have some questions about how to add more boards from the same MCU series e.g. STM32F1

The old "LibMaple" core supported the STM32F103Cx , STM32F103Rx. STM32F103Vx and STM32F103Zx series

@rickKimbal has started to add a "BluePill" board (STM32F103C8) to the F103 core, but we realised that there were differences in the hw_config and we had to move this file from libstm32f1 to the variant folder.

This is discussed in 2 threads

http://www.stm32duino.com/viewtopic.php?f=48&t=1407

and

http://www.stm32duino.com/viewtopic.php?f=48&t=1406


Also. One thing we need to add is USB CDCACM, I don't think any of the Nucleo boards have a direct USB connection, but most F103 boards make use of the built in USB port and we have a bootloader we use to upload.

BTW
I think perhaps I should move this whole thread to this section http://www.stm32duino.com/viewforum.php?f=48 as its dedicated to your work ;-)

User avatar
Rick Kimball
Posts: 990
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: Introducing the new delivery for STM

Post by Rick Kimball » Mon Sep 19, 2016 8:31 pm

@Wi6Labs Do you plan on doing any more changes to the STM32F1 core?
-rick

User avatar
Rick Kimball
Posts: 990
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: Introducing the new delivery for STM

Post by Rick Kimball » Mon Sep 19, 2016 8:51 pm

Wi6Labs wrote: We decided to divide the project in 2 parts:
-The lib that contains the access to the drivers and to the MCU configuration. The library contains the STM32 HAL. It is compiled independently.
ST requested to use the HAL as it is maintained by the ST teams so you can easily integrate new functionalities :).
-The arduino core with the Wirish interface and the variant.

Their should not have any direct reference to the Hardware registers into the arduino core.
Wi6Labs team
Thanks for the port. We have been wondering if ST would ever do an official port. :)

It seems like the "wrapper function" for lack a better name still seem to make assumptions about the variant pins.

For example in analog.c
https://github.com/stm32duino/Arduino_C ... log.c#L105

This table in libstm32f1 makes assumptions about which pins and how many pins are configured as analog even though the pin specifics are in a table in variant.cpp. You can't just change the pin associated with analog pins in variant.cpp without also making changes to the file in the libstm32f1.

The same problem is also found with the uart.c file.

Is this something you plan to make more general?

-rick
-rick

User avatar
Rick Kimball
Posts: 990
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: Introducing the new delivery for STM

Post by Rick Kimball » Mon Sep 19, 2016 8:56 pm

RogerClark wrote: Also. One thing we need to add is USB CDCACM, I don't think any of the Nucleo boards have a direct USB connection, but most F103 boards make use of the built in USB port and we have a bootloader we use to upload.
Many of the Nucleo-144 boards have USB and Ethernet Networking.

NUCLEO-F207ZG, NUCLEO-F303ZE, NUCLEO-F412ZG, NUCLEO-F429ZI, NUCLEO-F446ZE, NUCLEO-F746ZG, NUCLEO-F767Z
-rick

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

Re: Introducing the new delivery for STM

Post by RogerClark » Mon Sep 19, 2016 9:18 pm

Rick,

Frederic posted a list of the board they intend to support, but it only looked like one board per MCU series.

I will email Laurent, who is team leader for this at STM, as Frederic may now be away on paternity leave.

I think we will need to wait until tomorrow for a response from Wi6Labs, because its getting on for midnight in France

Btw. One other thing I noticed is that the pin names seem to be set using #defines, rather than enum.
If Wi6 are not doing any more work on the F1 core, I agree that more radical changes will be needed.

User avatar
Wi6Labs
Posts: 25
Joined: Fri Sep 16, 2016 11:39 am
Location: Rennes, France
Contact:

Re: Introducing the new delivery for STM

Post by Wi6Labs » Tue Sep 20, 2016 7:36 am

Roger,

ST developed the NUCLEO board support for:
  • STM32F103RBT6 STM32F303RET6 STM32F429ZIT6 STM32L476RG STM32F091RCT6 STM32L053R8T6
As you know these boards are hardware compatible with Arduino architecture. Now they are also software compatible.
As we said in previous post our goal is to provide generic interfaces to link the Arduino world with the STM32Cube world.
We understand there are multiple ways to implement such kind of "glue". But we decided to make something very easy to use with the Arduino IDE.
We have some questions about how to add more boards from the same MCU series e.g. STM32F1

The old "LibMaple" core supported the STM32F103Cx , STM32F103Rx. STM32F103Vx and STM32F103Zx series
If you want to support other STM32 series we advice you to modify the library (libstm32f1). You can generate an archive with the makefile in build_gcc (some modifications are required). If you need more information on how to generate archive, we can help you.
Please also check the system/Drivers/CMSIS/Device/ST/STM32F1xx/Include for the list of supported boards.

Rick,
@Wi6Labs Do you plan on doing any more changes to the STM32F1 core?
Only if there is bug in the Arduino IDE for the STM32F103RB.

BR

Wi6Labs team
Wi6Labs team

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

Re: Introducing the new delivery for STM

Post by RogerClark » Tue Sep 20, 2016 8:20 am

Thanks @Wi6Labs

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

Re: Introducing the new delivery for STM

Post by RogerClark » Tue Sep 20, 2016 11:44 am

@wi6Labs

is possible can you read this thread

viewtopic.php?f=48&t=1407&start=40

There are already some questions about how we can add support for F103Vx and F103Zx series boards.

It looks like the code in libstm32f1 does not handle GPIO Ports, D E F or G, so we will need to update multpile files e.f. digital_io.c to add support for these GPIO ports ( the same probably applies to MCUs with more USARTS and also some F103 MCUs have UART as well as USARTS.

To create create a new variant, it looks like we may need to make a complete copy of libstm32 F1 ( in the system folder), but this is not ideal, as it will lead to a duplication of a lot of functions, which will be identical in many different boards.

So it alos looks like we woll need to split the global initialisation structures from inside files like digital_io.c and perhaps make a new file e.g digital_io_config.h which contains the global definitions structure.

I realise Wi6Labs will not be making any additional variants, but it would be very helpful if you could answer questions related to the code design etc, and perhaps suggest methods so we can support multiple additional MCUs in each series.

Thanks

Roger

User avatar
Slammer
Posts: 241
Joined: Tue Mar 01, 2016 10:35 pm
Location: Athens, Greece

Re: Introducing the new delivery for STM

Post by Slammer » Tue Sep 20, 2016 12:29 pm

There is no problem to implement GPIO for as ports we like, eg PA, PB, PC, PD, PE, PF, etc.... in the library.
It is easy to check if a specific port is defined, as HALMX defines the peripheral bases if the peripheral exists. As I can see, some ifdef's are needed if we have to keep the same source files for GPIO, UARTS, etc at least for the checking of a peripheral existence. I know that you dont like ifdef's but the other way to have multiple versions of library is the worst thing we could make.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest