STM32, ghetto style

[dannyf]

Every once in a while, we will have discussions on what a "minimalist mcu system" looks like.

There are plenty of us who have done truly minimalist 8-bit systems. So I thought I would post a few pictures of a "minimalist" STM32 system.

The mcu in question is a STM32F030F4 - a tssop20 16k CM0 chip from STM - < 40 cents a piece, if you can get one. I got mine from China for ~60 cents.

Here are two pictures of the STM32 chip flipping an led.

[dannyf]

The only part on the board, aside from the led, is the STM32 mcu. Nothing else.

No capacitors, no crystal, nothing.

The programmer? It is a knock-off st-link on a stick (like a usb thumb drive). There are everywhere on the bay for $5 dollars.

[dannyf]

Wiring?

Four wires from the programmer to the chip: Vcc (3.3v), GND, SWDCLK and SWDIO.

You will see one extra wire - for BOOT0. That's only needed because the board has no connection for BOOT0, and we also want to make a even more ghetto version of this,

[dannyf]

Next?

We will try to even get rid of the knock-off ST-link. Instead, we are going to utilize the bootloader already on the chip and do a zero cost programming exercise (assuming  you have a usb-ttl adapter).

stay tuned.

[dannyf]

Development environment:

tried successfully on CoIDE and Keil.

CoIDE: I used an earlier version that has no direct support for the ST chip. So I compiled it to a generic CM0 chip. With the st standard peripheral libraries, the code size is 1.1k - 1.7k, depending on compiler settings;

Keil: with microlib and cross-modulation optimization turned on, I got 1.0k - 1.6k. However, gcc is much faster in compilation time.

[westfw]

Thanks for the example / proof-of-concept.

the code to flip the led is fairly generic

At the level of the code you showed, it better be!  The question is "how ridiculous" is the chip_init() part, and the library functions (if any) under your PIN_xxx macros? (those are your macros (that you've mentioned in other threads), rather than STLib or CMSIS functions, right?)   At 1.1k, your binary is very nearly exactly the same size as the Arduino BLINK example (for ATmega328) that does the same thing.  And a lot of people criticize the arduino libraries for being bloated.
(Now, frankly, 1K for init and vectors and stuff seems OK to me, on a $0.60 16k chip...)

[Psi]

Development environment:

tried successfully on CoIDE and Keil.

CoIDE: I used an earlier version that has no direct support for the ST chip. So I compiled it to a generic CM0 chip. With the st standard peripheral libraries, the code size is 1.1k - 1.7k, depending on compiler settings;

Keil: with microlib and cross-modulation optimization turned on, I got 1.0k - 1.6k. However, gcc is much faster in compilation time.

EmBlocks is another one that works well for stm32

[dannyf]

In case you are interested, current consumption @ 8Mhz HSI, without the led, is just shy of 10ma. Slightly worse than a typical 8-bit mcu at comparable frequency.

[andyturk]

Keil: with microlib and cross-modulation optimization turned on, I got 1.0k - 1.6k. However, gcc is much faster in compilation time.

Even 1k seems like a lot to blink an LED. Of course, maybe 1k is the smallest size that the tool will report.

[mikerj]

Keil: with microlib and cross-modulation optimization turned on, I got 1.0k - 1.6k. However, gcc is much faster in compilation time.

Even 1k seems like a lot to blink an LED. Of course, maybe 1k is the smallest size that the tool will report.

A fair chunk of that will be interrupt vectors (forty odd 32 bit vectors), the C runtime and initialization code.  It seems like a lot compared to e.g. a PIC, but with great power comes great(er) overheads.

[dannyf]

St-link knock-off: just search for st-link v2 on the bay and the one I got has metal casing. Should be around $5 shipping included. They are of fairly high quality, with laser itched letters on them and a bi-color led indicator (red + blue).

Soldering tssop20 parts: very easy. I applied some flux on the board and then lined the chip. Applied a little bit of solder on one color and check the part again for alignment - this is the more important part. After that, just put a big drop of solder on the tip and drag it across the pins. Wipe off excessive amount and check for short. A 30 second job if you do it right.

Code size varies on settings / compilers used. Here is one example: 1.2k for the overhead (start-up, clock mgmt, and SystemCoreClockUpdate() - itself a 200b monster). PIN_OUT() is 200b; Others are 40 bytes or so.

On the most aggressive setting, you can shrink the overhead to about 500 bytes.

[dannyf]

One more.

ST pheripheral library: I used an ancient one, version 1.0.1, . The latest one is 1.3.1. I have not tested any thing under 1.3.1. However, it should work.

[SirNick]

No decoupling cap?  No series resistors?  For shaaaame.  Think of the children...

[miguelvp]

PSoC 4200 with 28 pin SSOP is a bit more expensive at $1 for the chip alone but with a good regulated external supply it can run as is.

Regulated External Supply

In this mode, the PSoC 4200 is powered by an external power
supply that must be within the range of 1.71 to 1.89 V (1.8 ±5%);
note that this range needs to include power supply ripple too. In
this mode, VCCD, VDDA, and VDDD pins are all shorted
together and bypassed. The internal regulator is disabled in
firmware.

But not only you get a 32bit MCU, but programmable digital and analog blocks, ADC, DAC, capacitive sensing 32K of flash ram 4K rom, well tons more.

But if you use 3 decoupling caps then you can power form unregulated 1.8 to 5.5V. So a coin battery will do.
Oh, and free shipping while they still have the $1 offer, (of course it does sound like it's been subsidized or something)

[djacobow]

This is preposterous! The raw power of the 32b ARM cannot be harnessed with a mere soldering iron, a TSSOP adapter board, and a few wires!

 

[dannyf]

The programmer... are everywhere on the bay for $5 dollars.

For those of us who are too cheap to spare $5 (I am one of them), there is an approach that requires zero / no (incremental) cost to program those STM32 chips: your discovery boards. They have a debugger on board and can be made as programmer for those chips.

Note: you have to provide external power, however.

[dannyf]

Another cheapie, in keeping with the ghetto style of this thread, is to use a serial port (tx/rx pins) and to activate the bootloader in the system memory of those chips.

With this approach, all you need are two wires (tx/rx) + Vcc/Gnd (and BOOT0 for this particular board), and you can program the chip.

Practically, you will be hard pressed to find a modern computer with a serial port so the practical solution is to use a usb/ttl board (232 or cp210x or pl2303) to simulate the serial board.

Here is my implementation (the pictures show the code running - thus the BOOT0 line is floating).

Four wires to the STM32 (Vcc, Gnd, TX, RX), BOOT0 floating.

In the programming mode, BOOT0 is tied to nRST - you will need to read the datasheet to understand why,

[dannyf]

The above approach requires a serial port (either directly or via a usb/ttl converter), and a piece of software (flash loader demonstrator, freely available from ST).

There is also an approach that does not require the flash loader demonstrator - hyperterminal is all you need.

However, you will need to adapt and program a piece of firmware (available freely from ST) and burn it to your chip (either with a programmer or via the flash loader demonstrator). After the initial programming, all you need is a serial port + hyperterminal.

[dannyf]

Hopefully, this thread will show people how easy it is to start using those arm chips, from a programming perspective.

Hope it helps.

[Whales]

I'm loving this.  I have to try them out

[dannyf]

Each approach has its own pros / cons:

1) st-link: it provides the most comprehensive view of the registers, and the ability to halt the processor. However, in cases of large data flow, it is not efficient;

2) serial port: it allows an efficient way to observe large number of data - you can simply program your code to utilize the uartx module to send data over the tx/rx lines. ie. the programming and user application are one. However, you have no way of halting the mcu and if you want to output a new variable, you have to reprogram the chip or program the flexibility to output variables on the fly - via the hyperterminal.

I prefer the st-link approach myself.

[dannyf]

BTW, for those of you interested, the above approaches apply to STM8S/L/A chips too - they are ST's 8-bit chips.

The STM8 chips are incredibly inexpensive - I have a few of them on a boat from China at 30 cents apiece (STM8S003F). Very difficult to beat at those price points.

Enjoy.

[dannyf]

I'm loving this.

I am glad that you find it helpful.

I have always heard people talking about how difficult and expensive it is to acquire skills and equipment to get started on those ARM chips. Hopefully this thread will demonstrate how easy and low-cost it is to get it going, at least for those STM chips.

At this low of a price point, it is a shame that more people aren't trying out those chips.

[westfw]

it is a shame that more people aren't trying out those chips.

Where did you say you could purchase them from, again?  :-)

(This history of hobbyist microcontrollers is that they had to be pretty cheap, and they had to be "available" to hobbyists.  Microchip owes a lot of thanks to Parallax for their dominance in the hobbyist market. (and in the other direction, Atmel's early flash microcontrollers were nearly unobtainable.)
This assumes that the manufacturer considers hobbyist involvement to be a good thing; but I observe that in the absence of the rare "evaluation mission", a working engineer is similar to a hobbyist...
(and I'm constantly amazed at how many "eval boards" are nearly indistinguishable from, say, Arduino in terms of capabilities, but languished largely unnoticed for some reason that is really hard to put your finger on.  How are those STM "Nucleo" boards doing, anyway?))

[dannyf]

Digging through my boxes and here we go, an open frame stlink/v2 knock off + a stm8s003f board.

Again a picture of it blinking the green led. The st-link is in the background and the stm8s003f board in the foreground.

Code?

The code is identical to the one posted earlier (plus some timer interrupt related stuff to calibrate the software delay routines used), also driven by the st peripheral library.

Total code size: 3.2k. Of which, about 1K is totally unrelated to blinky. 0.5K is truly blinky related and the rest is overhead.