Tag Archives: arm

Code Size changes with “int” on 8bit and 32bit platforms

I was looking for a few bytes extra flash today, and realized that some old AVR code I had, which used uint8_t extensively for loop counters and indexes (dealing with small arrays) might not be all that efficient on the STM32 Cortex-M3.

So, I went over the code and replaced all places where the size of the counter wasn’t really actually important, and made some comparisons. I was compiling the exact same c file in both cases, with only a type def changing between runs.

Compiler versions and flags

platform gcc version cflags
AVR avr-gcc (GCC) 4.3.5 -DNDEBUG -Wall -Os -g -ffunction-sections -fdata-sections -Wstrict-prototypes -mmcu=atmega168 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums
STM32 arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.6.2 20120316 (release) [ARM/embedded-4_6-branch revision 185452] -DNDEBUG -Wall -Os -g -ffunction-sections -fdata-sections -Wstrict-prototypes -fno-common -mcpu=cortex-m3 -mthumb

And… here’s the results

counter type avr-size arm-none-eabi-size
unsigned int 1318 844
uint8_t (original) 1160 856
uint_least8_t 1160 856
uint_fast8_t 1160 844
int 1330 820
int8_t 1212 872
int_least8_t 1212 872
int_fast8_t 1212 820

I would personally say that it looks like ARM still has some work to go on optimizations. If _least8 and _fast8 take up more space than int it’s not really as polished as the avr-gcc code yet. For me personally, as this code no longer has to run on both AVR and STM32, I’ll just use int.

So, after extending this a bit, my original conclusion about the fast_ types not being fully optimized with arm-gcc were wrong. It’s more that, on AVR, your “don’t care” counters should be unsigned for smaller size, while on STM32, they should be signed (Though I still think it’s dodgy that int_least8_t resulted in bigger code than int_fast8_t) Also, even if signed is better in the best case, the wrong signed is also the worst case. Awesome.

STM32L Discovery Board – first impressions

I’ve been increasingly intrigued by the plummeting price of ARM cortex-M3 devices, both the chips themselves, and also some of the development boards. With ST’s newest, the low power STM32L Discovery board, I thought I’d take the plunge, see what could be done. For a few dollars more than the STM32VL Discovery board, you get:

  • Twice the RAM
  • Lower power consumption
  • A touch slider interface
  • A nice glass LCD

I only got it today, and given that I run linux at home, it’s a bit of a minefield of toolchains, especially if I want to use neat things like hardware debugging. (One of the sexy things you get when you move up to a “real” CPU) I’m sure I’ll write more as this unfolds slowly, but here’s some first impressions.

The touch slider is neat! The preloaded demo code cycles through a few different modes showing off lower power consumption, but that sort of stuff you could read off the spec sheet. A nice responsive touch slider and a good clear LCD, with a couple of user LEDs and another hard button (The slider can also be used as 4 buttons) makes this a pretty kick arse basic platform!

The screen printing is a bit messy and cluttered, with lots of different sizes. I really don’t know why they felt they need to print the numbers of every resistor and capacitor? It’s a little hard to find which jumper is which. Continuing on cosmetics, why are some jumpers labelled JP, and some labelled CN? Why are some of them on the bottom of the board, and some on top? Odd. Anyway, let’s see if we can get some code on it!