Further Wanderings in Low Power Land

Introduction to Low Power

On this Arduino Day 2014, I thought I would investigate very low power operation of the ATmega328P-PU.

With low power and low energy battery powered devices becoming the norm, the desire to run the microcontroller on low voltage, derived from a coin cell or single AA cell is becoming increasingly popular. Some microcontroller manufactures, including Atmel, Silicon Labs and Holtek have identified this need for "single cell operation" and have built a simple boost converter into their device. Others - particularly, EM Microelectronic, have a core, the EM6682 that will actually run at 0.9V.

So we are going to see a proliferation of low power microcontroller solutions, and as a preliminary investigation into what was to come, I thought I'd explore the performance of a very common micro, as used in all Arduino Unos - the ATmega328P-PU, one of Atmel's PicoPower range.

This post is inspired by Nathan Seidle's Spark Fun post of 2011 "Adventures in Low Power Land".

Nate wanted to get a ATmega328 to run at the lowest possible sleep current whilst used in a digital watch application.

Now typically, an ATmega328P running code at 16MHz will draw about 7mA at 3V3, and whilst asleep, with almost everything turned off, Nate's investigation showed that 1.0uA operation was feasible.

I wanted to explore the territory between these two extremes, and determine whether there were other "safe havens" of operation, which could be usefully be exploited for low power applications.

I wondered whether by a combination of low power techniques it would be possible to run the Arduino at a greatly reduced clock speed, and at a lower voltage, and still have the microcontroller  running code and communicating via the UART.

Please note that this investigation is entirely experimental.  Several of the ATmega peripherals will no longer function at low voltage and low clock speed - in particular the ADC.  Also it should be remembered that just turning on an LED is going to consume many times more microwatts than just the microcontroller running code.

Getting Started

My initial experiments involved using  the prescaler on the external 16MHz crystal oscillator. On the standard Arduino Duemillenove with ATmega328 16MHz, the brown out detector is set to 2.7V. With this setting, a supply of 2.8V and the prescaler set to give a 62500Hz clock, the current dropped to a more reasonable 750uA.  This was a modest first effort, as even at less than 1mA, a coin cell is only going to last about a week.

I then decided that the 16MHz oscillator was always going to be power hungry, so I followed Nate's example and configured the device as an Arduino Pro 3V3 8MHz using the internal 8MHz oscillator.  I also turned off the Brown Out Detector (BOD) because I soon realised that this would prevent the IC running at low voltages.

I divided the 8MHz internal clock oscillator using the maximum prescaler value of 256. This meant that the code was executing at 31250 Hz, or 1/512 of the usual execution speed.

By setting Serial.begin(76800), I was able to get 300 baud communications from the new divided clock frequency.

BOD Alert!

There have been a number of cautionary tales about disabling the BOD, which could lead to corruption of the flash memory, but as this was entirely an exercise in pushing the device to investigate it's lowest limit of supply voltage and current, I accepted that there may come a point where I could no longer guarantee code integrity.

So I disabled the BOD, and the current started to creep down, first to 450uA, then 300uA. I then remembered the post in Jeelabs, about how the MCP1702 regulators start to draw large amounts of current when the supply voltage falls below their minimum LDO point.

So after I removed the MCP1702 regulator and set up a 2.0 V supply, the current dropped massively, remaining close to 100uA.  I then wondered if I could lower the supply to closer to 1.8V and see what current consumption would result.

I quickly learned that the CP2102 serial adaptor was supplying current to the application via the Rx line. The greater voltage on the Rx line leaks through the input protection diodes on the Rx input and contributes about 80uA - which caused the super capacitor to charge up!  I disconnected the Rx line, to ensure that subsequent measurements were accurate.

A rather poor, unregulated supply made from a potential divider on the 5V supply from my CP2102 cable, allowed me to get a datapoint at 1.8V, where the average current was close to 60uA.  The individual characters sent from the UART at 300 baud, were clearly visible in the current measurement.

Unfortunately, I didn't have access to a variable low voltage power supply, so I charged up a 0.22F super capacitor and ran the ATmega from this, monitoring the voltage and current drawn, via the voltage drop across a 1000 ohm resistor in the +ve supply lead, as the super capacitor slowly discharged.  Here are some voltage and current way-points during the discharge - it really highlights how dropping the supply voltage reduces the power (microwatts) drastically:

Volts        Current             Power

3.30V       450uA              1485uW
2.50V       100uA              250uW
2.00V       70.5uA             141uW
1.95V       64.7uA
1.90V       62.5uA
1.85V       61.3uA
1.82V       60.0uA
1.80V       58.9uA             106uW
1.75V       57.6uA
1.70V       55.6uA
1.65V       53.9uA
1.60V       51.1uA
1.55V       48.2uA
1.50V       44.5uA             66.75uW
1.45V       39.8uA             57.71uW
1.44V       38.7uA           - Dead!

Current consumption shoots up after 2.5V!

Power / uW in red also increases dramatically

As can be seen from the graphs - Low Power Land is definitely entered below 2.0V supply voltages!

Using this method I was able to show that code was still running at 1.71V supply and 55.8uA average consumption - printing serial to the terminal every second or so.

At 1.68V supply the CP2102 would no longer correctly receive characters - although the ATmega was still sending them - but at a much reduced amplitude.

So the ATmega328P-PU will still run code at 1.45V  consuming about  58 microwatts of power.

Later in the evening, I realised that it was my CP2102 serial adaptor cable Rx input that was giving up at 1.7V, and failing to read the very low voltage signals from the UART.   I continued to monitor the ATmega UART output with the scope running code right down to a supply voltage of 1.43V and 39.5uA of current. The ATmega328P-PU was actually running on 56.5 microwatts of power.

If you are concerned about disabling the BOD, then assume that the minimum safe supply voltage is stated as 1.8V in the datasheet, for clock frequencies below 4MHz. Set the BOD to this lower limit and accept that you can run the IC at between  60 and 100uA, depending on clockspeed and what peripherals you have enabled.

Applications

So why is this important?  It means that we can have very low power consumption from Arduino based hardware, making it compatible with Bluetooth low energy. A simple interrupt from the BLE module can wake the '328 to whatever clock frequency is needed to handle the RF data.

Additionally, it allows new power sources to be developed, such as energy harvesting devices, or even a small 3" x 2" photovoltaic collector, illuminated by ambient lighting is sufficient to power the microcontroller.

Clearly their will be a compromise between fast and slow clocking, and a combination of spending long periods asleep, and waking up to run at high clock speed, may be more advantageous than plodding along at 31kHz. It's definitely a tortoise and hare situation, and the overall winner is likely to be highly application dependent.

Photos and more detail to  follow.

Clarity of Vision

A simple serial port graphing program helps debug high speed sensor data.

This week, I have been debugging a high speed 24-bit ADC, connected to an STM32F303 ARM microcontroller. Unfortunately my usual arsenal of debugging tools were starting to creak under the strain. Here I discuss existing methods, plus a new approach which will be of interest to the hobbyist/Arduino community.

The Old Fashioned Way...

With any microcontroller project, during debugging, it is essential that you have the tools available to get data in and out of the micro so that you can see what's going on. Often this may just be a UART link to a serial terminal program which allows you to print out results and enter serial commands to control the application.  Frequently, when I start with a new microcontroller, I use a simple framework program that provides the serial link with basic functions such as

putchar(x);            // Prints the ASCII character of x, sends x to the uart transmit buffer

print_num(x);       // Prints x as an integer

getchar();            // checks to see if there is a character waiting in the uart receive buffer

Now putchar and getchar  are as old as the hills, and have been associated with character input and output - probably before C was even thought of.  They may be as simple as testing for a uart flag to be set, and then writing or reading the uart tx or rx registers, but once you have these working, and can get characters in and out of your application program, then debugging becomes a whole lot easier. With just putchar you can do hex dumps of memory, send data to a file or even make a very simple realtime horizontal bargraph display - handy if you are looking at time varying analogue data.

My framework program often uses getchar and a switch/case statement to select different modes of working. One example this week was being able to control the sampling and averaging of an ADC that I have been working on, just by sending a single ASCII character to the microcontroller.

Another good technique is to set up a timer channel to count milliseconds. This establishes a time framework to your application program.  By reading the millisecond counter, it becomes easy to co-ordinate tasks at given times, say once every 10mS, or once a second, and also to print out the millisecond count at each end of a task - to see how long it takes.

Fairly early on in your developments, you will want to start testing the I/O pins. One technique is to toggle an output port line each time you enter a given routine, this might drive a LED or better still connect a scope probe and use an oscilloscope to time the event. If you are going to be laying out a pcb for your next project, it is very worthwhile to break out some of the spare I/O pins, to say a 2.54mm header, which gives you something to clip a scope probe onto, or use jumper leads to a temporary array of LEDs. Modern microcontroller packages are very small, and the pins are not easy to probe individually - so break a few spare pins out - so you can get at them easily.

This week, I have been debugging a high speed 24-bit ADC, connected to an STM32F303 ARM microcontroller. Not only does this involve high resolution data, but it is output at high speeds, which makes seeing what's going on a little challenging.  The particular ADC would be producing 24 bit readings at approaching 20kHz, and data sent at 921,600 baud. Whilst a terminal program, in this case RealTerm would be a start, it's very hard to visualise what's actually happening with streams of hex digits scrolling up the screen at an alarming rate. Clearly a new approach would be needed.

The project involves reading very small changes in voltage signals - down to fractions of microvolts, and as such it is essential to have good analogue design, and use precision low noise components. I found a good application note from Linear Technology, which describes most of the techniques in detail. If you are interested in high resolution analogue datalogging, and low noise analogue techniques - this app-note is well worth a read

Unfortunately, electrical noise is a fundamental property of the universe we live in, so minimising noise to the point where it no longer interferes with your ADC readings, is quite a challenge.

The ADC and microcontroller are mounted on a small pcb, along with voltage  regulators, op-amps and an RS232 driver IC. Whilst RS232 might appear a little old fashioned, it is a robust way of communicating between instruments over moderate distances.

The microcontroller produces a 1MHz clock for the ADC, and every 8uS, the ADC interrupts the micro, to announce that it has another reading ready.  The micro then reads the ADC using SPI, does some quick calculations on the readings and then passes the results out through the serial port for analysis on a PC.

This might appear simple enough, until you realise  that even with some data averaging, the readings are being sent to the PC every 50uS, or 20,000 readings per second, and to achieve this, the UART has to run at 921,600 baud, nearly a megabit per second.

Visualisation of Your Data

During the debugging of this project some simple tools have been invaluable to capture the data, and allow visual analysis on a graphical display. By turning the ADC sample numbers from the sensor into a "scope trace" display I could see in real time what was happening.

SimPlot - A Simple Serial Plotting Program

After a quick search, I came across a program,  SimPlot  (downloadable here) This has been developed within the Arduino community, and allows up to four channels of data to be plotted against time, like an oscilloscope display. A few lines of code will produce the 16 bit integer data in the format needed by SimPlot, and it is very easy to use. The screenshot above shows one channel of data being captured from an Arduino at 115200baud, where the ADC input has been left floating.  SimPlot allows you to set both the number of samples in the horizontal axis, and also the range displayed in the vertical axis.  By choosing a certain sample rate, and setting the horizontal scale accordingly, it is possible to determine the frequency of the displayed waveform - in the above case it's just 50Hz mains hum.

Fortunately, SimPlot will handle high baudrates, and just typing in 921600 set it up correctly and I was soon able to view the amplitude of my data, noise and all.  It is so much easier to see what is happening with a realtime trace, than to try and look at reams of hex data, or capture the data to a file and analyse later using plotting programs such as KST.

As microcontrollers become more sophisticated, and often within the hobbyist community, they are now used to read advanced analogue sensors, such as accelerometers and gyros, having a 4 channel display of analogue data like this is an absolute god-send. You can see in real time the changes in the signal, it's sensitivity to changing external parameters, such as temperature, and monitor drift and noise.

24 bit ADCs - what's available.

24 bit ADCs are now becoming more widely available, at an affordable cost.  Most of the recent developments have been with the Delta-Sigma converters, which have an internal architecture that suits high speed digital signal processing and efficient translation into silicon. As a result Delta-Sigma converters tend to be cheaper and more widely available than the more traditional successive approximation (SAR) converters.

However, Delta-Sigma converters are about a magnitude slower than the SAR converters, max sample rates of about 10,000 samples per second, and as you sample faster, the weight of noise increases, so that a 24 bit converter, might only return about 17 noise free bits at 4kHz, rising to 20 bits at 2kHz sample rate.

Nevertheless, there are some good Delta-Sigma converters, and the LTC2440 from Linear Technology is a good representation of what is available.  There has been some work done within the Arduino community on this device, and a link to a report on its performance whilst being read by an Arduino is here.

These converters are available for about £11 (Farnell) - but you will need a TSSOP adapter pcb in order to make use of them. They don't exactly lend themselves to breadboard prototyping either.

The resolution of a 24 bit converter is such that if we chose a 5V range, then the voltage represented by a single count would be 298nV - or approximately 0.3 microvolts.  Compare this to the 10 bit converter on the Arduino, where the smallest voltage step is 4.88mV,  or 16384 times larger.  However this resolution is somewhat theoretical, and not really achievable in practice. Most Delta-Sigma converters are used at very low sampling speeds, often below 10Hz, in applications such as weighing scales.

Successive Approximation converters can convert much quicker, and the AD7767 I have chosen for my project can produce a maximum of 128,000 samples per second.  The conversion rate is controlled entirely by the clock frequency you supply it with, up to a maximum of 1.024MHz. A new conversion is available every 8 clock cycles.  Currently I am clocking it at 800kHz, in order to achieve 100,000 samples per second.  These are averaged down, so that a new result is available every 8 samples - or 12.5kSps, or if you only wish one sample, then these can be output at 20KSps - which is limited by the speed of the RS232 interface.

Joining the Dots .......

In the Beginning..

In the early 1960s, Digital Equipment Corp, were contracted to build a system to control and monitor certain processes at a Canadian nuclear power station which would convey data back to a mainframe computer. One of the young hardware engineers, Gordon Bell, came up with the proposal, that rather than building a one-off, custom digital control system from their digital modules, that they should build a small and low cost programmable 12 bit computer. It's programmability would make it more flexible, and, as a general purpose product, could be sold to other customers. Thus the DC-12, later the PDP-5 was conceived. It was the fore-runner of the PDP-8, which was the first true minicomputer, benchtop sized and a major commercial success for DEC.

The idea of using a small computer to perform specific tasks, whilst interfaced to a larger machine was not entirely new.  Seymour Cray had developed the CDC-160 back in 1960, again a 12 bit machine, reportedly designed over a 3 day weekend!

History indeed repeats itself, as some forty years later, the Arduino team first designed their product to be an input/output board, which would interface with a desktop or laptop machine, running Processing. The easy to program Arduino could be connected to analogue and digital signals and make these available to the laptop for controlling or graphing, in a way that previously had been a lot of hard work. Either you needed to be an embedded specialist, with a register level knowledge of programming microcontrollers or use proprietary software.

It's now 10 years since the creation of the first Arduino, and this will be celebrated around the world on Arduino Day, March 29th.  Whether you love or loathe Arduino, you have to accept that it has introduced a whole generation of youngsters to open source technology, and some of them are destined to become the programmers, developers, designers and entrepreneurs of tomorrow.

Arduino is just one of the ways in which technology has been opened up - a process that began about 25 years ago, with the creation of the World Wide Web, and followed by other notables including Linux, open source software, Android and open hardware, trailblazed by Arduino, and followed by many.

I recall that 25 years ago, when I started my career, that a genuine IBM PC cost the equivalent of about 5 months wages, and you could spend a similar amount on the software packages to run on it.  Now you can purchase a tablet machine for a few hundred dollars, and we have come to accept that a lot of the software is bundled into that price, or open source, free and downloadable from the web.

In my opinion, it is this democratisation of technology that has brought about the rapid developments we have seen over the last 5 years.

On a hardware front, 32 bit ARM devices are competing in price with 8 bit devices.  $5 will buy you a lot of processing power,  or $10 or $12 will buy a dev board that is Arduino compatible. The open source GCC compiler and a free, unrestricted IDE can be downloaded.  So for a few dollars, you have more computing power than that 1985 IBM PC or the 1964 PDP-5, which back then cost $27,000, at a time when a new Mustang would be $2000.

Other drivers of this technology revolution include wireless communications and improved battery technology.  Devices will become smaller, smarter and run for years on low cost batteries.  The SmartPhone can provide a common interface for controlling household technology, such as channel hopping on the TV, when you can't find the remote,  programming the central heating controller, or selecting the correct program on the washing machine.

All of these applications are on convergent trajectories, powered by open source technology which is now accessible to the hobbyist.

Quick Hack - Arduino with Bluetooth Low Energy

This week, the nRF 8001 module arrived from Olimex. These are available for around $14 and take just over a week to ship from Bulgaria.

In order to connect it up, I used a "bare bones" Arduino like board of my own design, that runs at 3.3V This is important, as the nRF8001 IC from Nordic Semiconductor will not withstand 5V.  The board is simply an ATmega328, a 16MHz crystal, reset circuit, a 3V3 regulator and a 6 pin header for a FTDI cable.

The nRF8001 module from Olimex is breadboard friendly, and once having soldered a couple of headers to the underside, it can be mounted in a breadboard.

In the middle is the nRF8001 IC, with the 16MHz crystal above it. To the left is the low power 32kHz crystal, and to the extreme right of the  pcb is the L-shaped pcb trace antenna.  Another 22 surface mount passive components complete the design.

The close up above shows how just 8 jumper wires are needed to connect it. The top header connects 3.3V, 0V and Reset, and the bottom header connects MOSI, MISO, SCK and two handshaking signals REQN and RDYN on digital pins 9 and 8 respectively.  These are used to synchronise the transfer of data between the ATmega328 and the nRF8001.

Once I had downloaded the latest Nordic Semiconductor nRF8001 example sketches and Library from Github, and loaded the nRF UART app from the Google store (Apple version also available), it was very quick and easy to get the example running.  Within a few minutes I was able to type ASCII characters into the phone and have them appear on the Arduino serial terminal window, and vice versa.

Other example code allows the phone to control the various ports on the Arduino remotely over the BLE link.  Once connected the nRF8001 uses only about 600uA average current, whilst the ATmega uses about 7mA!

 

More ARM Adventures

Update 28/03/2014.

An excellent online book "Discovering the STM32 Microcontroller" by Geoffrey Brown is now available.  This comprehensive, up to the minute text leads the beginner through the main techniques involved in writing applications, and interfacing hardware devices to these increasingly popular microcontrollers. Communications with serial, SPI and I2C are covered, also interfacing to a colour LCD, a SD card and a Wii Nunchuk.

In an earlier post, I described how 32 bit ARM microcontrollers are now making substantial inroads into applications previously hosted by 8 bit micros.

In order to get started with ARM devices, I decided to make a minimalist breakout board for the STM32F303, which has an ARM Cortex M4 core. This has a floating point unit and additional DSP instructions making it quick for math intensive code.

The STMF32303 has a maximum clock frequency of 72MHz, but has several low power modes where it can be clocked from a low frequency internal clock source.  This is important for battery powered devices,  where battery life may be an important issue.  At 72MHz, I measured the current consumption at 35mA from the 3V3 supply.

One of the biggest challenges to the ARM newcomer, is understanding the vast menagerie of on-chip peripherals and how to initialise them.  Once this is mastered, programming becomes as simple as any other microcontroller.

Arduino manages to make the task of programming easier, by providing a few memorable C++ functions, which take care of basic I/O operations, effectively shielding the user from the minutiae of bit manipulation at register level.  It is this hardware/register abstraction layer which makes programming the Arduino so much simpler for beginners.

There is no reason why these user friendly functions cannot be recreated on the ARM. So if you prefer 

digitalWrite(1,HIGH);

Instead of 

GPIO_SetBits(GPIOA, GPIO_Pin_1);

then this is perfectly understandable, and a lot less typing.  Abstracting complex functions to simpler, easier to remember commands is definitely the way to introduce newcomers to programming.  I'll cover more on this in a future blog-post.

For those wishing to remain within the Arduino comfort zone, Leaf Labs has produced an Arduino "look-alike" IDE for their STM32 based Maple, and Maple-mini products.  However, most of their IDE developments have been restricted to Linux platforms, having abandoned the PC as a platform a couple of years ago.

Peripherals

The STM32F303 has a rich set of peripherals including USARTS, Timers, SPI, I2C, ADCs and DACs. Additionally it has programmable gain op-amps and comparators which can help reduce the amount of analogue circuitry needed in an application.  There is also a capacitive  touch-sensor interface allowing user controls to be implemented easily on the pcb.  Almost all of the I/O pins are multi-function, and getting to know what is available where is one of the hardest tasks when first getting started with the ARM.

On the ARMiGo board, I have tried to simplify this by primarily putting the analogue interface signals along one side of the pcb and the digital signals along the other, but a closer inspection of the datasheet will show that further pin-swapping between functions is possible.

ST Microelectronics provide a comprehensive set of "wrapper" functions to assist the user in the process of setting up the peripherals. Ultimately these functions set the individual bit patterns in the peripheral control registers, but abstract a lot of this low level bit manipulation from the user.

In the same way that Arduino has a setup() function where most of the hardware initialisation is performed, I chose to have a separate file, which I call periph_config.c, where I put all of this setup code, and a single function Init(), called from the start of my main code, which calls the relevant functions in periph_config so as to initialise the hardware. It's then an easy matter just to change periph_config when you need a slightly different hardware configuration.

It would be relatively straightforward to automatically generate the periph_config file from some sort of GUI. Here the user would select the various functions needed and the file would be automatically generated.

Applications

ARMiGo is intended to take over when the Arduino just runs out of steam.  It has a 72MHz maximum internal clock frequency, provided from an 8MHz crystal that drives a phase locked loop. So raw speed is available when necessary, but using the clock divider, the 8MHz clock can be divided down to a plodding 125kHz, when much lower power is needed. In this condition the ARM will consume around 1mA.

Full speed USB is available on-chip, and STM have provided source code for CDC, virtual com port VCP and other USB profiles.  As well as being able to communicate directly over USB, as a slave device, with a PC or other device acting as host, all of the STM32 family have an embedded (factory programmed) bootloader which allows firmware to be programmed into the device directly from USB. This is known as DFU - device firmware upgrade.

For communicating with other devices, the STM32F303 has 3 USARTS available, plus SPI and I2C interfaces. In a recent application, I have sent data to a PC using one of the USARTs, at 921,600 baud, whilst using the SPI bus to take readings from a 24 bit ADC (AD7767) at 125kHz sampling frequency. One of the timer channels provides a 1MHz clock signal for the ADC.

The STM32F303 also has four individual 12 bit ADCs, which can sample at 5MHz. Each ADC has a front end multiplexer, allowing up to 4 analogue signals to be read from each ADC. This opens up interesting applications in energy monitoring, or as a low cost multifunction test instrument.  The excellent Miniscope project is based on the STM32F303 - be sure to watch the video of the arbitrary waveform generator - which uses one of the 12 bit DAC channels.

The STM32F303 has up to 35 I/O lines available, making it a little more flexible than Arduino or other ATmega328 boards. However, it should be appreciated that it is a 3.3V part, and whilst the digital I/O lines are 5V tolerant, the analogue ones are not.  This comes as a mixed blessing, as it can interface directly with newer 3V3 devices without the use of level converters, but caution is needed when using in a project that has mixed supply voltage logic.

ARMiGo is a low cost/low tech product to get people started with ARM. Whilst many other boards use ARM devices, the ARMiGo tries to remove to remove the clutter and provide direct access to all ports and peripherals, in an easy to use, plug in module.

ARMiGo - A breakout board for STM32F303 ARM Microcontrollers

As integrated circuits get smaller, and more powerful, it becomes increasingly difficult for the hobbyist to utilise them easily. Soldering tiny SMT parts is a challenge for many - but an amazingly useful skill, once mastered.

32 bit ARM microcontrollers are now virtually the same cost as older 8 bit devices, yet offer a many fold increase in performance, as a result of their 32 bit architecture and faster clock speed. In addition to this, they come with a rich set of peripherals, making them ideal for more demanding applications.

For the hobbyist who may have first gained exposure to microcontrollers via 8 bit products such as the Arduino, the move to 32 bit may appear a little daunting.  However we all have to progress and keep up with the times, and so now the time has come to move up to the "big school".

For a particular microcontroller to gain traction in the hobbyist community, it has to meet a few basic requirements:

1.  Low cost development boards
2. Free to use, open source toolchain
3. Lots of online code examples, projects, forum support
4. Support from a vibrant user community
5. Easy to use and incorporate into projects
6. Easy to upgrade to different devices from within the same microcontroller family


1.  Low Cost Hardware

After some investigation, and triggered into action by exceptionally low cost development boards, I have settled on the ST Microelectronics STM32F range of microcontrollers as being the basis for future projects.

These micros are already being used extensively in a range of hobbyist boards including Maple, Netduino, Olimex, Expruino, mbed, MicroPython and STM's own range of very low cost Discovery boards, which are priced around the range  ($11 - $18).

A recent offering from mbed in collaboration with ST is offering boards for as little as $10, and come complete with a detachable ST Link programmer, which can be used for programming other boards.

These boards are now available from suppliers including Farnell, Newark,  Mouser, Digikey.

Low cost hardware is the new trend, with dev kits often being sold at close to cost price,  so, gone are the days when you forked out £20 for your first Arduino, and then another £20 when you wanted to build it into a more permanent project.

2.  Open Source Toolchain

Free to use toolchains are nothing new. Microchip realised in the 1990's that they would sell more chips if they made the coding tools free. Fortunately the ARM microcontroller is supported by GCC, and there is a free to use IDE,  called CooCox CoIDE, which supports a wide range of ARM chips from several main manufacturers.

3. Lots of Online Support and Code Examples

Getting started with ARM chips is as easy as dowloading the free tools, installing some drivers and learning the basics from a wide range of code examples easily found online.  The STM32 range of microcontrollers have been available for about 4 years now, and so there is a rapidly growing resource of online code examples, reference designs and supporting documentation. ST Microelectronics produces a firmware pack for all of its evaluation and Discovery boards, and this is a good place to start for code examples. Other online examples,  which are easily Googled, are downloadable from repository sites such as Github amongst others. YouTube is also a good place to search for STM32 projects. As the processors are considerably more powerful than 8 bit devices, they are often used with LCD colour displays, and there are several examples of these on YouTube.

4. A Large User Community.

All popular devices build up a loyal user community and the STM32 is no exception.  The popularity is driven by low cost hardware and free tools, and is ever expanding as new products based on the STM32 are released.  Again a simple Google search will often turn up a blog from an enthusiast who has already covered a lot of ground and is happy to share it. 

5. Easy to Incorporate into Projects.

This is where things are not so clear-cut.  The problem with most dev boards is that they are either too big, or use header pin layouts that are incompatible with breadboard or stripboard.  This can be a major inconvenience, and often force the user to buy some form of shield for mounting other hardware expansion, or resort to using female/male jumper leads, so that the headers can be jumpered into a breadboard. Either way the result is not ideal, and a rat's nest of jumper wires is neither permanent nor easy to work with.

6. Easy to move between devices in the STM32 family range.

There are now a considerable number of devices in the STM32Fxxx family, based broadly around the Cortex M0, M3 and M4 ARM architectures. Whilst to the newcomer the range of different parts may seem confusing, STM have designed the family in such a way which makes it relatively easy to move between parts.

The first thing to realise is that they are all microcontrollers, with on chip SRAM, and only the larger packaged parts will support external memory.

Secondly, all parts share identical, or very similar I/O and peripheral architectures, so if you are using USART , or Timer 2 on a 48 pin pack, you will find the same peripherals, and more, in the 64, 100 and 144 pin packages.

Thirdly, you will find that you can switch between family members - because they share common pin-outs. This means if you have designed a pcb for a 48 pin STM32F103, and you want to move up to the STM32F303, then you will find all the ports, clock lines and power pins are exactly the same - so no pcb changes are needed.

Here are some guidelines to selecting a part:

1.  How much I/O will my application require?  The GPIO ports are 16 bits wide, and devices are made with between 2 and 8 ports.  The 48 pin package provides 2 ports PortA and PortB,  the 100 pin package provides 5 ports PortA - PortE.

2. Choose the appropriate amount of flash memory and SRAM.  The smaller parts have 128kB of flash and 32kB of SRAM. The largest parts have 2MB of flash and 256k of SRAM.

3.  Choose the Cortex family member.  M0 is the cheapest with the slowest clock, and generally without USB. M3 is a good starting point with a 72MHz clock and on chip full speed USB.  M4 is similar to M3, but supports clock speeds up to 180MHz and has a floating point unit (FPU) which may be useful for intensive maths code such as used in robotics and flight controllers.

Getting Started.

Initially I bought a Discovery F3 development board, which uses a 100 pin STM32F303 processor and has  compass, accelerometer and gyro devices on the board. It was exceptionally good value at under $11 from Newark.  However, whilst it provided a platform to get me started writing code and getting the framework to support my application built, it was just too big and the double row headers are not the friendliest of connectors to use. I didn't need all of the  80 lines of I/O provided by the 100 pin device,  so I settled on the 48 pin part, which somewhat smaller, cheaper and more manageable in terms of pcb layout.

My solution was to create a 51mm x 19mm  double sided pcb, which mounts the STM32F303 microcontroller,  its clock and reset circuits and USB/programming connectors. This small breakout pcb, converts the pins from the 48 pin LQFP to an easier to use 40 pin dual in line module, and provide the minimum of features to get the STM32 to load and run code.  

This approach is not new and has been used in minimalist products such as the Maple Mini and the Arduino Pro Mini and Nano, all of which have been around for some time.

I decided to name the board "ARMiGo" in respect to its user friendliness and I designed the ARMiGo to be as open and flexible as possible, so that it can be used as a core for incorporation into other designs.  The essential parts of that core are the microcontroller, the 8MHz crystal, the reset circuit, USB connection and programming header. 

The first of the prototypes arrived this week, and now working running some simple test code.

ARMiGo uses the STM32F303 Cortex M4 ARM device which runs at a maximum of 72MHz.  The pcb also supports the STM32F103 which is based on the M3 core.

The board is the same size as a standard 40 pin DIL format IC - making it ideal for breadboarding, and small enough to be used as a plug in module in a 40 pin socket, on a larger board.

All 35 I/O lines of the ARM chip are brought out to standard 2.54mm spaced headers.

The 5 pin right angle header on the left accepts the clock and data signals from the "ST-Link" programmer/debugger device.  These are available very cheaply from ebay/taobao/deal xtreme etc.

However it is relatively simple to use the embedded STM bootloader and program it via either the mini-B USB connector on the right or via one of the USART channels.

There is a really rich mix of on-chip peripherals, which gives these small ARM parts tremendous flexibility - including the following:

Full speed USB interface

4  Fast (5 Msps)  12bit ADCs, each with up to 4 input channels

4 Programmable gain op-amps and 7 comparators

2  12 bit DACs

3   USARTS

3   SPI

2   I2C

RTC with 32768 Hz oscillator and dedicated output pin for "alarm"

10 timer channels,  2 basic,  6 general purpose and 2 advanced:5  General purpose  16 bit timer channels with up to 4 outputs for PWM generation, timing, counting etc.

1 general purpose 32 bit counter/timer - for optical encoder reading etc

2 advanced 16 bit timers for complimentary PWM generation etc.

In addition, the analogue section of the IC contains programmable gain op-amps and comparators which feed the ADC channels, and can be used to replace external analogue circuitry.

This small 48 pin packaged part contains 128KB of Flash and 40KB of SRAM - of which 8K can be battery backed up when the rest of the IC is powered down.

In the attached picture, most of the lower row of pins is the analogue I/O, and the upper row is mostly digital, although there are many options for allocating the peripheral functions to different pins.

With 5MHz 12 bit analogue interfaces it offers greater resolution and much faster sampling speed than Arduino. Additionally the 72MHz clock and 32bit wordsize will all make for a much faster data thoughput.

The combination of 35 I/O lines, on chip USB and a user friendly module, should make ARMiGo the starting point for a wide variety of new projects. Prototypes can now be breadboarded or easily built on stripboard, and the module just plugged straight in.

If you want more details about ARMiGo - please drop a comment.