STM32CubeMX :: STM32F030F4 support

Development of new Cores using the STMCubeMX and HAL
User avatar
ahull
Posts: 1627
Joined: Mon Apr 27, 2015 11:04 pm
Location: Sunny Scotland
Contact:

Re: STM32CubeMX :: STM32F030F4 support

Post by ahull » Thu Apr 14, 2016 11:50 am

Sounds like good progress. It will be interesting to see which (cube or maple/stmduino) builds the more compact/efficient code.
- Andy Hull -

User avatar
ddrown
Posts: 136
Joined: Sat Jan 09, 2016 4:49 am

Re: STM32CubeMX :: STM32F030F4 support

Post by ddrown » Thu Apr 14, 2016 3:09 pm

RogerClark wrote:OK.

I worked out what the problem was

The new version of the ST-Link CLI Exe (version 2.4) is not compatible with the stlink_upload.bat command

The new version seems to need the keyboard to be pressed (e.g. return pressed), after the upload if the -Run option is used.

So either we need to bundle version 2.1 of the CLI in the repo or we modify the bat file command line to remove the -Run option
Can you try this and see if it fixes it?

https://github.com/ddrown/Arduino_STM32 ... 954d448785

User avatar
Vassilis
Posts: 320
Joined: Thu May 21, 2015 6:42 am
Location: Thessaloniki, Greece
Contact:

Re: STM32CubeMX :: STM32F030F4 support

Post by Vassilis » Thu Apr 14, 2016 8:44 pm

A few minutes ago I sent a new PR. SPI library is added and works ok :D

- wiring.h The delayMicroseconds was re-written for STM32. The previous assembly code wasn't work correct to the tests I had made.
- wiring_digital.c The LOW and HIGH was opposite on digitalRead(...). Fixed!
- SPI library is added. It supports only the basic functions (methods)

-= Functions =-

Code: Select all

void begin(void)
uint8_t transfer(uint8_t _data) const
uint16_t transfer16(uint16_t data)
void transfer(uint8_t buf, size_t count)
void setClockDivider(uint8_t clockDiv)
void setBitOrder(uint8_t bitOrder)
void setDataMode(uint8_t dataMode)
The interrupts and DMA SPI modes are not implemented yet.
Were Added two batch (*.bat) files for renaming the spi.c and spi.h files that are produced from the CubeMX to _spi.c and _spi.h. Moreover, the batch edits the _spi.c file and replaces the

Code: Select all

 #include "spi.h"
file with the

Code: Select all

#include "_spi.h"
one.

For testing the SPI library I used my previous VS1003 (VS1053) library and it works ok !
The library has been tested only on STM32F103C8 micro-controller

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

Re: STM32CubeMX :: STM32F030F4 support

Post by RogerClark » Thu Apr 14, 2016 9:12 pm

Thanks Vassilis

I will pull onto my local machine and test it with a ILI9341 display ( when I find the non-dma versions of the LCD libraries)

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

Re: STM32CubeMX :: STM32F030F4 support

Post by RogerClark » Thu Apr 14, 2016 9:16 pm

ddrown wrote: Can you try this and see if it fixes it?

https://github.com/ddrown/Arduino_STM32 ... 954d448785
I will give that a try.

BTW. I think ideally we should pass the run address, so I may adjust the bat file to do that.

Strangely it doesnt seem to need the -Run command, the -Rst seems to be enough when its running from the base of flash, but I guess we may want to change the start address at some time, so having the Run option may come in handy

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

Re: STM32CubeMX :: STM32F030F4 support

Post by RogerClark » Thu Apr 14, 2016 10:01 pm

ahull wrote:Sounds like good progress. It will be interesting to see which (cube or maple/stmduino) builds the more compact/efficient code.
The HAL code is creating bigger binaries than libmaple

I'm not sure why this is, but Blink in libmaple with NO USB Serial, is only 6k, but its around 12k with the HAL

libmaple with USB serial is 12k for blink

Ram usage is also about twice as much using the HAL i.e blink takes 1.5k on libmaple and 3k with the HAL


But its early days with the HAL and there may be ways to stop unused code being linked in.

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

Re: STM32CubeMX :: STM32F030F4 support

Post by RogerClark » Thu Apr 14, 2016 11:01 pm

Can anyone advise on the best way to "patch" the files from the core when making a new variant, or simply updating to a later export from the Cube

Because we need to write our own main.c and also it looks like we need to be able to modify the start offset vector (which is hard coded to 0x00)

I don't think we can use the unix patch command as we the location of the patch may change, we may need to do it via some sort of text search and replace.

Or perhaps the only way to do it is to write instructions that need to be manually implemented. ?

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

Re: STM32CubeMX :: STM32F030F4 support

Post by RogerClark » Fri Apr 15, 2016 10:55 am

Vassilis wrote:A few minutes ago I sent a new PR. SPI library is added and works ok :D

- wiring.h The delayMicroseconds was re-written for STM32. The previous assembly code wasn't work correct to the tests I had made.
- wiring_digital.c The LOW and HIGH was opposite on digitalRead(...). Fixed!
- SPI library is added. It supports only the basic functions (methods)

-= Functions =-

Code: Select all

void begin(void)
uint8_t transfer(uint8_t _data) const
uint16_t transfer16(uint16_t data)
void transfer(uint8_t buf, size_t count)
void setClockDivider(uint8_t clockDiv)
void setBitOrder(uint8_t bitOrder)
void setDataMode(uint8_t dataMode)
The interrupts and DMA SPI modes are not implemented yet.
Were Added two batch (*.bat) files for renaming the spi.c and spi.h files that are produced from the CubeMX to _spi.c and _spi.h. Moreover, the batch edits the _spi.c file and replaces the

Code: Select all

 #include "spi.h"
file with the

Code: Select all

#include "_spi.h"
one.

For testing the SPI library I used my previous VS1003 (VS1053) library and it works ok !
The library has been tested only on STM32F103C8 micro-controller
Hi Vassilis

There seems to be a problem with renaming spi.c etc to _spi.c as the Arduino IDE seems to attempt to compile both _spi.c and spi.c

I get the following error messages for the Generic STM32f103C8

Code: Select all

C:\Users\rclark\AppData\Local\Temp\build2460407063954389677.tmp\_spi.c.o: In function `MX_SPI2_Init':
D:\Documents\Arduino\hardware\HALMX_Arduino_STM32\HALMX\variants\MXBluePillF103C8\Src/_spi.c:44: multiple definition of `MX_SPI1_Init'
It just seems to be the Generic STM32F103C8 variant that has this issue, but this appears to be the only variant which has _spi.c

Which variant did you test with ?

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

Re: STM32CubeMX :: STM32F030F4 support

Post by RogerClark » Fri Apr 15, 2016 11:02 am

Guys

I have started to add bootloader support to the Generic STM32F103C8 board (variant)

However at the moment, this variant is not compiling because of issues with Vassili's SPI code.

But if anyone wants to give it a go e.g. on a Maple mini, you can get the previous commit version (prior to the addition of the SPI code)

https://github.com/rogerclarkmelbourne/ ... c0e3a6404f

Select STM32F103C8 (20k ram 64k flash), which now defaults to the bootloader upload

Compile and upload something e.g. blink

Then when the compile has completed and the IDE tries to upload the sketch, press the reset (and release) the reset button on the maple mini, and DFU util should then find the bootloader (DFU device) and upload the sketch

Note. At the moment about the only thing you can test is Blink as we have not got Serial USB working yet.

But its a step in the right direction.

User avatar
Vassilis
Posts: 320
Joined: Thu May 21, 2015 6:42 am
Location: Thessaloniki, Greece
Contact:

Re: STM32CubeMX :: STM32F030F4 support

Post by Vassilis » Fri Apr 15, 2016 1:26 pm

RogerClark wrote: Hi Vassilis

There seems to be a problem with renaming spi.c etc to _spi.c as the Arduino IDE seems to attempt to compile both _spi.c and spi.c

I get the following error messages for the Generic STM32f103C8

Code: Select all

C:\Users\rclark\AppData\Local\Temp\build2460407063954389677.tmp\_spi.c.o: In function `MX_SPI2_Init':
D:\Documents\Arduino\hardware\HALMX_Arduino_STM32\HALMX\variants\MXBluePillF103C8\Src/_spi.c:44: multiple definition of `MX_SPI1_Init'
It just seems to be the Generic STM32F103C8 variant that has this issue, but this appears to be the only variant which has _spi.c

Which variant did you test with ?
I am sorry about that. The MXBluePillF103C8\Src\spi.c and MXBluePillF103C8\Inc\spi.h files must be deleted. These files are already patched and renamed as MXBluePillF103C8\Src\_spi.c and\MXBluePillF103C8\Inc\_spi.h in to the MXBluePillF103C8 variant I used.
Last edited by Vassilis on Fri Apr 15, 2016 1:40 pm, edited 1 time in total.

Post Reply