My Experience With STM32 Microcontrollers
3e71e26a-119c-405f-97e8-6dde5a06df3611 Apr 2010
For some reason, I never talk much about my embedded development projects, which is odd considering the large amount of time that I spend on them. I started learning embedded development stuff back in my sophomore year of high school with the AVR line of microcontrollers.
In my junior-senior year (it’s a long story) I designed and built an embedded device to control NXT robots for the FTC robotics competition. I still have the original breadboarded prototype lying around. But this post isn’t about that, I was just providing some background information. This year, IEEE@WashU has decided to build a light-up dancefloor, similar to the old one, but split into a set of modular 2-by-2-foot tiles for easier maintainability, upgradeability, and not-exploding-people-ability. Also it will have pressure sensing. We were originally planning to run the floor with an ATMega at the center coordinating everything. Unfortunately, our first try at the inter-module communications was prone to noise issues. After much deliberation, we chose a scheme using ordinary UART signalling carried over LVDS between modules, with direct connections between neighboring modules. Unfortunately, that meant we needed a chip with 4 high-speed UARTs. We ended up settling on the STM32 line of ARM chips, specifically the STM32F105. It has 5 UARTs, of which all are capable of 2.25 Mbaud. Also it has on-board ADC functionality, and runs nearly 4x as fast as an AVR at top speed. So it’s a pretty nice chip overall. The first big problem was packaging. Most AVR chips come in a DIP package, which is nice and friendly for hand-soldering. The STM32F105, on the other hand, comes in a QFP-64 package, which is quite a bit less friendly. For prototyping, I soldered one to a breakout board by hand. It worked, sporadically, for about half a week, but I’m pretty sure my poor soldering is to blame for the failure, either due to bad electrical connections or thermal damage. But from what I was able to infer about the operation of a non-damaged chip, the STM32 line should be pretty fun to work with.
-
Like the AVR, it has extremely minimal requirements for external components. I ran it with power, JTAG, two blinky LEDs, and nothing else connected.
-
The STM32F10x Standard Peripheral Library contains a lot of useful functionality already implemented, although the function naming conventions are pretty ugly.
-
On-chip debugging is always worth it. AVR chips can do this too, but I never really bothered using it. Now that I’ve tried it on the STM32, I don’t think I could bear blinky-LED debugging any more.
-
Lots of fun features:
- 4x higher clock speed than AVR.
- Two 16-channel ADCs
- Two 12-bit DACs
- Unique 96-bit device signature
Aside from the soldering issue, I believe that the STM32 line of microcontrollers is exceptionally hobbyist friendly, and should be pretty fun to work with once I get some non-damaged chips hooked up.
