Introducing the new delivery for STM

The official STMicroelectronics Arduino core
User avatar
Rick Kimball
Posts: 941
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: Introducing the new delivery for STM

Post by Rick Kimball » Tue Sep 20, 2016 1:01 pm

Question about the stack configuration for @Wi6Labs

In the STM32F1 core, can you explain how the stack is used? If I look at the linker file:
https://github.com/stm32duino/Arduino_C ... ASH.ld#L49

The variable _estack is set to an address in the middle of RAM.
_estack = 0x20001FFF;

In addition, it is an odd address instead of even.

Why isn't this variable set to the actually top of RAM (0x20005000) ?

-rick
-rick

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 » Wed Sep 21, 2016 1:02 pm

Rick,

It is a mistake. __estack must be set to 0x20005000, the last address of the SRAM.
We will report it to ST who will push the patch soon.

Thanks Rick.

Wi6Labs team
Wi6Labs team

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

Re: Introducing the new delivery for STM

Post by Rick Kimball » Wed Sep 21, 2016 3:30 pm

@Wi6Labs

What would be the best way of adding a new variant that has different pin assignments than the variants you are supplying?

[Note:]
I did read your previous answer and was looking for verification that that is indeed your solution.

You seem to say that for each board we need to create a new library? Pins seem to have their attributes described in both the variant directory and the library directory. You can't just redefine an analog pin with PWM to use another pin in the variant.cpp file, it has to also match the information in the analog.c in the library directory.
[/Note]

-rick
-rick

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 » Fri Sep 23, 2016 11:54 am

Roger / Rick,

To answer to your questions how to add a new board:

Firstly, the project is base on Nucleo boards, so there is some feature not implemented in the core code (under system/libstm32f1).
So, you need to add some code in sources (as you have already done). You should create a new folder in variant for each board added. And you should generate the library for the new board (there is a makefile in system/libstm32f1/build_gcc). This makefile must be completed with the options of the new board.
Finally, to use the board with Arduino, you should complete the board.txt with the parameters of the new board.
You seem to say that for each board we need to create a new library? Pins seem to have their attributes described in both the variant directory and the library directory. You can't just redefine an analog pin with PWM to use another pin in the variant.cpp file, it has to also match the information in the analog.c in the library directory.
You are limited in pin functions. So we need to define also in analog.c the pin configuration. In variant.cpp you just signal to Arduino how the pin can be used.

BR
Wi6Labs team
Wi6Labs team

stevestrong
Posts: 1446
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: Introducing the new delivery for STM

Post by stevestrong » Fri Sep 23, 2016 1:41 pm

What is actually the "pins assignment" meaning? Is it the pinout of the respective board?
So, for instance, if I have two boards with the same chip (let's say: STM32F407VET6), do I really have to make a new folder for each board variant?
Wouldn't be more effective to separate the chip variants, and not the board variants?
I mean, when I am using the GPIOs, I always use the "PAx" style, so that even if the board is different, I get the same functionality for the same pin when the same chip is used.
Or am I missing something?

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 » Fri Sep 23, 2016 2:51 pm

stevestrong,

In the Arduino spirit you have one folder by board.
In your case, we understand that the hardware of your boards (that use the same chip) is different.
So we advice you to create 2 folders in variant.
Maybe it is not the best way in your case but we are opened for other solution from the community.

Wi6Labs team.
Wi6Labs team

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

Re: Introducing the new delivery for STM

Post by Rick Kimball » Fri Sep 23, 2016 3:11 pm

@Wi6Labs

What if I wanted to add all the pins on the Nucleo boards and use the Morpho header with the Arduino core. What would be the best way to accomplish that?

I guess what I'm getting at, in a a round about way, is that the way the library and variants work together isn't optimal. The library has pin knowledge. I contend that any pin knowledge should only be known by the variant. I'm suggesting that the library should be just that, a set of routines that can be used with any variant and any set of pin descriptions for the same chip. Any thoughts on that?

-rick
-rick

Ollie
Posts: 182
Joined: Thu Feb 25, 2016 7:27 pm

Re: Introducing the new delivery for STM

Post by Ollie » Fri Sep 23, 2016 3:39 pm

Rick, I do completely agree with you. The library should be available for any variant. Most of the "board" functions should be just for mapping the physical chip pins to items on the board, such as internal components or exposed pins.

+++ Ollie

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

Re: Introducing the new delivery for STM

Post by RogerClark » Fri Sep 23, 2016 8:34 pm

Guys

I had a couple of emails from STM and Wi6Labs, and basically it appears that Wi6 were only requested to create a system to handle Nucleo boards and hence had not designed a very flexibly architecture.

They sent me the handover document (which they said is confidential), but it doesn't contain anything that we don't already know, as its intended audience appears to be anyone that doesn't know about the Arduino IDE and the structure of the third party cores.

I'd really like to get the first pass BluePill code into the repo this weekend, so I suppose I could just action Rick's PR, but I'm still inclined to take a complete copy of libstm32 and make libstm32f103cx so that BluePill can be a variant of this, as could Maple mini

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

Re: Introducing the new delivery for STM

Post by Rick Kimball » Fri Sep 23, 2016 8:49 pm

RogerClark wrote: ... but I'm still inclined to take a complete copy of libstm32 and make libstm32f103cx so that BluePill can be a variant of this, as could Maple mini
seems like the best course
-rick

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest