Which Brain to Use?

With the widespread availability of devices today, you would be hard-pressed to find a microcontroller that didn’t meet the needs of simple hardware designs. A system such as this could easily be driven by an 8-bit core, like the ever popular Atmel AVR series devices, which are now driving millions of Arduinos worldwide.

As a side note, my embedded hardware design background began in the early 2000’s, using Motorola (now Freescale) 68HC11 devices. For anyone that doesn’t remember this series, it was extremely popular in the 80’s and early 90’s. The particular variant I was working with used EEPROM for the code space, and was UV-erasable. So, any changes you’d make in the firmware would require placing the devices under a UV lamp for a period of time to erase them before reprogramming. Often times they didn’t erase properly, and you’d end up with flipped bits in the code. The emulators for those chips were the size of a mini PC tower, with a complex array of parallel wiring and socket adapters. The firmware engineer at the time had also just transitioned to using a C compiler, instead of writing the code in Assembly Language. Why we were still doing all of this in 2001 was mind-boggling.

Motorola 68HC11

At that point I decided that for new designs it was time to transition to something more modern, with flash memory for starters. We ended up settling on the Atmel AVR series. It was a world of difference, being able to use C development IDEs, real-time debugging via JTAG, and the ability to erase and flash firmware in seconds. Over the course of my career there, I probably designed the ATMEGA128 into over 20 projects.



It wasn’t until a few years ago that I started venturing outside of the AVR realm. The demands of the projects I was working on were really too much for the Atmel chips. I started needing things like floating-point math, higher speed clocks, USB interfaces, Ethernet, etc. On several projects I went with a TI MSP430 device, which is quasi 16-bit. The ecosystem for the MSP430 series is very well established, and there are a plethora of development kits available. The TI CCS IDE is also pretty good if you don’t mind Eclipse. It can be slow and temperamental, but once you get a stable environment set up it tends to be rock solid.

I’ve also worked with Cypress PSoC3 devices, which have an 8051 core (8-bit) and a host of analog attachments on the chip. I was surprised with these at how easy the development environment was to use. Unfortunately my experience with these is in recovering someone else’s spaghetti code. I have messed around with the PSoC5 series (Cortex-M3) on their development kits, and my first impressions were generally good.

In the Wireless Sensor Module, I would be needing something with the following requirements:

  • Low-cost
  • Low-power
  • USB, SPI and I2C interfaces
  • RTC capability
  • Small package

I’ve been working a lot with the STM32 series devices, so I decided I would go with something in that line. This particular application doesn’t require much in the way of performance, and I’ve been wanting to work with the Cortex-M0 cores for a while now, so I settled on an STM32F042C6, a 32K Cortex-M0 in a TQFP-48 package. The intent is to have the mcu in sleep most of the time, waking up once per minute to sample the sensor and transmit a packet then going back to sleep. I was planning on running it with a small Li-Poly battery, ~800mAh. When the STM32F042 is in one of its low-power modes (with the RTC running), it should consume less than 10uA.

STM32 Schematic Block.

STM32 Schematic Block.

Since I’ve been doing a lot of development in the IAR EWARM IDE lately, I wanted to stick with that as the development environment. It’s not particularly aesthetic, but it’s fast and capable. For now, I’ve been using the Kickstart version, which is code-limited to 32K. I haven’t needed anything more, but I’ve gotten close. Unfortunately the full license is around $4,000.

Now that I’ve chosen the micro, it’s time to decide a few other things:

  • Battery + charger IC
  • Regulators
  • Peripherals
  • User interface hardware
  • Oscillators

I’ll address these in the next topic.