STM32, ghetto style

[bingo600]

This code from here : (for a F030) using -Os
https://www.eevblog.com/forum/microcontrollers/stm32-ghetto-style/msg522326/#msg522326

Code: [Select]

#include <stm32f0xx.h>
#include "stm32f0xx_usart.h"


int main(void) {
USART_InitTypeDef USART_InitStruct;

USART_DeInit(USART1);
    //USART_Init(USART1, &USART_InitStruct);

while(1) {
    }
}
Gives this result:

Code: [Select]

arm-none-eabi-size main.elf
   text    data     bss     dec     hex filename
    596       0       0     596     254 main.elf

Latest launchpad

Code: [Select]

Thread model: single
gcc version 4.8.4 20140526 (release) [ARM/embedded-4_8-branch revision 211358] (GNU Tools for ARM Embedded Processors)

And the init+blinky+adc-random code from here
https://www.eevblog.com/forum/microcontrollers/stm32-ghetto-style/msg508984/#msg508984

Code: [Select]

arm-none-eabi-size main.elf
   text    data     bss     dec     hex filename
   1396      20       4    1420     58c main.elf

/Bingo

[westfw]

The 40% number is for JUST the library code, not including the startup code that compilation normally includes.
Add -nostartfiles to your compile.  Obviously, inlining the STP code doesn't have any effect on the size of the the vector table or C startup code.   The STP code to do the same function does shrink considerably.  (Presumably, the resulting program doesn't actually function correctly with no startup code.  It's just a compilation size experiment.)

Code: [Select]

BillW-MacOSX-2<10344> make nostartn
/usr/local/armgcc/bin/arm-none-eabi-gcc -DSTM32F10X_MD=1 -mcpu=cortex-m3 -mthumb -O3 -ffunction-sections -fdata-sections -Wl,--gc-sections -gdwarf-2 -include assert.h -o test_normal \
           -nostartfiles \
           -I normal main.c normal/stm32f10x_usart.c normal/stm32f10x_rcc.c start.c
/usr/local/armgcc/bin/arm-none-eabi-size test_normal
   text    data     bss     dec     hex filename
    592      36       0     628     274 test_normal
BillW-MacOSX-2<10345> make nostarti
/usr/local/armgcc/bin/arm-none-eabi-gcc -DSTM32F10X_MD=1 -mcpu=cortex-m3 -mthumb -O3 -ffunction-sections -fdata-sections -Wl,--gc-sections -gdwarf-2 -include assert.h -o test_inline \
           -nostartfiles \
           -I inlines main.c start.c
/usr/local/armgcc/bin/arm-none-eabi-size test_inline
   text    data     bss     dec     hex filename
    352      36       0     388     184 test_inline

The .zip file for the whole thing (including multiple versions of the un-modified STP files, for both 030 and 103) is over 500k. :-( I'll put a copy here: https://drive.google.com/file/d/0B6dMB5dovDUZdlFPbzFXemtxZjA/edit?usp=sharing

[dannyf]

the stm32f7?

Just looked up its datasheet (preview at this time).

Some highlights and low lights:

1) the fpu is a single precision unit;
2) 3x12bit adc, 7.2msps;
3) 18 timers: two advanced (tim1/8) + tim2/3/4/5, each with 4 output compare pins. Wow!
4) 4 usart/4uart: beats out F4 parts but way shy of TI's usart;

Sounds like well featured part. A little bit crippled due to sfpu + small-ish flash. Would be interesting to see how st prices this part.

With parts like this, there will be fewer and fewer reasons to use PIC32.

[westfw]

more explicit

Thanks.  That does help a lot.
There are two reasons that your results are inconsistent with mine:
1) You didn't inline the RCC functions as well.  This is pretty minor; it's a nice trivial function and the call setup is about the same as the inline sequence produced.  No big deal.
2) the big problem is that you missed that for the optimization I'm trying to invoke, the arguments to the inline functions should be CONSTANTS.  Instead of

Code: [Select]

USART_TypeDef *uart;
  uart=USART2;
    :
  myUSART_DeInit(uart);You should have

Code: [Select]

  myUSART_DeInit(USART2);I'm a little surprised (and disappointed) that gcc doesn't manage to do this optimization even for your original code.  Clearly uart has a constant value and is not volatile or anything; your code and the code with an explicitly constant argument REALLY ought to compile the same :-(

Here's the whole set of possible outcomes.  "MANY" means three calls to DeInit rather than one.

Code: [Select]

( plain )
   text    data     bss     dec     hex filename
   1244    1080      32    2356     934 a.out
-DCONSTANT
   1236    1080      28    2344     928 a.out
-DMANY
   1256    1080      32    2368     940 a.out
-DMANY -DCONSTANT
   1248    1080      28    2356     934 a.out
-DINLINES
   1060    1080      32    2172     87c a.out
-DINLINES -DCONSTANT
   1044    1080      28    2152     868 a.out
-DINLINES -DMANY
   1384    1080      32    2496     9c0 a.out
-DINLINES -DMANY -DCONSTANT
   1084    1080      28    2192     890 a.out


I discovered something else interesting, accidentally.  Want to save 528 bytes of code and 1k of data space (initialized data, so it takes up flash space) in most of your programs?  Define your own exit() function.

Code: [Select]

void exit(int r) {while(1);}  Apparently the standard runtime defaults to a fancy version of exit that calls registered exit procedures.  And that pulls in code to register those procs.  And support functions.  528 bytes worth of code plus over 1000 bytes of "data" to support something that shouldn't happen in an embedded system (calling exit() or allowing main() to return.)  Sigh.

(Edited to include the substantial .data contribution of the default exit()) (Hmm.  It may be that since I'm using a different compile procedure and maybe different STP libs (from the Nucleo downloads, rather than the STP downloads) that  my results are different than others...)

[Koepi]

There is something really weird in your setup, it seems.

With self-defined exit()-function:

Code: [Select]

text    data     bss     dec     hex filename
   4914     124     568    5606    15e6 stm32-7seg.elf
And now without:

Code: [Select]

   text    data     bss     dec     hex filename
   4914     124     568    5606    15e6 stm32-7seg.elf
Making main() void instead of int:

Code: [Select]

   text    data     bss     dec     hex filename
   4914     124     568    5606    15e6 stm32-7seg.elf

[westfw]

Hmm.  I am using the generic ARM compiler from ARM, which doesn't have ST-specific startup files/etc...
It seems to be sucking in exit() from: arm-none-eabi/lib/armv7-m/libc.a(lib_a-exit.o)

[westfw]

Hmm.   So I installed CoIDE and the Windows ARM compiler (4.8.4!) on my windows XP VM, and it does indeed have different behavior WRT exit()/etc.  It also seems to have a memory leak, so that after a dozen or so "rebuild" steps, I get:

Code: [Select]

BUILD FAILED
java.lang.OutOfMemoryError: PermGen space
Total time: 1 second
It seems to add about 2M to the memory usage for each build, and craps out around 190MB total (according to the task manager.)  that seems low, given that the VM has 2G and the system claims 1.5G is still free when CoIDE stops working.  Grr.

[gmb42]

Note that there are some moving parts around for exit().  Depending on your toolchain and how it's setup, it might be using newlib-nano 2 which has a lite option for exit that makes the register and exit functions weak references, so if they aren't used, then the linker doesn't include them

I believe that newlib-nano 2 was introduced with gcc 4.8.  See here for more info.

[richard_t]

Hmm.   So I installed CoIDE and the Windows ARM compiler (4.8.4!) on my windows XP VM, and it does indeed have different behavior WRT exit()/etc.  It also seems to have a memory leak, so that after a dozen or so "rebuild" steps, I get:

Code: [Select]

BUILD FAILED
java.lang.OutOfMemoryError: PermGen space
Total time: 1 second
It seems to add about 2M to the memory usage for each build, and craps out around 190MB total (according to the task manager.)  that seems low, given that the VM has 2G and the system claims 1.5G is still free when CoIDE stops working.  Grr.

There's a fix for that - edit CoIDE.ini (mines in C:\CooCox\CoIDE) to include:

Code: [Select]

--launcher.XXMaxPermSize
256M
-vmargs
-Xms60m
-Xmx512m
-XX:+UseConcMarkSweepGC
-XX:+CMSClassUnloadingEnabled

I put it at the end of that file, and restart CoIDE.

No idea what the above does, I'm not a Java person, but I hope that helps for you.

Richard.

[westfw]

There's a fix for that

I was hoping there was, but not looking forward to trying to track it down.
Thanks for providing the option.  It seems to work pretty well (there's still some "leak", but it seems to top out at about 240k, and then starts fixing itself...)

[dannyf]

I'm running an older version of  CoIDE (1.7.4 I think) and haven't encounter that issue.

Have yet to find a compelling reason to upgrade, .

[IuriC]

Nice work guys!

I bought an STM32F4 Discovery board a while back, maybe is time to start play with.

[Koepi]

Iuri, you do realize that there is a "small" difference between a STM32F030 minimalistic board and a F429 Disco?

[dannyf]

There are a few different kinds of STM32F4 boards. CoIDE I think doesn't have full support for them all.

However, you can simply compile to a supported STM32F4 chip (F40x chips for example), as the library makes no distinction between F40x or F41x or F42x chips.

Alternatively, Keil / IAR have full support for all F4 series at this point.

The basic principles outlined earlier should work and the code should also work, with minimum changes.

The F429Discovery is a nice board, with the LCD.

[Koepi]

From the age of the chips and the SPL interface the F0xx and F4xx are close relatives; the F1xx sticks out a bit as it is older and the code/SPL looks a bit different. Especially when you look at the GPIO setup for example, it looks similar, but for example setting up a pin with pullup/pulldown is different.

(I do have the F4-Disco based on F407 as well but it is a bit smaller, thus it wouldn't make my point as clear as the F429 Disco does )

[dannyf]

Yeah. F0 has quite a few things going for it: the AF interface is much cleaner; the GPIO flexibility much bigger, and GPIO is hanging off AHB vs. APB....

F1, being quite a bit older, may be refreshed soon.

[westfw]

I also agree that the F0 GPIO interface is "cleaner" than the F1s.  I was shocked on the F1 when I noticed that you had to handle the GPIO bit configuration via separate registers depending on bit number, and then pleasantly surprised when this wasn't the case on F0.
This may be a rare case where (westfw, dannyf, koepi) all agree on something!

[dannyf]

A quick experience in CoIDE vs. Keil.

I am working on an IMU algorithm. 6DOF acceleration / gyro sensors to drive 4 channel pwm generators, uart + bluetooth, lcd, and wii control. Fairly math intensive: the IMU is quaternion driven and the pwm generators are behind a 4x4 PID matrix.

Under CoIDE, it compiles to about 18Kb on a STM32F100 and would not fit into a STM32F030, under the most aggressive optimization.

It compiles to 15Kb on Keil, with no optimization, and down to 8Kb with the most aggressive optimization + Microlib.

[westfw]

So... What's twice as big?

I keep seeing reports of "Keil produces much better code than gcc for arm", but no one ever posts are more detailed analysis :-(

Floating point?  I hear that by default, gcc has a relatively bulky SW floating point implementation.  (You can blow an AVR application out of flash space by forgetting the -lm avr float library, and letting it use the gcc float library instead, for instance.  ( http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_math )

[dannyf]

Not quite ghetto but in the same spirit: Launchpad + mpu6050 + pwm output on a led.

The launchpad reads off mpu6050, perform the fusion + imu algorithm, and use the output (in this case, the accelerometer reading on the X-axis) to dim the led.

The sensor itself is quite sensitive so a little bit of tilting could change the led's brightness significantly.

The mpu is mounted on the base side of the pcb and the led cross two pins. To show the ghetto-ness, no resistor on the led.

[Koepi]

I didn't take a closer look at it yet, but the MSP430G2 launchpad comes with a "spare" µC. It's probably possible to build up something ghetto style abusing a dip socket mount.
Just as blue print, this isn't a working sample, just the idea.

There you could hook up the msp6050 and the LED as well, a few GPIOs are available

[dannyf]

That's definitely ghetto  enough, .

I don't have a MSP430 board - the launchpad I have is one of the earliest ones, with LM4F120.

MSP430 is quite interesting in that the mpu6050 dmp example from Invensense is implemented on msp430 so minimal changes are needed.

[Koepi]

Uh, my bad, just realized that you have a Stellaris (=Cortex M3) launchpad there; MSP430 is TIs own low power 16bit processor architecture. I didn't test it yet as I didn't find the motivation to install a suitable IDE and compiler for it.
Unfortunately, the M3 series from TI has been given up end of 2012. LM4F is the supposed Cortex M4 based successor (so your launchpad can't be that old ), but allegedly cheap low-pin-count versions are not yet available.

[westfw]

LM4F is the supposed Cortex M4 based successor

Briefly.  TI gave up the LM prefix and the ARM microcontrollers are now "TIVA TM4Cxxxx"   The LM4F based "stellaris launcpad" was replaced with the "Tiva Launchpad" and has a TM4C123GH6PM to replace the  LM4F120H5QR.  They're ALMOST the same.

[dannyf]

I used a lot of LM3S parts - 8962 for example.

They are (were?) really good mcus with some severe bugs, however.

Luminary is really the first company that started to cheapen 32-bit mcus - they advertised <$1 pricing then - which you could actually buy.

allegedly cheap low-pin-count versions are not yet available.

LM offered some soic parts - in the LM3Sxxx family for example but they were incredibly difficult to get, even for volume buyers.

TI basically went the upper-market route after they took over. Fortunately, they retained driverlib.