STM32CubeMX :: STM32F030F4 support

Development of new Cores using the STMCubeMX and HAL
User avatar
RogerClark
Posts: 5943
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: STM32CubeMX :: STM32F030F4 support

Post by RogerClark » Sat Apr 16, 2016 11:29 pm

Guys

I thought I'd just try exporting a project from the Cube which has just USB and just a virtual serial device

But, I immediately have problems as soon as I tick the USB box in the config screen, as it seems to have an issue with Timer 1 and also the clock config screen has unreasonable issues :-(

So I thought I'd try loading an built in board (the Nucleo F103RB), but that has config errors even if I make no changes at all.

The Cube has issues with the SPI for some reason.


I wonder if my installation of the cube is broken somehow - possible as I did an update a few days ago.

(Prior to that I don't recall these sort of issues, but I never actually use (tried to compile) an source code produced by the Cube)

I guess my best bet is probably to delete the whole installation and try to download it all again :-(

Edit
I thought I'd try to load Vassili's F103C8 project, but I brings up a popup asking to "migrate" or "continue", doing either results in errors and it then won't export the code.

Arrggghhh

I'll see if I can find a online tutorial that shows how to use the Cube, as at the moment, either its broken or I'm missing something fundamental

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

Re: STM32CubeMX :: STM32F030F4 support

Post by Vassilis » Sun Apr 17, 2016 7:05 am

RogerClark wrote:Guys

I thought I'd just try exporting a project from the Cube which has just USB and just a virtual serial device

But, I immediately have problems as soon as I tick the USB box in the config screen, as it seems to have an issue with Timer 1 and also the clock config screen has unreasonable issues :-(

So I thought I'd try loading an built in board (the Nucleo F103RB), but that has config errors even if I make no changes at all.

The Cube has issues with the SPI for some reason.


I wonder if my installation of the cube is broken somehow - possible as I did an update a few days ago.

(Prior to that I don't recall these sort of issues, but I never actually use (tried to compile) an source code produced by the Cube)

I guess my best bet is probably to delete the whole installation and try to download it all again :-(

Edit
I thought I'd try to load Vassili's F103C8 project, but I brings up a popup asking to "migrate" or "continue", doing either results in errors and it then won't export the code.

Arrggghhh

I'll see if I can find a online tutorial that shows how to use the Cube, as at the moment, either its broken or I'm missing something fundamental
I use STM32CubeMX v4.14.0 with STM32CubeF1 Release v1.3.1. You probably do not have installed the old one firmware file (1.0.0) that sheepdoll's package needs. That's why you get the message "Migrate or Continue". If you have installed the 1.3.1 firmware just press on <Migrate>.
The auto update doesn't work for me. I forced to download the firmware file 1.3.0 from there and the patch 1.3.1 from there.

I tried the CubeMX's USB Virtual COM port to the STM32F103C8 and it's recognized correctly by my windows PC as virtual com port in device manager. The produced bin file is 20kB bigger.

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

Re: STM32CubeMX :: STM32F030F4 support

Post by RogerClark » Sun Apr 17, 2016 7:51 am

Thanks Vassilis

It took several attempts to update the Cube.

I also had to run as Administrator, otherwise it fails to install the new files when it finishes downloading them


ummm

20kb for USB Serial is terrible. Perhaps the problem is the --whole-archive flag which was needed to resolve issues in libmaple but may be causing the compiler / linker to link things which are not used.

The HALMX binaries seem to be 2 x as big as lib maple, even without using the virtual com port

I recall a long time ago, we tried to remove the --whole-archive flag and initially it looked like it was OK, but then we had problems with timer callback functions.

https://github.com/rogerclarkmelbourne/ ... 960851d64b

But it may be worth trying without --whole-archive for this core

Edit.

I tried removing the --whole-archive flag from the build command, but it doesn't make the code any smaller, and it also causes a warning about

Code: Select all

undefined reference to `_sbrk'
And only reduces the code size by about 75 bytes


So I don't think removing the --whole-archive flag is possible.

Re: USB Serial

The USB Serial implementation in libmaple seems to add about 6k to the binary,

So it looks like the STM implementation either has a lot of additional features or is inefficient (in terms of code size).


It would probably be possible to take libmaple's USB Serial implementation and covert it to HAL - but, I suspect it would be a lot of work :-(

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

Re: STM32CubeMX :: STM32F030F4 support

Post by Vassilis » Sun Apr 17, 2016 5:07 pm

analogRead() is ready. I have to write the analogWrite() for PWM and I will send a PR.

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

Re: STM32CubeMX :: STM32F030F4 support

Post by sheepdoll » Mon Apr 18, 2016 1:52 am

Still have not been able to get the mac to see the USB CDC VCP. Does anyone know if I need the 1k5 or so resistors on the D+ or D- lines. The online docs say they are not needed.

The next thing I plan to attempt is to connect one of my 2X40 LDC displays and see If I can get them to work through the F Malpartida libraries.

As for code bloat, I think that is the way things are done now. I can still write hand tuned clock counted code on my UNO (clones)

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

Re: STM32CubeMX :: STM32F030F4 support

Post by mrburnette » Mon Apr 18, 2016 2:03 am

Does anyone know if I need the 1k5 or so resistors on the D+ or D- lines.
In circuits I have used, only D- is pulled high (3.3V) by approx. 1500 Ohms.

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

Re: STM32CubeMX :: STM32F030F4 support

Post by sheepdoll » Mon Apr 18, 2016 3:08 am

Well F Malpartida libs do not work out of the box. They call delayMicroseconds. I found this in wiring.h where it is defined for Teensy using inline asm which the arm g++ compiler barfs on. "Error: instruction not supported in Thumb16 mode." Not sure where that came from. If it was something I put in when I was stubbing out the .h files. I have not done any pulls for a week or so.

delayMicroseconds() is the function I so need the most. Simple to do on the AVR, set a timer and poll on it. I tired to see if I could enable TIM1 in cubeMX but that seemed to lead so the unhandled interrupt vector WWDT exception that hangs things on load.

I think I am going to watch my favorite film tonight _Doctor Strangelove_ Nobody could pull off those camera pointed at the mirror pullbacks like Kubrick could. (Zemekis cheats and uses CGI for the effect.)

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

Re: STM32CubeMX :: STM32F030F4 support

Post by Vassilis » Mon Apr 18, 2016 4:39 am

sheepdoll wrote:Well F Malpartida libs do not work out of the box. They call delayMicroseconds. I found this in wiring.h where it is defined for Teensy using inline asm which the arm g++ compiler barfs on. "Error: instruction not supported in Thumb16 mode." Not sure where that came from. If it was something I put in when I was stubbing out the .h files. I have not done any pulls for a week or so.

delayMicroseconds() is the function I so need the most. Simple to do on the AVR, set a timer and poll on it. I tired to see if I could enable TIM1 in cubeMX but that seemed to lead so the unhandled interrupt vector WWDT exception that hangs things on load.

I think I am going to watch my favorite film tonight _Doctor Strangelove_ Nobody could pull off those camera pointed at the mirror pullbacks like Kubrick could. (Zemekis cheats and uses CGI for the effect.)
I rewrote the delayMicroseconds() function to work on STM32F1 MCUs. check in to the Github updated wiring.h file.

User avatar
GrumpyOldPizza
Posts: 174
Joined: Fri Apr 15, 2016 4:15 pm
Location: Denver, CO

Re: STM32CubeMX :: STM32F030F4 support

Post by GrumpyOldPizza » Wed Apr 20, 2016 3:40 pm

mrburnette wrote:
ST's HAL is all C. No C++. All I/O drivers are in C for compatibility assurance.
I once read, but cannot now find the reference, that come outfits have a strict no-C++ rule for embedded uC code. I believe it was because of the difficulty to formally profike memory usage ... so, maybe I read this in regard to military/space applications.
C++ has the issue of a lot of implied "new" operations, which tigger a malloc(). malloc() is normally neither thread safe, nor usable in interrupts. So unless you have a malloc() implementation that takes this into account you are running the risk of hard to track bugs.

A secondary issue is that C++ adds some hidden code/data size overhead (static constructors for example). Since the bean counters want to always buy the cheapest MCU, code/data size is always at a premium.

I guess neither other those are critical for small sized applications. But if you have bigger applications chances that C++ will bite you are higher.

Regarding the military/space applications, they are specified usually with the constraints that you cannot use any form of dynamic memory allocation after a initialization phase. So no malloc() or alloca(). As you probably guess that is a problem with classes that have virtual methods, as a new object instantiation requires dyanmic memory allocation ...

Anyway, a lot of commercial systems require MISRA-C compliance as a basic software quality criterium. There is a corresponding MISRA-C++ standard, but it's outdated (2008) and did not seem to gain traction.

- Thomas

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

Re: STM32CubeMX :: STM32F030F4 support

Post by Slammer » Wed Apr 20, 2016 11:14 pm

A agree C++ is a possible threat to stability specially in very small systems, but if you follow strict rules you can have the advantages of C++, without problems.
I am using C++ for embedded and some times critical applications without problems. Some strategies can improve stability and size of application:
- no dynamic allocation, define new stub functions for new(), malloc() etc... to be sure that there is no dynamic allocation.
- remove completely rtti support
- remove or replace some standard functions related with constructors etc...
- don't use, if possible, stl containers or streams or other standard c++ libraries.

In other words use C++ as an enhanced C with classes without bells and whistles and you will be in the safe side.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest