[deprecated]First release of STM32F4 core

The official STMicroelectronics Arduino core
zmemw16
Posts: 1371
Joined: Wed Jul 08, 2015 2:09 pm
Location: St Annes, Lancs,UK

Re: First release of STM32F4 core

Post by zmemw16 » Wed Apr 12, 2017 8:19 am

wow, that's pricey!

its got sd and eeprom, experience of the Black 407 VET/ZET boards suggests those peripherals might not be mapped to the data sheet defaults.
i freely admit i had assumed the default usage previously, possibly explaining why nothing seemed to work excluding the leds :!:

stephen

fpiSTM
Posts: 177
Joined: Fri Sep 16, 2016 12:33 pm
Location: Le Mans, France

Re: First release of STM32F4 core

Post by fpiSTM » Wed Apr 12, 2017 8:37 am

stevestrong wrote:Just wanted to shortly ask: will this core be totally different from the Arduino Star OTTO?
Hope no at short term.

ag123
Posts: 716
Joined: Thu Jul 21, 2016 4:24 pm

Re: First release of STM32F4 core

Post by ag123 » Wed Apr 12, 2017 1:03 pm

my guess is that for a 'small' F4, 1'd need to go for an L4 series, but i'm yet to find any 'tiny' enthusiasts dev boards floating on ebay with that.
the closest is probably the nucleo which for now use a modest board space, i'd think if it gets too small it may become impossible to break out all the pins on 2.54mm headers :lol:
http://www.st.com/en/evaluation-tools/n ... 476rg.html
imho the F4, e.g. F407{V,Z}ET is a good board for connecting lots of things and has decent sram and flash

palmerr
Posts: 58
Joined: Tue Jan 31, 2017 6:21 am
Location: Melbourne, Australia

Re: First release of STM32F4 core

Post by palmerr » Thu Apr 13, 2017 6:07 am

Frederic,

I've been looking through your variant files for MCU Port to Arduino pin mappings while working on a "Black STM32F407VET6" variant - as we've described on the Wiki http://wiki.stm32duino.com/index.php?title=STM32F407.

The Nucleo board is fairly straightforward with its Uno V3 style headers.

With the Disco Board
- what was the reasoning behind starting with the inner pins on both sides, and the the outer pins?
- how hard did you try to match Uno-style Dxx standards for functions (e.g. SPI, I2C, UART)?

Thanks for any guidance you can provide on how to make the variants as easy to use as possible for programmers.

Richard

fpiSTM
Posts: 177
Joined: Fri Sep 16, 2016 12:33 pm
Location: Le Mans, France

Re: First release of STM32F4 core

Post by fpiSTM » Thu Apr 13, 2017 7:16 am

palmerr wrote:Frederic,
- what was the reasoning behind starting with the inner pins on both sides, and the the outer pins?
- how hard did you try to match Uno-style Dxx standards for functions (e.g. SPI, I2C, UART)?

Thanks for any guidance you can provide on how to make the variants as easy to use as possible for programmers.

Richard
Hi Richard,
As the F407 discovery has no arduino Uno V3 compatible connector, that's why I followed the board connectors.
I provided it as an example of pin mapping but it can be fully customized/reordered as the user want by updating in variant.cpp the const PinName digital_arduino[] array. You can also, remove some pins or add new one to access it thanks another id (As done for A0-A5 which was duplicated in the array).
In fact the array index match the pin numbering (Dxx):
digital_arduino[0] will give the pin D0
Currently, you have:
const PinName digital_arduino[] = {
//P1 connector Right side
PC0, //D0
PC2, //D1
PA0, //D2
PA2, //D3
PA4, //D4
PA6, //D5
PC4, //D6
PB0, //D7
PB2, //D8
...
It could be modified like that:
const PinName digital_arduino[] = {
//P1 connector Right side
PA4, //D0
PA6, //D1
PB0, //D2
PA2, //D3
PC0, //D4
PC2, //D5
PC4, //D6
PA0, //D7
PB2, //D8
...

When you have reordered this array, think to update the variant.h to reflect your change.
In the previous example, I've change the D4 and D5 pin. So, in variant.h:
before:
#define SS1 4
#define MISO 5
after:
#define SS1 0
#define MISO 1

The pin mapping could be fully customizable by the user. We only provide a basic one with the full set of pins.
Hope that's help.

palmerr
Posts: 58
Joined: Tue Jan 31, 2017 6:21 am
Location: Melbourne, Australia

Re: First release of STM32F4 core

Post by palmerr » Thu Apr 13, 2017 8:43 am

Frederic,

Thanks for the advice.

I'll go and look at my files and develop a pin mapping that makes sense for this board.

Richard

fpiSTM
Posts: 177
Joined: Fri Sep 16, 2016 12:33 pm
Location: Le Mans, France

Re: First release of STM32F4 core

Post by fpiSTM » Thu Apr 13, 2017 9:18 am

palmerr wrote:Frederic,

Thanks for the advice.

I'll go and look at my files and develop a pin mapping that makes sense for this board.

Richard
You're welcome.

Just two things :
1/ if you remove or add some pins in the array, think to update the enum in variant.h in order to have DEND aligned with the number of pin defined in the array.
2/ You could comment/uncomment line of pin mapping in PeripheralPins.c to use one instance instead of one other for a dedicated pin functions (TIM3 instead of TIM4, ADC2 instead od of ADC1,...) or simply do not give acces to a pin function if it's what you want. ;)

palmerr
Posts: 58
Joined: Tue Jan 31, 2017 6:21 am
Location: Melbourne, Australia

Re: First release of STM32F4 core

Post by palmerr » Thu Apr 13, 2017 12:41 pm

Frederic,

Thanks again.

Looking at how the SPI code searches for the right entry in, say the MOSI array in PeripheralPins.c, is it a bad idea to have a pin, say PB5, active for both SPI1 and SPI3?

It seems that the code will stop at the first entry, say SPI1, even if SPI3 is intended and the wrong AF will be applied to the pin.

Richard

fpiSTM
Posts: 177
Joined: Fri Sep 16, 2016 12:33 pm
Location: Le Mans, France

Re: First release of STM32F4 core

Post by fpiSTM » Thu Apr 13, 2017 1:15 pm

palmerr wrote:Frederic,

Thanks again.

Looking at how the SPI code searches for the right entry in, say the MOSI array in PeripheralPins.c, is it a bad idea to have a pin, say PB5, active for both SPI1 and SPI3?

It seems that the code will stop at the first entry, say SPI1, even if SPI3 is intended and the wrong AF will be applied to the pin.

Richard
Yes the first will be took but Pinmap feature does not deal the same pin for both instance (back ported from mbed). User has to choose which one he wants
So it is not a good idea to have the same pin for both instance of same function.
// {PB5, SPI1, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF5_SPI1)},
// {PB5, SPI3, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF6_SPI3)},
So you should choose one of them

ag123
Posts: 716
Joined: Thu Jul 21, 2016 4:24 pm

Re: First release of STM32F4 core

Post by ag123 » Thu Apr 13, 2017 8:31 pm

hi palmerr,
i think it'd be ok to simply have SPI1 on PB3-PB5, the trouble is the the board designer placed the onboard spi flash, the spi1 header and the nrf24 connector on those same pins, this would certainly mean unavoidable conflicts
if we simply have SPI1 on PB3-PB5 the onboard spi flash can be disabled or selected using PB0 which is connected to /CS (labelled F_CS) on the spi flash.
then if a 'user' wants to connect say an spi lcd he/she can still use spi1 without an issue
http://www.stm32duino.com/viewtopic.php ... =20#p26219
http://www.stm32duino.com/viewtopic.php ... =10#p26147

actually for i2c it appears that it could be used without conflict with spi1 as PB6 I2C1_CLK & PB7 I2C1_SDA are labelled as routing to NRF_CE & NRF_CS

otherwise you may want to simply pick another set of pins for i2c (this might be preferred, it would leave NRF_CE and NRF_CS as GPIO pins) and yet set another for uart as the {V,Z}ET6 board has many pins broken out

if we want to cater to the different scenarios i'd think we can have different 'variants' in which the 'user' would have to choose between the variant for SPI+I2C or perhaps a nrf24 connector specific variant as 2 different 'variants' using those same PB3-PB7 pins

Post Reply