STM32F103 any good?

[Muxr]

I've done some AVR development in the past. My background is software engineering so I don't mind learning a new language or environment.

But basically I've been shopping around for an MCU to migrate to after using 8Bit AVRs. I was mainly looking for cheap MCUs in case I decide I want to mass produce one of my projects, so the price is really important.

I was shocked with how cheap these (STM32) F103s are. For instance one of my projects is a clock and I have a need for an RTC module but this STM32 comes with a built in RTC. It's actually kind of mind boggling how much more advanced and how many more features F103 packs for the same price as an AVR Atmega328.

I mean you get: 75Mhz, 32Bit arch, 64Kb Flash, 20Kb SRAM, 2x12Bit ADC, bunch of interfaces, USB2.0, 7-channel DMA

I ordered a few of these $4 boards to play with: http://www.ebay.com/itm/311156408508?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

There is an open source Arduino toolchain: https://github.com/rogerclarkmelbourne/Arduino_STM32  It's pretty experimental though.

So I guess the question I have is, what's the catch? Anyone have experience with STM32 Cortex M3 F10x controllers, are they any good? And where should I begin in terms of software tools to program these guys? (preferably OS X / Linux toolchains).

[HackedFridgeMagnet]

It's a great step forward to get out of the Arduino ide.
I use eclipse with the cdt plugin and gcc and openocd(i think that is its name) for the debugger.

There is a fair bit of effort to set it up if you haven't done it before.
But there is plenty of support around and you wont look back.

the best way to start coming from arduino is probably the nucleo boards and some intro (limited) ide that should come with a board.

[chickenHeadKnob]

The stm32f103 is one of the older cortex m3 processors and for historical reasons unknown to me became very popular in china some years ago. That means you can find many ebay offerings at well below digi-key pricing so they are great value for the money. If you want cortex m4F (hardware floating point) some members of the stm32f3xx can be found cheap from north American disti's, but not as cheap as the 103. The newer stm chips have better (and more) timers and other peripherals.

[Jeroen3]

The RTC in the F103 is only a 32 bit counter and does not provide calendar features. And usually the inernal 32Khz oscillator does not run on Vbat, something to be aware of. (I'm not sure in this chip)
The F103 can only run 36 MHz from internal oscillator. For 72 MHz you'd need an external source. (You'd need it USB anyways)

[neslekkim]

Look at this thread: https://www.eevblog.com/forum/microcontrollers/stm32-ghetto-style/
and all the spinoff threads..

[andersm]

The I2C peripheral is badly designed, otherwise it's a pretty straightforward chip.

[Psi]

Yep f103 is good, be prepared to learn a standard peripheral library as opposed to fiddling with the raw registers as you do on AVR.
Its much more feature advanced so you really need a peripheral library or it takes ages to get stuff working.

Also the AVR registers are as dream to code, everything is layed out in a way that makes sense. Stm32 not so much, but with the library you don't need to go  down to that level anyway.

Be aware there are many things in stm32 you need to enable that were on by default in AVR. Clocks for various parts of the chip and stuff

[muvideo]

The RTC in the F103 is only a 32 bit counter and does not provide calendar features. And usually the inernal 32Khz oscillator does not run on Vbat, something to be aware of. (I'm not sure in this chip)
The F103 can only run 36 MHz from internal oscillator. For 72 MHz you'd need an external source. (You'd need it USB anyways)

In the F103 the RTC runs off Vbat, internal oscillator can be used to clock the chip up to 64MHz.

[Jeroen3]

In the F103 the RTC runs off Vbat, internal oscillator can be used to clock the chip up to 64MHz.

Yes. And that's where you need to read carefully. There are multiple series sharing the documentation and number STM32F1xxxx. Very ambiguous.
Connectivity line devices can only go up to 36 MHz and Low-, medium-, high- and XL-density series can go up to 64 MHz from hsi.

[tszaboo]

Yes the F103 is one of my standard components to use. It is good, well designed. I think the only time when it was a letdown, when we realized that the USB and the CAN cannot work concurrently.
But you need to be aware that only the smaller F103s are the ones I can recommend. If you need more than the 20K SRAM and 128K flash, there are much better choices even in the F300 and F400 series.

[poorchava]

Yes the F103 is one of my standard components to use

Ditto. I tend to standarize on STM32F030F4 for small stuff, STM32F103 for medium and STM32F407 when in need of serious processing power.

As for IDE, I recommend CoIDE from CooCox. For me it is practically problem-free, and all the external setup you need to do is to install the arm-gcc and provide the path to it in IDE. It's totally free (no limitations whatsoever) and in general supports most of ST's Cortex uCs

[daybyter]

This board does not support external RAM, right? (Ordered one, too.)

[Brutte]

These F1/F2/L1 chips from STM have very similar peripherals.
The F103 is a faster and feature-rich version of F102, although F103 is cheaper in retail, it may not be in volume.

For development, I'd suggest picking a 512kB flash/64kB SRAM in LQFP100 or higher, for release you can pick anything that barely matches the requirements (down to 16kB QFN36). Mind these 72MHz chips are optimized for speed so jumping from coremark=11 for AVR8 to coremark=108 of F103 may not be what you expect (GCC).

Now the differences..
These chips use 3,3V nominal voltage, some IOs can operate up to Vcc+4V, around 8V max in open drain mode (I think they refer those as "5V tolerant"). This "feature" means that internally these 8V IOs do not have the upper clamping diodes. So, if you apply 12V through 4k7 resistor to an IO of AVR8 then nothing spectacular happens, IO is driven up to Vcc+0,7V and upper clamping diode limits the voltage.
The problem is that same experiment should fry the 8V IO on STM32.
Now, not all STM32 IOs are 8V compatible. Some are just regular IOs with both clamping diodes. Here injecting current won't damage the chip "if you limit the current to the one specified in maximal ratings of course " but can ruin ADC readings of the uC.

As of the toolchains, if you pick the IDE with wizarding (like uVision or CooIDE) then the setup is similar to the one with AVRStudio. Just name the project and:

Code: [Select]

int main void(){..... return 0;}However, if you decide to pick a bare metal route, then it is same as with bare metal AVR8 and you have to provide your own linker, startup code, IRQs etc. If you never wrote startup code and/or linker scirpt for AVR8 then most likely writing one for STM32 is going to discourage you (even configuring a clock tree can ruin your day).

[poorchava]

Another thing: as with almost every ARM uC you need to remember to enable the clock to a peripheral before you can actually use it.

[Muxr]

Thanks for the replies guys, awesome info!

Another thing: as with almost every ARM uC you need to remember to enable the clock to a peripheral before you can actually use it.

Yes I read that, it seems to be ARM's way of making you think of power utilization I believe.

Found their peripheral library as well for F103, STs website is kind of a mess. Found this index of F103 stuff if anyone else happens to be looking for it: http://stm32.eeelec.com/html/STM32F1%20resources.htm  3.5.0 seems to be the latest version of the standard peripheral library.

Browsed around the source, seems pretty straight forward.

[poorchava]

It's not how ARM does it. It's how ST, NXP,  Atmel and such do it. ARM only provides the core,  all peripherals are of particular vendor's design.

[Muxr]

It's not how ARM does it. It's how ST, NXP,  Atmel and such do it. ARM only provides the core,  all peripherals are of particular vendor's design.

I stand corrected. Although they all seem to be doing things in a similar fashion, perhaps something mandated by ARM via CMSIS?

[poorchava]

I don't know. If I had to guess,  my first bet would be on the fact,  that those chips are loaded with many modules and features,  each of which draws some current and not all of them can be used at the same time, so if they were all turned on at all times,  the power consumption figure would be much higher. Since nowadays there is almost always some pressure on reducing the power consumption of a product, this is a really useful feature. Lower power is not only longer battery life but also smaller regulators,  less filtering capacitance lower transient currents when switching and so on.

[langwadt]

I don't know. If I had to guess,  my first bet would be on the fact,  that those chips are loaded with many modules and features,  each of which draws some current and not all of them can be used at the same time, so if they were all turned on at all times,  the power consumption figure would be much higher. Since nowadays there is almost always some pressure on reducing the power consumption of a product, this is a really useful feature. Lower power is not only longer battery life but also smaller regulators,  less filtering capacitance lower transient currents when switching and so on.

it also mean a single part can cover a lot more applications. Compared to the size of ram and flash the peripherals are tiny so it makes sense to add as many as you can think of and just turn them on and off as needed

[Jeroen3]

They typically put the bare die full of stuff they disable later one. Such as extra ram, flash, timers, or maybe even entire Cortex M0's. Such as the lpc43 en 18.
Because if you compare the LPC18 and LPC43 addresses, they are remarkably similar. Just otp't the configuration differently. This is nice, because you don't need to bake many different chips. Just a few, and later on you decide what configuration you'll give them.

Obviously, enabling everything will be problematic with power consumption, and thus temperature specs.

I'm currently working on an small 3xAAA powered proprietary remote control. The STM32F1 XL series (with the 1 MB flash) is capable of doing that.
But it seems just a little bit underpowered for doing a 320x240 spi-lcd, the fancy way. Sure it can draw lines and stuff (using STemwin) but it's a bit slow-ish. I was unable to get the fancy features of emwin working. Maybe because a copy of the LCD does not fit in ram. I was unaware of the "feature" that USB and CAN use the same RAM block. It was nice if one of them was capable of being remapped. This is one of things you discover if you inherit a project.
The power consumption of the STM, with life-support, in this application is about 20mA (3.3V). When I unplug the LCD, obviously.

[Muxr]

Yeah, I was reading the other Ghetto STM32 thread while mostly about the smaller F0s Dannyf actually tested F103 going beyond the Flash 64kb boundary specified in the spec sheet.

Apparently they can have usable 128kb. https://www.eevblog.com/forum/microcontrollers/stm32-ghetto-style/msg516439/#msg516439

[Jeroen3]

On the St forums, Clive1 actually confirmed this for 407 parts.

The ones above the 512KB threshold (>= 0x08080000) have not been tested. The 405/407 parts typically have the same 1MB dies. There is only a single bank of flash.

Just remember that although the memory is available, there are no guaranteed specifications on those parts of flash.

[Muxr]

On the St forums, Clive1 actually confirmed this for 407 parts.

The ones above the 512KB threshold (>= 0x08080000) have not been tested. The 405/407 parts typically have the same 1MB dies. There is only a single bank of flash.

Just remember that although the memory is available, there are no guaranteed specifications on those parts of flash.

Yeah no telling if extra Flash is faulty or a higher grade part bined for lower spec demand.

[poorchava]

Another thing that is different between ARM uCs and AVR/PIC/MCP430. A lot of time-critical registers have different address for disabling and enabling. For example for a gpio port in STM you have a BSRR (bit set reset register) and BRR (bit reset register). When you write 1 to BSRR on position 0 you set gpio0 high, is you write 1 into BRR on position zero, you set gpio0 to low. There is obviously also traditional way via ODR (output data register) where you write 1 or 0 and gpio assumes this logic state.

Another useful thing is bit-banding, which is a mechanism available in CM3 and CM4. It mans that particular registers have an alias somewhere in the memory for every bit in that register which allows truly atomic modification of registers (no read-modify-write problems). Read up on bit-banding.

[Muxr]

That's pretty slick, this article explains it pretty well: http://spin.atomicobject.com/2013/02/08/bit-banding/