Skip to main content
Philipp Krause
Senior II
February 18, 2018
Question

Getting started with STM32 bare metal, but with standard library

  • February 18, 2018
  • 11 replies
  • 13445 views
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.
This topic has been closed for replies.

11 replies

Bogdan Golab
Lead
February 18, 2018
Posted on February 18, 2018 at 21:13

https://www.cs.indiana.edu/~geobrown/book.pdf

 
Andrew Neil
Super User
February 18, 2018
Posted on February 18, 2018 at 22:42

For basic getting-started tips, see:

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

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
waclawek.jan
Super User
February 18, 2018
Posted on February 18, 2018 at 22:45

Is there some simple 'Hello, World!'-style tutorial, [...] I want to avoid the use of complex or non-free stuff (IDE, Cube, libraries such as SPL or HAL).

Then no.

Welcome to the wonderful 32-bit world!

Jan Waclawek

PS. My take on this at

http://www.efton.sk/STM32/

  but only a few randomly chosen boards and tasks. Some rudimentary example in the

http://www.st.com/en/embedded-software/stm32snippetsf0.html

.

I honestly want you to learn to hate the 32-bitters very quickly as we need you desperately for SDCC.

Philipp Krause
Senior II
February 19, 2018
Posted on February 19, 2018 at 09:26

Don't worry. For now I just want to get a few performance numbers - Scores for the Whetstone, Dhrystone, Coremark and stdcbench benchmarks to compare with the 8-bit devices.

Maybe, in the long term, if I find the time to do so, knowing the STM32 might be helpful in porting the RTOS RIOT from the STM32 to the STM8.

Philipp

henry.dick
Associate II
February 18, 2018
Posted on February 18, 2018 at 23:03

'Basically I'm looking for a tutorial like the

/external-link.jspa?url=http%3A%2F%2Fwww.colecovision.eu%2Fstm8%2FSTM8S-DISCOVERY%2520Serial.shtml

, but for an STM'

that tutorial relies on non-standard libraries, to borrow your terminology.

'P.S.: By 'with standard library' I mean that functions from the standard library'

basically, you have free tools, you have cmd tools, ..... the moment it comes to access onboard peripherals, none of them exist anymore.

so if you have to code with 'standard libraries' exclusively, stay on your PC.

Philipp Krause
Senior II
February 19, 2018
Posted on February 19, 2018 at 09:07

I don't see any use of non-standard libraries in the STM8 tutorial.

It uses stdint.h, which is a mandatory standard library header for freestanding implementation of C, and the type uint8_t,the availability of which is implementation-defined, but required for any implementation that has an 8-bit type at all. It also uses stdio.h and printf(). While these are not mandatory for freestanding implementations, they are still useful. The tutorial uses SDCC, and for the printf() that comes with SDCC, the way to specify where the printf() output goes is by the user providing a custom putcher().

Philipp

henry.dick
Associate II
February 19, 2018
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.

Bogdan Golab
Lead
February 19, 2018
Posted on February 19, 2018 at 08:15

When I wanted to switch to ARM (a few years ago) I was in the same situation. Started with TI ARM as they had nice tutorials at that time. Moved to STM32 because they had more stable IDE (I mean Keil because I used to use TI IDE for TI ARM which was awful for me).

I think I should have started with reading reference guides and programming at the register level. Especially if you are experienced in other MCUs.

When you start with CubeMX/HAL/LL you also need to study RM because the abstraction provided by the HAL/LL is not clear (at least for me).

I think that the mentioned earlier book is good to see the difference between the 8bit MCU and ARMs:

/external-link.jspa?url=https%3A%2F%2Fwww.cs.indiana.edu%2F%7Egeobrown%2Fbook.pdf

But I am only hobbyist, not professional.

Harry May
Associate
February 19, 2018
Posted on February 19, 2018 at 11:04

I came to STM32 last year whenI started a professional product for a machine controller.

First of all I got evaluation boards, like you did, and tested the various libraries and rtos.

From my experience the HAL generates more problems than it solves due to its

unnecessary complexity.

My library of choice it the STM32 standard library. It allows me to initialize all hardware components perfectly.

I also use Cube MX, but only to get hints about hardware usage, not to generate software.

I use the System Workbench for STM32 which works very reliably and never made any problem during development of my controller. System Workbench generates a simple and basic skeleton for the software which helps a lot to get started.

For a Hello World style program you can do a LED blinker for your eval boards which is done with a few lines of code.

Good Luck

Harry

Bogdan Golab
Lead
February 19, 2018
Posted on February 19, 2018 at 11:46

Last year I needed simple ARM for simple task and discovered LPC810 (an NXP product). So started from scratch with the new vendor. Of course it's also an ARM so I started from register level programming (and errata documents). 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).

To make my comment valuable: this forum is a great source of knowledge and help. There are some very skilled engineers (see the top guys on the rank list) who are willing to help.

AvaTar
Senior III
February 19, 2018
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
Associate II
February 19, 2018
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.

henry.dick
Associate II
February 19, 2018
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.

0690X00000609gkQAA.png

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
Associate II
February 19, 2018
Posted on February 19, 2018 at 14:06

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

0690X00000609jEQAQ.png

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
Super User
February 19, 2018
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
Senior II
February 19, 2018
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
Super User
February 19, 2018
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

Philipp Krause
Senior II
February 19, 2018
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

henry.dick
Associate II
February 19, 2018
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
Senior II
February 19, 2018
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).