Getting started with STM32 bare metal, but with standard library

Philipp Krause · ‎2018-02-18

Posted on February 18, 2018 at 19:55

A few days ago I got a few STM32 boards (STM32F0-Discovery, STM32F031 Nucleo-32, STM32F302 Nucleo-64) to have a quick look at the STM

Is there some simple 'Hello, World!'-style tutorial, that shows setting up an UART for printf() and possibly basic use of timers? I want to use a free toolchain (I have the arm-none-eabi-gcc Debian package installed, and compiled texane stlink). I want to avoid the use of complex or non-free stuff (IDE, Cube, libraries such as SPL or HAL). Basically I'm looking for a tutorial like the

http://www.colecovision.eu/stm8/STM8S-DISCOVERY%20Serial.shtml

, but for an STM

Philipp

P.S.: By 'with standard library' I mean that functions from the standard library that make sense for, but are not required by, a freestanding C implementation (e.g. the string.h stuff) should be available.

#bare-metal-arm #gcc #stm32f0 #tutorial

Note: this post was migrated and contained many threaded conversations, some content may be missing.

waclawek.jan · ‎2018-02-19

Posted on February 19, 2018 at 17:13

Isn't that the aim of EEMBC ?

The proclaimed aim, maybe; but so far they failed to materialize that, IMO - except the low-power benchmark, which appears to deliver merital information.

Also, 'embedded' is a widely abused word.

As you've quoted:

IoT, automotive surround view and image recognition, data centers, ultra-low power microcontrollers, and smartphones/tablets and browsers (including Android platforms

of which none is micro*controller* related, and 8-bit comparable (I hope we agree that IoT is just a buzzword, lowering the credit of anybody using it in what is supposed to be a technically-oriented text).

JW

waclawek.jan · ‎2018-02-19

Posted on February 19, 2018 at 17:26

All these benchmarks have their place in comparing the performance of different 'systems' C (implementations ot the C programmer - consisting in particular of hardware, compiler and standard library).

What *would* make these benchmarks really useful, then, would be to compare different compilers (you would need to give up the 'free only' view for that, as the most interesting compilers are the commercial ones, sorry), different incarnations of the 32-bitters, and - what's even more interesting - using the very same 'system' under different conditions. For example, you might reveal the impact of the jumpcache (a.k.a. ART in 'F4/'F7) by performing a standard benchmark while interrupts disturb the jumpcache. Or, running the benchmark from FLASH versus SRAM(s), or having its data in different memories (e.g. I have a suspiciion that SRAM2 imposes one waitstate in the 'F4 as compared to SRAM1, but I haven't gotten to do any relevant test yet). Or showing the impact of write buffers. Running/having data/stack in external memories. Showing impact of clashes with other bus masters. Finding out the impact of instruction mix on interrupt latencies and jitter. Or showing impact of various *compiler* settings, especially in relationship with various incarnations of the ARM core (M0/M3/M7).

That would be merital; but - and I stand by it - comapring to 8-bitters *is not*.

JW

Philipp Krause · ‎2018-02-19

Posted on February 19, 2018 at 17:28

EEMBC benchmarks are non-free. Except for Coremark, they AFAIK, do not work on systems as small as an STM8 or STM32.

Philipp

Philipp Krause · ‎2018-02-19

Posted on February 19, 2018 at 17:41

Benchmarks are useful to measure capabilities for computation (and possibly energy consumption or code size). Even on microcontrollers, the speed of computations, etc matters. And then benchmark results can be useful to compare systems.

That there are other aspects not measured by benchmarks - memory sizes, interrupt latency, peripherals, etc that might be important for some choices does not mean that what is measured by benchmarks is irrelevant.

Philipp

henry.dick · ‎2018-02-19

Posted on February 19, 2018 at 17:52

'

These benchmarks

https://community.st.com/0D50X00009Xkf61SAB

https://community.st.com/0D50X00009XkWgpSAF

'

not sure if they are completely useless. A more accurate statement would have been that they have limitations.

Sure, no one uses a Cortex-M0 for number crunching but they do use those devices in processing integers, frequently I may add, and sometimes floating point math. so there is some merit in wanting to understand those chips' performance under a benchmark, like dhrystone or whetstone...

TI even produced an appnote with mcu-focused benchmarking. it is written in C so porting would be quite easy.

As to a mcu-specific benchmark, given the diversity of the peripherals, it would be difficult, if not outright impossible, to make apple-to-apple comparisons.

waclawek.jan · ‎2018-02-19

Posted on February 19, 2018 at 17:53

does not mean that what is measured by benchmarks is irrelevant.

Okay, use 'misleading' then.

JW

henry.dick · ‎2018-02-19

Posted on February 19, 2018 at 17:54

you then likely had cmsis in your compilation.

what you failed to realize is that you are comparing just the core - maybe a little bit of flash - performance. So your numbers would have been identical had you run the code on the same cores from different manufacturers.

Philipp Krause · ‎2018-02-19

Posted on February 19, 2018 at 17:59

Different compilers, with different compiler options. But it is always good to look a little bit over the fence, and get a few number for other devices - even if one doesn't try that many compiler / options combinations for those other devices. For those 'other devices', it might make sense to instead include different devices in a similar price range in a comparison.

I have used benchmarks to look into the effect of different compiler versions and compiler options on the STM8 side (see e.g.

http://colecovision.eu/stm8/compilers.shtml

) for a compiler comparison that includes such data from benchmarks as one aspect. My main focus is still on the STM8 and other 8-bit architectures, I'm just trying to get a few numbers from the STM32 side here for a bit of context.

Philipp

henry.dick · ‎2018-02-19

Posted on February 19, 2018 at 18:07

'

I'm just trying to get a few numbers from the STM32 side

'

to get you started:

https://dannyelectronics.wordpress.com/2016/11/14/whet-stone-or-dhry-stone/

there are plenty of others as well.

the key is to understand that benchmarks are useful because they have severe limitations. the user has to recognize when a benchmark is meaningless, when its limitations are acceptable, ...

waclawek.jan · ‎2018-02-19

Posted on February 19, 2018 at 18:19

A more accurate statement would have been that they have limitations.

More accurate statements wouldn't spark Philipp's interest 😉 I hopefully planted enough doubt by now.

frequently I may add, and sometimes floating point math

Sure. And usually you do it in 32-bit, not because you need to, but because that's easy to do - and that's what the benchmarks do, too. But that's also unfair for the 8-bitters.

And even more frequently you may compare and jump and do bit arithmetics. That would be fair to compare. Those are usually avoided in this sort of benchmarks.

As to a mcu-specific benchmark, given the diversity of the peripherals, it would be difficult, if not outright impossible, to make apple-to-apple comparisons.

It's not necessary to capture the real peripheral - often the *nature* of working with them is enough. For example, many relevant simulation could be done with timers, which are pretty ubiquitous.

But it's still difficult to do it in a relevant manner, and difficult to port, and difficult to interpret results.

Real challenges are difficult if not outright impossible... 😉

Jan