Getting started with STM32 bare metal, but with standard library

[Philipp Krause]

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.

[AvaTar]

Posted on February 19, 2018 at 18:52

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.

I wrote a 'benchmark test' two decades ago that teased out 0.98 MIPS from a 4MHz Z80 (4 clock cycles per instruction).

That test was totally meaningless, except for the number of instructions per time unit ...

Context is important...

Real challenges are difficult if not outright impossible... ;)

...

Yet an engineer needs to live without benchmarks were they would be most useful.

Having the same core in many MCUs, you often need to pick one solely by means of their peripherals.

[Philipp Krause]

Posted on February 19, 2018 at 19:44

While the criticism of using 32-bit where narrower types would be sufficient is valid for Coremark, it does not hold for Dhrystone and stdcbench.

Philipp

[Philipp Krause]

Posted on February 19, 2018 at 19:46

I'd give them the benefit of doubt and assume that by 'IoT' they mean algorithms typically used in TCP/IP stacks designed for use on microcontrollers.

Philipp

[Philipp Krause]

Posted on February 19, 2018 at 19:52

Comparing just the core is fine for me. After all I just want some numbers from alternatives to the STM8. When these numbers are representative for a wider range of such alternatives, that's even better.

Philipp

P.S.: I didn't use cmsis and now have eliminated all use of SP, headers or startup code from ST or other third parties. Everything is now code written by me / generated by GCC or from newlib-nano (a popular implementation of the standard library that also works on STM32).

[henry.dick]

Posted on February 19, 2018 at 20:36

so you are not comparing stm8 to stm32. instead, you are comparing stm8 to cortex-m0/1/3/4....

[AvaTar]

Posted on February 20, 2018 at 08:09

Assuming you pursuing a commercial project, I see no point in changing from STM8 to STM32 unless you have severe performance issues.

The STM8 is quite performant, relatively speaking, and well supported by ST.

One of my former companies assigned a ARM-Cortex agnostic engineer to an evaluation project, comparing PIC18 with a Cortex M0. He ported the companies 8-bit specific bit-banging code, and achieved a meagre 15...20% increase of performance. Well, and Microchip sponsored a dinner annually ...

I didn't use cmsis and now have eliminated all use of SP, headers or startup code from ST or other third parties.

IMHO at least the startup code (possibly with modifications) and the stm32fxxx.h device header are fine to use nevertheless.

Using established names and constants significantly increases readability, compared to magic-number bitshifts and operations.

[Philipp Krause]

Posted on February 20, 2018 at 11:13

The startup code at

https://github.com/szczys/stm32f0-discovery-basic-template/blob/master/Device/startup_stm32f0xx.s

  is non-free.

Philipp

[henry.dick]

Posted on February 20, 2018 at 13:07

Looks to be some kind of academic exercise.

I would agree that a non-cmsis, non-standard header driven approach has no practical appeal to a practioners.

[waclawek.jan]

Posted on February 20, 2018 at 13:22

I repeat my question from the other thread: what makes you mark device headers and startup code from  [Cube]\Drivers\CMSIS\Device\ST\STM32[xxxx]\ as non-free?

JW

[AvaTar]

Posted on February 20, 2018 at 14:03

Because this mostly amounts to re-inventing the wheel.

And except for the core peripherals (NVIC, Systick, etc.), there is no code involved - but you can even discard that if you wish.