Bare Metal STM32 Programming and a Quadcopters Awakening

Ok, this drives me nuts

ARGH! Seriously? The STM32F103? Crazy (or should that be Craze) hobbyists using "blue pill" boards because they are cheap (and they are, like $3 on ebay) which use this bastard chip of the ST Cortex-M line and they say "gee, its a really simple circuit and since they sell for so cheap on ebay it should be a good idea to use this chip!" BZZZZZZT!

ST Micro makes much better CPUs that would be ideal for this application, they have things like on board DSP instructions in their floating point units, and can run at internal clock rates of 180 MHz with a megabyte of Flash and 384K of RAM, some of it very high performance (core coupled memory). These CPUs are no harder to put onto a PCB than the STM32F103 and they are so much more capable. And sure, they are $10 apiece instead of $1 apiece which is fine if you're making BILLIONS of these things, but a bespoke quadcopter?

Oh but its Open Source, cool, except I can't find the PCB files anywhere, if I could I could pull out that crap chip and put in a real CPU and have OSHPark make me a few. I did find the software repo : https://github.com/Crazepony ↗ and yeah, another budget quadcopter maker with a bunch of things they want to sell and an "open source" tag to try to get people to come and look. Fair enough, it made me look. It is sort of the 'freemium' hardware company model.

Sigh. I'd love something bigger than the Crazflie[1] which is like real open source (PCB and everything) and smaller than a DJI Phantom that I could play around with.

Hi, interesting article, but I would like to suggest you something. While it's OK to do bare metal just using the memory locations like you did:

``` *(uint32_t *)0x40021018 = 0x00000004;

``` after a few days, it will become tiresome to read and to remember all those addresses. I suggest you to use the header [0] that the ST provides for STM32F1, which is included in packages such as STMCubeF1 [1], STMCubeF0, etc.

For instance, instead of using the memory address directly, you could just do

``` RCC->APB2ENR |= RCC_APB2ENR_IOPAEN;

``` so it's easier to remember what is what. STMCubeF1 is a big package, but you won't be using the API/drivers ST provides (such as HAL and LL), just the header. As I understand, the STM32 community kind of rejects this API as "bloated".

I have some examples here if you would like to take a look:

https://github.com/dbolgheroni/arm-makefile/blob/master/drv/gpio.c#L29 ↗

Cheers,

[0] https://github.com/dbolgheroni/arm-makefile/blob/master/stm32cubef1/cmsis/include/stm32/stm32f103xb.h ↗ [1] https://www.st.com/en/embedded-software/stm32cubef1.html ↗

Looks like a nice write-up!

ST actually sells an evaluation board for learning about drone control; it has a BTLE module, four small FETs, sensors for pressure and a 9-axis IMU, a 1S battery charging circuit, and source code for some example firmware on Github. Search for 'STEVAL-FCU001V1'.

I've also seen a lot of cheap STM32-based FCU boards from the same places you'd get one of these 'blue pill' boards.

These are very useful chips to learn about, because they come in all shapes and sizes. Some focus on power efficiency, others on speed, others on connectivity or signal processing, and there aren't too many differences that you need to account for in your code.

Also, you can program and debug these using OpenOCD with a generic "ST-Link" module; they only cost a few bucks from cheap sources, or many of ST's evaluation boards have a built-in STLink probe which you can use. That lets you connect to the chip from GDB and step through your code like a normal C program, which is often a lifesaver.

I can't help but wonder whether quadcopters will be where governments finally legislate control over general computation. Having access to bare metal means nobody can stop inexpensive and socially-disruptive quadcopter applications. How many years before quadcopters join rats and pigeons as the scourge of urban life, always on the prowl for unguarded power outlets or perches on power lines?

Governments and/or corporations have control of the bottom layer of cell phones and TCP/IP networking. Not so for firmware and cryptography, though not for lack of trying.