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.

[henry.dick]

Posted on February 19, 2018 at 12:27

Another way to ask your question: is it possible to compile one C file, without any device header files, (user written) start-up file, and any non-standard library, with or without the use of uart, on a stm32 or generically any MCU?

While I have yet to try it but I think the answer is yes.

[AvaTar]

Posted on February 19, 2018 at 12:01

This approach was was really good in this case but frankly the LPC810 is not very complicated device (GPIO, UART, I2C, SPI, comparator, and simple clocking system).

And it is a real world example that the famous 'CubeMX' does not cover everything ...

Decisions about about MCU vendors and platforms for commercial projects are often made without consulting developers.

Thus, understanding how such a part works is much more valuable than mastering a point-and-click software.

I currently work with 3 different platforms from 2 different vendors, none of them is ST. And only one of them ARM Cortex.

[henry.dick]

Posted on February 19, 2018 at 12:18

'I don't see any use of non-standard libraries ........the user providing a custom putcher().'

You answered your own question. If by 'standard library' you meant code augmented by custom user-written pieces, any and all MCU software falls into that category. So you definitively can do that with stm32 chips.

The difference to a stm8 programmer going to stm32, in a way similar to that tutorial you referenced earlier, is that you have a few key decision points.

1. Do you want to live within cmsis? Going native is entirely possible but generally not advisable.

2. Do you want to live within some ecosystem aka libraries? Again, going native is entirely possible and sometimes advisable, depending you the librarire and your skills.

3. Do you want to live within an ide? Again, going native (command line) is entirely possible but in my view not advisable, depending on your preference, workflow, and financial resources.

...

As a result, for what you want to do, it can be as simple as simply compiling the benchmark on a desktop, without any customized code, and even without the actual hardware. On the flip side, you can also do it via thousands of lines of custom code, thousands of pages of user manual, and multiple gb of installation and thousands of dollars of expenditures......

There are so many, and often too many, choices when it comes to programming those chips. Having choices is often good but can be overwhelming or even frightening, depending on who you are.

[henry.dick]

Posted on February 19, 2018 at 13:34

''

I think the answer is yes.''

I can confirm it for you that the following program, with ST start-up file, ran flawlessly on a F100 board, both in simulation and in actual hardware.

the only change made to the stock start-up file is to get rid of the reference to SystemInit(), which we don't have here for obvious reasons.

so for your purposes, you can simply load up the benchmark files and watch dwt counts, or if you want, set up SysTick for that.

[henry.dick]

Posted on February 19, 2018 at 14:06

here you have it, for the dhrystone benchmark, on a F1:

I basically put in the dwt defs, stolen from stm32f1xx.h, into the code posted earlier. No device-specific header files, no custom-written start-up files, + just ''standard'' libraries. and the backend is gcc-arm.

it took about 11 million instructions to run through the dhrystone benchmark, on an actual chip. the same code should run on a (decent) simulators as well.

[waclawek.jan]

Posted on February 19, 2018 at 16:32

performance numbers - Scores for the Whetstone, Dhrystone, Coremark and stdcbench benchmarks to compare with the 8-bit devices.

These benchmarks

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

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

for practical purposes, unless you want to sell these chips.

I understand that you want to play, but, please, don't contribute to the noise.

It would be a worthy effort to try to create a real microcontroller-centric benchmark, i.e. not a general-purpose number-crunching data-moving one; and that would really indicate the merits of 32-bitters vs. 8-bitters; but it's very hard to do it universal enough, and it would be even hard to properly interpret the results.

Another worthy effort would be to write programs finding points of overload of the 32-bitters, e.g. showing when does bus contention show up on the performance. Again, not trivial.

JW

[Philipp Krause]

Posted on February 19, 2018 at 16:33

I've made a bit of progress: Started with the SPL-using template at

https://github.com/szczys/stm32f0-discovery-basic-template

, removed all the SPL stuff, added the stubs for newlib to make printf() work, then realized Dhrystone won't work on the STM32F051R8 - it uses an array of 2500 int, which on the STM32 is 10 KB (would be 5 KB on the STM8), while the STM32F051R8 has only 8KB.

So my next tasks are:

2) Get rid of the non-free startup code from the template / ST.

1) Make some other, less memory-hungry benchmark work - probably stdcbench.

3) Make Dhrystone work on the STM32F302, which as more RAM.

Philipp

[Philipp Krause]

Posted on February 19, 2018 at 16:45

I do not see how the linked thread justifies the characterization of these benchmarks as 'completey useless'.

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). The first three have known emphasis on certain aspects of the implementation in their scores, something that stdcbench tries to avoid. But I don't see anything that makes them 'completey useless'.

Philipp

[waclawek.jan]

Posted on February 19, 2018 at 17:05

It's the target which makes them completely useless.

Microcontrollers are here to *control*, not to crunch numbers or move data around. Those benchmarks are intended for general purpose computing, not for mcus. In mcus, the usual tasks are different from the computers: programs are way more branchy; data often tend to be narrow (bits, bytes, rather than words); number of peripherals is an order of magnitude higher and they are varying in behaviour (and requiring varying approach in almost every case), there are much tighter timing requirements in  both in latency and jitter (an additional difference is in the power consumption profile, but there are relatively relevant benchmarks for that). In the 32-bit 'microcontrollers' this difference is even much more pronounced, as the computing 'core' can benefit from the tricks developed for general-purpose computing; but when it comes to with real world, and running programs with real peripherals, users who migrated from 8-bitters in the promise of increased performance underlined with the results of benchmarks are invariably disappointed.

So, using these benchmarks -  and especially in comparison with 8-bitters - has similar value as using results from car racing in evaluating merits of standard cars.

JW

[Andrew Neil]

Posted on February 19, 2018 at 17:07

waclawek.jan wrote:

It would be a worthy effort to try to create a real microcontroller-centric benchmark,

Isn't that the aim of EEMBC ?

https://www.eembc.org/

 EEMBC, an industry alliance, develops benchmarks to help system designers select the optimal processors and understand the performance and energy characteristics of their systems. EEMBC has benchmark suites targeting cloud and big data, mobile devices (for phones and tablets), networking, ultra-low power microcontrollers, the Internet of Things (IoT), digital media, automotive, and other application areas. EEMBC also has benchmarks for general-purpose performance analysis including CoreMark, MultiBench (multicore), and FPMark (floating-point).

The EEMBC benchmarks reflect real-world applications focusing on processor and microcontroller benchmarks as well as benchmarks targeting IoT, automotive surround view and image recognition, data centers, ultra-low power microcontrollers, and smartphones/tablets and browsers (including Android platforms). As an industry alliance, EEMBC members participate in the definition and development of all of our industry-standard benchmarks. EEMBC also makes its benchmarks available to corporate and academic licensees. The EEMBC Technology Center (ETC) offers an independent testing service to save you significant amounts of time porting and executing any of the EEMBC benchmarks.

https://www.eembc.org/about/index.php