Saturday, July 25, 2015

First steps coding and speed testing the STM32F746 Break Out Board

It's a few days since I received my prototype STM32F745 Breakout boards and I have slowly been writing some basic firmware functions to test out the hardware.

Whilst I have done a fair bit of code development for the STM32F4, F373 and F103 microcontrollers, this was my first exposure to the awesome Cortex M7.

Every programmer wants to create a comfortable coding environment around any new microcontroller platform, and often this is done by porting familiar routines across to the new target and re-using tried and tested libraries in order to develop the application.

With a few basic functions, you can do a surprising amount - here's one approach

digital input and output - flash a LED to confirm code is running
serial USART - allows text output and a simple command interface from PC
timers - by establishing a millisecond and microsecond tick you have precision timing
timers also allow pwm to be generated
ADCs - 12bit or even 16bit resolution measurements become possible
SPI  - connect to SD-Card,  Colour TFT LCD, etc
I2C - add an eeprom
RTC - and battery backup.  The STM32F series often have on chip RTC and non-volatile RAM

The Arduino project has done this time and again for the various microcontrollers used on their boards - proving that code originally written for an AVR, can be ported to various manufacturers ARM processors.  The STM32duino project has gained a fair amount of traction porting the Arduino environment so that it will run on STM32F1xx  M3 and STM32F4xx M4 processors.

The Arduino language successfully removes much of the complexity, or possibly quirkiness, from the C programming language, and at the same time creates a robust application framework onto which the hardware specific functions and libraries may be placed.

Purists, or old-school C programmers, may delight in criticising it's oversimplification of the language, but for beginners or those that have had no exposure to traditional C and C++, it's a fast way of getting simple applications running - and now with the benefit of moving between a range of more capable processors.

Tool Chain

I found that I could download a codesize limited (32KB) version of the Keil ARM-MDK, which runs under their uVision 5 toolchain. This was the easiest route to take, as it includes all the library headers, and numerous examples of how to configure the various on-chip peripherals.

If you are familiar with the STM32F  Standard Peripheral Libraries,  then this may be a mixed blessing.  STM have ported their functionality across to their new Hardware Abstraction Layer HAL, under their new development suite known as STM32 Cube.

There is no question that STM32 Cube will provide faster development for complex applications, as it combines graphical libraries, ethernet and TCP/IP stacks in an integrated design environment. However, the initial barrier to learning enough about HAL to reach the point of understanding it's various structures can be quite high, leaving the user somewhat perplexed that what should be easy, turns out to be really quite a challenge.

Once over the HAL Hurdle - progress will be much quicker.

Get it Running

The usual route to getting a new board up and running is to start with the bare minimum of code to prove that it will actually run.  Traditionally this is normally a simple LED flashing routine.
With the STM32 series of microcontrollers - and any 32bit mcu, for that matter, there is quite often a considerable quantity of registers to initialise first.

I started with the LED flash example, that came with the ARM-MDK download. It is often wiser to start with a known working example, rather than start from scratch, especially with an unfamiliar microcontroller.

As it happened, my problems were initially hardware related - as I had forgotten to connect the all-important analogue VDDA supply. Once this was connected, the microcontroller accepted code and sprang into life.  Without VDDA, the clock oscillator and the PLL blocks are not powered - so the mcu cannot run.

Once I had the LED flashing, it was time to check out the system timing, and make sure when you used the 100mS delay routine - that it was actually 100mS.  I had used an 8MHz crystal and so I had to change the PLL divisor ratio, in order to get the right timing, as the code in the example was for an EVAL kit - which used a 25MHz crystal.

Once this was done, I wrote the code to configure the GPIO pins so that I could toggle more of the I/O pins.

Next - USART

Basic GPIO is always the starting point for code development, but pretty soon you need to get a serial connection to a terminal program - so you can see numerical and text output plus the means of controlling the application with a simple command interpreter. With about 3 or 4 basic functions you can implement a surprisingly flexible user interface.

1.  putchar  - send a single ASCII character to the serial port.  This is the basis of all serial output.
2.  getchar  - receive a character from the serial interface
3.  print_num  - this will send an integer number to the serial interface
4.  Get_Serial  - a routine that accepts simple alpha-numeric serial commands for machine control

The USART proved somewhat trickier to implement, mainly because the HAL routines were somewhat different to the old STM32Fxxx_USART library code that I was used to. After a day spent failing to import the USART initialisation into my code, I decided to port my code into the HAL USART example - starting with a known working example.

This approach was a lot more successful, and soon I had printf(), putchar() and getchar() all working nicely.

Benchmarking the STM32F7xx.

Having got the first prototype running to the point where I could run code and get numerical output, I decided that it was time to run a standard benchmark test on it - so that I could compare it with other devices.

The dhrystone is the classic integer math benchmark that has been run on various computers for over 30 years.  A C code version (actually Arduino) of it can be downloaded from here

Some months ago, I tested the standard Arduino MEGA, which uses an ATmega2560 running with a 16MHz clock.

The results were as follows

ATmega2560 16MHz

Dhrystone Benchmark, Version 2.1 (Language: C)
Execution starts, 300000 runs through Dhrystone
Execution ends
Microseconds for one run through Dhrystone: 78.67
Dhrystones per Second: 12711.22
VAX MIPS rating = 7.23

STM32F746 216MHz

Dhrystone Benchmark, Version 2.1 (Language: C)
Execution starts, 300000 runs through Dhrystone
Execution ends
Microseconds for one run through Dhrystone: 3.33
Dhrystones per Second: 300000
VAX MIPS rating = 170.74

So the STM32F7xx is approximately 24 times faster than the Arduino on integer maths. But when you look at the whole package:

1M Flash
USB full-speed
Up to 6 SPI
Up to 18 timers
etc, etc

The list of peripherals is most comprehensive.  Best check the datasheet for full details.

And all available in LQFP packages that the hobbyist can actually solder.


This week I have made great progress getting the basics of a code development environment put together for the STM32F746.

The board was cheap and easy to build, with a record short development time of just 14 days from starting the pcb layout to first having the LED flashing, and so far all appears to be working as intended.

This is certainly a powerful processor, and with the right coding environment, such as Arduino or mbed will make a great little target for those wanting to move into 32bit  ARM bare metal programming.

Wednesday, July 22, 2015

How Ragworm helped me create a STM32F746 breakout board in under 2 weeks

EagleCAD Layout

Last time I described how ST Microelectronics had finally released their long awaited STM32F7xx series of ARM Cortex M7 microcontrollers, and how, conveniently for the hobbyist, that a device was available in a 100 pin LQFP package.  All that was needed was a suitable break out board so that the new device could be evaluated and built into cool projects.

The Solution

The solution was to design a simple breakout board, and so the idea of BOB - the STM32F746 break out board came to fruition.

I wanted a fairly rapid turn-around on this board - so without delay I set about the CAD design - commencing after lunch on Tuesday July 7th.

Mini-Projects like this can be undertaken quickly and cheaply by the hobbyist  by using free to use (eg KiCAD, EagleCAD) printed circuit design tools that run on all common platforms.  An idea can readily be turned into a real pcb and a real design with the use of these tools plus the relatively recent online pcb manufacturing services offered by a number of companies.

Previously, I had looked at some of the very low cost pcb services - like SeeedStudio Fusion pcb - which is a Hong Kong/Shenzhen based outfit which will offer very economical pcbs - provided that your design will fit into a 5 x 5cm or 10 x 10cm board size. Outside these board formats, things become a lot more expensive. In addition, overseas shipping charges from mainland China, may cost more than the actual pcbs. Whilst these services will deliver very cheap pcbs - it may take 3 weeks or more from sending the files, to getting the boards in your hand.

Fortunately, there are a number of local suppliers in the UK, who have set up services aimed specifically at the hobbyist and prototyping marketplace. They offer typically a 10 day turnaround for 2 layer, plated through boards.  Provided that your design rules are not too extreme - and you are happy with a minimum track and gap size of 6 thou, and a minimum drill of 0.5mm then these services are fast and economical.

The Design.

The schematic design took an afternoon, as I had to create a new symbol for the STM32F746. Another half day of pushing tracks around and the layout was nearly finished.

This is an easy board as boards go - as the dual row header connectors are almost an exact 1:1 match to the pin-out of the 100 pin LQFP mcu package.  I just had to add the crystal, RTC backup super capacitor and the connectors for connecting FTDI and USB.

It was then a case of finalising the board layout in EagleCAD and then sending off the gerber files to a local pcb manufacturer.

The Sting

Departing from my supplier of over 10 years, who had become increasingly expensive, and had recently made a number of manufacturing errors and delivery cock-ups, I decided to move my business elsewhere and choose a new pcb supplier.

The Worm

This time I chose Ragworm, based in Kent, whom I had had recommended by a number of fellow open source hardware enthusiasts, in particular Glyn Hudson at Openenergymonitor - who regularly uses them for his designs.

The Ragworm operation is one part of a small family run firm, with a traditional pcb manufacturing operation, that has developed an online service specifically aimed at the needs of hobbyists or those that need a small quantity of  economically priced pcbs.


I first checked my existing supplier's prices,  5 off, 2 layer pcbs size 66mm x 66mm on a 10 day turnaround. The price came back at £92.66 - however this is not the full story - once you add 20% VAT and £10 for shipping we have a bill of  £121.19.

By contrast, the Ragworm online ordering process is a breeze - just enter the X and Y dimensions of the pcb and the quantity required, upload the zipped gerbers and the price you see, is the price you pay. In the case of the Bob board  the grand total was £81.02 - a saving of just over £40.  This  33% saving was such a no-brainer, and with the payment process handled by PayPal made the whole process very quick and easy.

The order was placed on the morning of Thursday 9th July, and at all stages of the process, I was kept updated by email by one of the team at Ragworm.  On the afternoon of July 16th, I was informed by email that my pcbs were to be dispatched that day - barely a week after I sent the order. A 10 day service turned around in only a week!

One of the ways in which Ragworm keep their shipping costs down, is by using UK 2nd class post. This is not the fastest service - but under the circumstances it was not a problem, and my boards arrived on the morning of Monday 20th July.

The freshly minted board back from Ragworm

The bare boards were exceptionally well made, with good definition both of the tracking and the screen printed legend.  In talking with Stacey Driver at a local Raspberry Pi event, I found out that this is because they were using a better type of white screen printing ink - that gives better clarity.  It stands out well against the orange background. Whilst these boards use ROHS compliant HASL (hot  air solder leveling) this is ideal for prototype boards  - making them easy to solder by hand.

The next challenge was to make up the pcb to the point where it would run code.  This involves soldering down the processor, the crystal, a voltage regulator and a few decoupling capacitors and connectors.  The picture above shows the minimum build of the board. Not fitted at this stage were the boost regulator (to allow operation from a Li Ion battery) and the USB components.

The board has been designed to provide a STM32F7  equivalent of the STM32F4 Discovery board. This means that almost all of the 80 or so GPIO lines are brought out directly to the dual row 50 way header connectors underneath the board.  For those familiar with the F4 Discovery board - this is a very close copy - with the important interfaces unimpeded by additional hardware. The only thing missing is the ST-Link programmer section - but if you already have a Discovery or a Nucleo board, you can use this to program and debug the board.

Initial Testing.

The FTDI cable provides a source of 5V to power this board - as well as a serial debug port.  The on board 3V3 regulator provides a source of VDD and VDDA.  Remember to connect VDDA - otherwise the PLL and clock circuit will not work, and your board will appear lifeless.

A single orange LED, connected to PC13 shows that there is life.

I had hoped to use mbed to program this board - but their compiler (at the time of writing) does not yet support the STM32F7. Instead I downloaded the 32KB codesize limited version of Keil's uVision 5 - as this provided all the toolchain and libraries that I needed.

After hacking their blinky example - so that it uses PC13 instead of PI1, I very soon had the orange led winking at me - and with the fundamentals of the pcb proven to be working, it was time to get down to some more serious code development.

I hope to use the STM32 HAL libraries to give "Arduino-like" functionality to this board. Additionally, I am recutting the Bob design onto a n Arduino MEGA compatible footprint. This will be the subject of a future post.

In the spirit of open source hardware - if you you would like the EagleCAD design files for the STM32F746  BOB board - you can find them here.  Unfortunately I cannot offer any assistance at this stage with firmware, except for the most simple of Blinky code.

The next blogpost will have more details of how I managed to get some simple firmware running on this board - plus some speed tests - relative to the Arduino.

If you are in the UK, please consider using Ragworm for your latest pcb projects.

From Ragworm - with Love :)

Thanks to Stacey, Stephanie, Adam and all the pcb staff at Ragworm, who turned this mini-project around in record quick time.

Ragworm can be found at the following site: and also have Twitter presence @ragworm

Saturday, July 11, 2015

At last - The STM32F7xx a 216MHz ARM Cortex M7 core for the hobbyist

ARM core microcontrollers have made significant advances over the last few years, and last week saw the commercial release of the STM32F746 - an ARM Cortex M7 core that runs at 216MHz.

With this newly released microcontroller, we now have the means to make a very fast "Arduino".

At the same time as releasing the STM32F7xx range,  ST have made a low cost Discovery Board available.  This breaks with tradition over previous Discovery boards  and is very much all the bells and whistles needed to showcase the new F7 family.

It comes with a 4.3" capacitative TFT colour LCD, and some fairly sophisticated demo software.
In addition it has Ethernet, additional external SDRAM, NAND flash, audio interfaces, camera interface, microSD socket - and what little I/O is left is brought out to Arduino compatible shield headers!

You can read all about the new STM32F7-DISCO board here

More importantly for the hobbyist, the STM32F7xx part is available in a series of LQFP packages - which whist still quite a challenge to solder to a pcb - is not as impossible as Ball Grid Array BGA packages - which need to be machine placed and reflow soldered.

The STM32F746 is available in 100, 144, 176 and 208 pin LQFP packages.  The three larger sizes have additional GPIO ports, and are ideal if you want to drive an LCD using 8 bit RGB parallel data. However, I chose the 100pin package - to keep it simpler for the hobbyist.

I have been using the smaller packages of M4 ARM for about 18 months, and was keen to upgrade to the M7 and at least evaluate the 2X performance increase and the faster I/O.

My current application is particularly I/O intensive - so I needed unhindered access to all the pins. It is a multi-axis motor control board and as such needs 4 quadrature decoders - for rotary position sensing. It also needs 4 USARTS, USB, and complementary PWM for driving two dc motor H-bridges.  There is a user interface consisting of a small (2.8") colour TFT display driven by a SPI bus, 5 user buttons and a scroll wheel encoder - for menu item selection. Further inputs from sensors and safety limit switches mean that virtually all of the 80 I/O lines are  committed.

Having read the datasheet, I found that the 100 pin LQFP package is not quite pin compatible with the STM32F407 Cortex M4 device.  ST Microelectronics have chosen to add another power pin, and as a result, shifted 30 of the I/O pins one place to the left.  (The other 70 are in their original locations). This was going to need some board modifications compared to my M4 designs - but then I had the idea of  making a simple Break Out Board, which would be pin header compatible with the STM F4 Discovery Board.

Whilst the new STM32F7-DISCO board is a superb showcase for the new F7 microcontroller - the lack of free GPIO and access to peripherals made it too limiting for my application - so I decided to bite the bullet and make a very simple dev board - with every signal broken out to pin headers.

Anyone familiar with the F4 Discovery board will see that this has the same pin headers. The ST-Link section of the board is not present - as it is assumed that the user will already have a ST-Link or other means to program the board.

On the left is a mini-B USB connector which will power the board, and the mcu can run USB VCP firmware to communicate with a PC. In addition USART 1 and USART 3 are broken out in the form of FTDI compatible headers.  USART 1 can be used to bootload firmware onto the board - which I  have conveniently included RESET and BOOT switches for this purpose.  All STM32F devices (and virtually all manufacturers ARM core devices come with a factory bootloader, to allow for some simple means of programming).

In addition to a 5V supply, the board uses a MCP1640 boost regulator - and can run on voltages down to about 1V. This allows the use of LiPo or even alkaline cells to power the board.

The board is fitted with an 8MHz crystal for the main oscillator - with an on-chip PLL that synthesises the main clock at 216MHz, and a 32768Hz watch crystal for the Real Time Clock. There is also an 0.22F supercapacitor to maintain the RTC registers and the non volatile RAM.

The STM32F7xx offers a performance increase of approximately 2.2 over the previous F4 series.  It has built in display controller - so ideally suited to driving LCD panels in parallel mode. The larger LQFP packages (144, 176, 208) are ideal for direct drive of LCD panels using 8 bit RGB. There is 128K extra RAM and an external memory interface  - over and above what the F4 offered.


Digikey, Farnell/Newark and Mouser hold stock of the STM32F746VGT6 100 pin  microcontroller.

It's one off price is about $17.75 or  $16.16 in 10 off

The 66 x 66mm pcb could be sourced from low cost board manufacturers for about $2.20 in 10 off quantity - such as SeeedStudio PCB service

So for about $25 outlay  - you could have a very capable 216MHz ARM board which can ultimately be programmed with open source tools - such as GCC, Arduino, Python, Javascript etc.

Final Impressions.

The STM32F7xx range represent the current state of the art in ARM devices to be used stand-alone in microcontroller mode- without the use of an operating system.

They contain a very rich mix of GPIO and periperals, plus the ability to drive a colour LCD - for applications where a modern user interface is needed.

At the same time, you have full access to the I/O ports - allowing you to drive I/O at up to 108MHz  - which makes for a very versatile real time controller - to interface with sensors and actuators.

USB and ethernet is on-chip (but the ethernet will need an external phy device).  ST Microelectronics provide a library of standard peripheral firmware and USB plus TCP/IP stack to allow these devices to be used to maximum advantage.

Whilst this device runs at better than 200MHz - it is only a single core device.  It is not in the same league as the 900MHz 4 core Raspberry-Pi 2, nor should it be considered to be.  It's more equivalent to a high speed Arduino Due, than a low end Pi.

The difference is that a hobbyist skilled at soldering can make and repair one of these for themself, and use it as the basis of new designs, whereas the Pi, relying heavily on BGA devices is well beyond the scope of amateur construction. The breakout board shows that you can still put a microcontroller, but a fast one, down onto a simple pcb, with crystal and reset circuit, and a serial USART connection, and with minimum effort using opensource programming tools have it up and running code.

Saturday, May 23, 2015

Using Piano Forte with the Espruino Javascript Interpreter

Piano Forte - with ESP8266 WiFi and HM-11 Bluetooth Low Energy 

In the last few weeks, a few things have come to light that make working with the STM32Fxxx series of ARM microcontrollers a lot more fruitful.

Espruino - JavaScript On-Board

The Espruino project, which provides a JavaScript interpreter for several of the STM32F ARM devices has blossomed and matured, giving a whole host of new powerful functionality and the benefit from the immediacy and interactive nature of an interpreted language.

Also - there is now a large user base for Espruino, and a forum offering help and guidance for the newcomer - as well as code examples.

As the standard variant of Piano Forte uses virtually the same microcontroller as the Espruino board - (they are both STM32F103 with 256K of flash and 48K of RAM), it's just a case of downloading the latest code image from their site and programming it in using the STM32 bootloader utility.

Making Connection

Espruino uses the STM full speed USB com port driver, but if there is no USB plugged in, it defaults to USART1 which appears on PA9 and PA10.  This is useful for testing - as it allows you to get a board up and running with just a FTDI or similar serial cable.  The serial baud rate defaults to 9600 baud - but this is intentional, because it allows a Bluetooth module - such as the HM-11 to be used directly for programming and communicating with the Piano Forte.

The Piano Forte was also designed to be an I/O board for the Raspberry Pi.  The Pi can be used to send the javascript text across to the Piano Forte - again at 9600 baud - using it's UART pins (8 and 10) on the GPIO connector.

The FTDI  is debug cable connected via USART1 - this also has access to the serial bootloader

PA9      Tx
PA10     Rx

If the Piano is to be fitted to a Raspberry Pi - the FTDI cable is redundant and the USART1 is connected to the PI GPIO header via a couple of series resistors on the underside of the pcb.

Wireless Options

Piano Forte was designed from the start to allow various wireless connectivity options. These will be most useful when the board is intended for stand- alone operation - and not as an I/O slave for the Ras-Pi.

An 8 pin header is included on the pcb to allow the ESP-01 to be fitted.

The ESP8266 module is connected via USART2 which appears on PA2 and PA3

PA2  Tx
PA3  Rx

Additionally there is a footprint on the pcb which accepts the HM-11 Bluetooth module.

The HM-11 BLE module is connected via USART3 on ports PB10 and PB11

PB10 Tx
PB11 Rx

On the first set of prototype boards this will need a couple of wire links.

Friday, May 08, 2015

Interfacing a Chord Keypad to Papilio Duo FPGA Board

Five keys plus thumb operated shift/control key
This is a simple chord style keypad that I made up a few years ago.  It is loosely based on the Microwriter - an early UK designed portable keypad / notewriter.

The five main keys are located under the fingertips and thumb of the right hand, plus an additional shift key that can be held down with the thumb.  This combination allows up to 64 key combinations  - which is enough for simple ascii, alphas and numerals.

However, this time the application is not for text entry, but to allow very rapid access to menu items, tools and colour options for a CAD program - without having to break concentration and use the keyboard.

In the early 1990's, Charles Moore - the founder of the Forth programming language, devised a similar simple keypad, to allow him fast, direct and immediate control of his OKAD suite of VLSI CAD design tools. It means that all the frequently used options, for example the toolset in CAD, are immediately below your fingertips and accessible without remembering a series of keyboard strokes or moving the mouse off the working drawing area, to the menu bar, to select a new tool.

If this multi-keypad were combined with the position and scrolling functions currently provide by a mouse, then it would mean that a considerable amount of program interaction could be done from the "mousekey"  without having to take one's hand of the mouse to type at the keyboard.

Wiring Up

The keypad will interface directly into the Atari joystick port of a Classic Computing Shield that I purchased from Gadget Factory - as part of the Papilio Duo development kit. I am slowly developing a stand alone CAD workstation, based around a 32 bit soft processor running on the Papilio Duo FPGA.

The wiring is very simple - just 6 microswitches connected to inputs pins which short to ground when pressed.  The Computing Shield provides 47K pull-up resistors - such that the port lines will all appear high until a keyswitch is pressed. The wiring schematic is provided in the Computing Shield hardware guide

For the moment, the keypad inputs will have to be polled, but a little more logic - such as 6 diodes, would allow a further line to indicate an interrupt from the keypad - if any switch is pressed, the diode AND  (inverted logic OR) would bring the interrupt line low.

Decoding the key inputs in code is fairly simple - we assign binary weights to each of the key inputs, and then the unique combination of switch presses is the binary sum of these weights.

For example - assign a weight of:
1 to switch 1,
2 to switch 2,
4 to switch 3,
8 to switch 4,
16 to switch 5,
32 to switch 6.

If switches 1 and 2 are pressed together, the decoding returns a value of (2+1) = 3.

Some consideration was given to switch debounce - multiple sampling of the key-inputs until a stable, repeatable sum is achieved.

The keypad is first scanned to see if any key is pressed.  If there is, we wait for 30mS and scan again. We then wait a further 30mS and scan a second time.  If the first and second scans are equal - we know we can return with a valid keycode.

Why a Custom Keypad?

The keypad provides a simple and fast means of navigating and selecting a wide range of options from a menu.

It may be used for causing a quick change in operation - such as an original games controller.

It can also be used for text input - but this requires a bit of practice and learning the character set.

Saturday, May 02, 2015

Benchmarking Arduino - and his Chums.


The standard Arduino based on the ATmega328 is an 8-bit device with a 16MHz clock frequency and 2K bytes of RAM.

I have for some time been exploring more powerful alternatives to the Arduino - especially the 32 bit STM32Fxxx ARM Cortex M4 range of microcontrollers, and some softcore processors implemented in a FPGA.

The one thing that these processors have in common is that they can all be programmed using the Arduino IDE - so in theory, code written for the Arduino will run on all devices -almost without modification.

The flavour of C++ used by Arduino has become a kind of lingua franca for these widely varying processors, allowing access to vast knowledge base and range of libraries that permit the easy interfacing of hardware devices. In truth, if you wish to use an integrated device or sensor, then someone will already have created an Arduino library for it.

Since the earliest days of commercial computers, both manufacturers and users have had a strong interest in their computing performance. Computers were expensive, and computing time was equally expensive. Any way of increasing performance and reducing programming costs was sought after. As memory technologies improved, processor cycle times reduced to match the shorter access time of the memory.

When launched in 1965, the PDP-8 was capable of 312,500 12-bit additions per second.  How does the Arduino compare with that figure?

Into Practice

The Arduino is a great platform for trying things out.  Whilst not the fastest board available, it's resources are easily accessible, and the millis() and micros() timer functions allow simple benchmarking to be done. 

Remembering the claimed performance for the PDP-8, I decided to set up a simple addition test for Arduino. First I formed an array of 16 bit integers - remembering that in the Arduino there is only sufficient RAM space for about 500 16-bit words. Exceeding this gives a risk of overwriting some of the stack, heap and system variables.

I then loaded up the array with random integers 

void setup()
  for(int i = 0; i <=500; i++)
  m[i] = random(0,65535);


The main routine would then add two of the memory locations together, working it's way through the array. The time taken for the 500 iteration function was calculated using the micros() function.

Results were as follows:

1. Adding a constant to memory    1uS
2. Adding contents of two memory locations into a variable   1.4uS
3. Adding  contents of two memory locations and storing back into a third memory location 1.6uS

So based on this, the Arduino is performing addition of  memory located operands at between 2 to 3 times the speed of the 1965 PDP-8.

However  - we should bear in mind that at 16MHz, the Arduino is executing approximately 16 instructions per microsecond.  Whilst an 8-bit add is a single cycle instruction, by the time we have used it within a 16-bit add routine, and involved a memory access, the Arduino is taking roughly a microsecond to achieve a common operation in a typical program.  

I then conducted the same test on the 72MHz STM32F103 board programmed using Arduino_STM32.

1. Adding a constant to memory    0.156uS    (6.4X faster)
2. Adding contents of two memory locations into a variable  0.294uS  (4.76X faster)
3. Adding  contents of two memory locations and storing back into a third memory location 0.32uS (5X faster).

Next was the turn for the 96MHz ZPUino - a softcore running in a Xilinx Spartan 6 - on a Papilio Duo FPGA board.

1. Adding a constant to memory    0.58uS    (1.72X faster than Arduino)
2. Adding contents of two memory locations into a variable  0.708uS  (1.39X faster)
3. Adding  contents of two memory locations and storing back into a third memory location 0.706uS (1.41X faster).

The skeleton Arduino code for these addition speedtests is available on this Github Gist

The results for the ZPUino were a little disappointing - bearing in mind it is being clocked at 6X the speed of the Arduino. However it is a stack based processor, which uses external RAM. The external bytewide RAM will slow down RAM accesses and perhaps C does not compile efficiently to its stack based architecture.

Whetstone and Dhrystone Benchmarks

One solution is to use standard benchmark code, of which there are several well documented programmes, designed to test the various performance aspects of the processor. These include:

Dhrystone  - an integer arithmetic benchmark
Whetstone  - a floating point benchmark
CoreMark - for multi-core processors
LinPak      - for Linux based systems

Dhrystone - a fixed point benchmark

The Dhrystone benchmark code - suitable for small microcontrollers is available here - however the Dhrystone caused some me difficulties in converting it to an Arduino compatible format - particularly because of the shortage of RAM on the ATmega328.

Fortunately, I was contacted by Magnus of Saanlima Electronics - with an Arduino friendly version. You will however need an Arduino MEGA - because the Uno does not have enough RAM to run this benchmark.


Arduino MEGA1260 board 16MHz

Microseconds for one run through Dhrystone: 78.67
Dhrystones per Second:12711.22
VAX MIPS rating = 7.23

72MHz STM32F103 programmed using Arduino_STM32 

Microseconds for one run through Dhrystone: 11.66
Dhrystones per Second: 85762.68
VAX MIPS rating = 48.81
I then ported it to ZPUino2.0  - and after a little fiddling got the following:
Microseconds for one run through Dhrystone: 37.95
Dhrystones per Second: 26351.79
VAX MIPS rating = 15.00

Whetstone - a floating point benchmark

The Whetstone test code adapted for Arduino by Thomas Kirchner is here
When run on a standard Arduino 16MHz Duemillenove the Whetstone produced the following result

Starting Whetstone benchmark...
Loops: 1000 Iterations: 1 Duration: 81740 millisec.
C Converted Double Precision Whetstones: 1.22 MIPS

On the STM32F103 board with a 72MHz clock

Starting Whetstone benchmark...
Loops: 1000 Iterations: 1 Duration: 19691 millisec.
C Converted Double Precision Whetstones: 5.08 MIPS

So the STM32F103 appears to be running at approximately four times the speed of the Arduino. This speed increase is dominated by the faster clock on the STM32F103, and not that the ARM processor is executing the compiled code any more efficiently than the AVR.

Whilst an indication of processor performance, the benchmarks are a somewhat artificial test, and the actual performance of one processor compared to another will depend on the application. Additionally, the manner in which the compiler interprets the C source code and efficiently converts it into the native machine language of the processor has an effect on the overall processing speed.


The 16MHz Arduino can execute real code at around 1.22 million instructions per second.

Moving up to a 72MHz STM32F103 ARM will give about a 5X to 7X speed advantage over the Arduino. A lot of this is down to the faster clock, and some down to the fact that double precision arithmetic will be easier (less cycles) on a 32bit processor than an 8 bit device

Soft core FPGA processors are interesting, but may be constrained by the use of external RAM and the restriction of an 8 bit external bus hen accessing multi-byte words. It must therefore be possible to improve their performance, with the used of internal (on chip) RAM.

Friday, April 24, 2015

One song - to the tune of another......

One Song to the tune of another....

It is said that any processor, given enough time, can emulate the operation of any other processor. With this in mind, this week I have been having a retrospective look at some simple tools to help with low level microcontroller hacking.

This week in the spare evenings,  I have written some low level tools to help me debug a J1 Forth processor - which is a softcore that runs on a FPGA.

In order to first understand the operation of the J1, I first used a simulator - so that I can try simple test programs - of only a few bytes, and single step through them to view the effect each instruction has on memory.

These screen shots have been created by a softcore procesor called ZPUino - which runs on a FPGA and produces an 800 x 600 VGA output.

My code is written in "Arduino" and is compiled to run on the ZPUino - a 96MHz 32 bit soft cpu.

The early version of this code can be found on this Github Gist

It has been written by way of a quick demonstrator of what is achievable with simple coded tools - and no way constitutes a finished design.

Thanks to Alvaro Lopez, Jack Gassett  @Gadget Factory and James Bowman @GameDuino for their support.

The memory dump window - where up to 1K 16-bit words are displayed in hexadecimal. May be individually highlighted.

Tools in the Toolbox

Here is a non-exhaustive list of what I think is needed to support new processor code development.

1. A graphical view of memory and key registers such as program counter, top of stack, stack pointer etc - each cell highlighted with a change in colour when its contents are changed
2.  A disassembled listing of the memory, showing the immediate area from which the cpu is executing instructions. A single step facility to execute each instruction in turn and view the changes to RAM and registers.
3. A model of the cpu emulated in software. Again - single stepping through code is essential.
4. An assembler. The means to type in mnemonics and data and have these converted to legitimate instructions. Produces an output file which may then be loaded into the RAM of the cpu - or the cpu simulator.
5. Ultimately, a higher level language, such as Forth, which may replace the low level assembler and provide an interactive experience with the processor.

A Historical Note

30 years ago, as a college student, it was commonplace to write machine code using the laborious task of hand assembly.  Processors were generally clocked at less than 5MHz and had a rich, 8 bit instruction set. Often it took several clock cycles to execute the simplest of instructions. Additionally, a lot of the processor's time was spent handling the graphics interface. Face it, 1980's were slow.

The most sophisticated tools for this were a pencil and a supply of paper - plus a databook that detailed the instruction set for the particular micro that you were coding for.

Op-codes were written down on paper in hex, and then using some form of hexadecimal input program, they would be entered into the RAM of the microcontroller. We quickly learned the trick of using a battery backed RAM, instead of an EEPROM for program development - and when your code finally worked, you would program an EEPROM.

Move on Up

As time goes by, tools become more sophisticated, and further layers of abstraction are put between you and the bare metal of the processor.

By the late 1980s, assemblers became available to the hobbyist community, and so you at least had the easier task of programming in standard mnemonics, rather than raw hex.  About this same time, I wrote a simple Z80 disassembler in Basic, which at least allowed you to get a crude listing of the code stored in RAM - showing the main instructions, calls, jumps etc.

These low level tools make the task of dealing with a new microcontroller much simpler, and so this week I decided that I would look at providing myself with a suite of tools to simplify the code development on the J1 soft core Forth processor.
Disassembler Window - bottom right allows instructions to be displayed in human readable Mnemonic format 

The J1 is the processor used on GameDuino, blown into a Xilinx FPGA.  It has a simple instruction set, which makes the task of assembly and disassembly somewhat easier.  It's also quite easy to simulate - or rather emulate, using another microcontroller.

I have decide to use the Arduino language to program up these tools.  Firstly it is very accessible, secondly it runs on AVR, ARM and FPGA processors -  so it has almost become a lingua franca for these various devices.

Close-up on disassembler window shows the address, instruction, mnemonics and any literal values.
The yellow highlighting at address 003 shows the current executing instruction - i.e. program counter.
My efforts were spurred on with the availability of 800x600 colour graphics running on the ZPUino soft core processor. This means that my Arduino code programs can have a decent colour graphical user interface - rather that just a serial terminal interface.

Additionally, I have bought a Classic Computing Shield from Gadget Factory - which in addition to the VGA interface, provides PS2 keyboard and mouse, microSD card and Atari style game controller ports to my Papilio Duo FPGA board.

So hopefully I will be all set to start developing in a usable computing environment.

The first task was to get the VGA graphics to provide a memory dump facility from the SRAM that accompanies the FPGA. This shows the memory address and the data stored at each RAM address. It's about as basic as you can get - showing 1K x 16 bit words on the screen at any time.

With the ability to display graphical text fields, in different colours on a VGA monitor, I decided that it was about time to  start on a new voyage of discovery - and to create a set of tools from scratch to help understand the operation of the FPGA softcore microprocessor.

Thursday, April 09, 2015

Exploring PianoForte - Part 0

The minimum build PianoForte - just 20 components
This is an update to a post from 9th April.

PianoForte is an experiment in hardware.  It is the combination of several ideas, using the latest wireless modules and hardware, in order to create a platform for developing new, exciting physical computing devices.

This post introduces the hardware and some of the design decisions needed to turn a concept into a working design.

Here are some key points about the PianoForte design:

1.  It uses a popular ARM microcontroller, capable of about 20 times the speed of an Arduino Uno.
2.  It's designed to be battery powered - for greater portability and flexibility
3.  It offers various wireless modules including WiFi, BLE and 433MHz low power FSK
4.  More GPIO pins, more memory, faster clock, better peripherals and huge possibilities.
5.  Builds on the vast Arduino ecosystem and community using the Arduino_STM32 extension to Arduino IDE
6.  Also highly compatible with Gordon Williams' Espruino - a javascript interpreter for the STM32Fxxx series of microcontrollers

That's why I'm excited about PianoForte.

PianoForte offers a stepping stone from Arduino into the rapidly expanding world of 32 bit ARM Cortex M3 and M4 microcontrollers.  It uses the Arduino_STM32 extension to the Arduino IDE - allowing you to write Arduino code for any of the STM32103xx range of microcontrollers.

These low cost STM32F103 ARM Cortex M3 micros have greater speed and a richer mix of peripherals than the Atmel AVR - which is now showing its age. The ARM chips offer:

1. 32bit processor
2. 4.5 times the clock frequency
3. 3 USART, 2 SPI and 2 I2C
4. On chip USB
5. Real Time Clock
6. 12 bit ADCs
7. 40 GPIO lines compare to 20 for Arduino Uno.

I have however pitched it firmly in familiar Arduino territory. This is still a microcontroller on which you can do "bare metal" programming and have direct access to the rich mix of peripherals offered by a modern ARM chip.  It's definitely not a Raspberry Pi equivalent or replacement - more of a souped-up Arduino, which uses the same Arduino IDE, language, libraries and shields.

In the last few weeks, I have designed and developed a prototype pcb as a means to test out some of the hardware features, in particular the wireless modules.  It's getting increasingly tricky to prototype with surface mount modules - so the solution was to bite the bullet and have a small board made that can accommodate the various options.

This first prototype is not perfect, I never expected it to be.  It has one or two easily corrected bugs, but will allow me to hone my ideas, and produce a board that is commercially manufacturable in volume. Over the next few weeks I expect to rationalise and simplify the design, to produce something that can be sold for about $25 to $30.

Lower cost ARM boards are available, but they lack the wireless options, the microSD, the Lithium Ion battery charger and the flexible boost converter.  It is the mix of these additional components which makes the board a lot more useful when it comes to exploring new ideas.

About Arduino_STM32

This is an extension to the usual Arduino IDE which makes it possible to write Arduino-like code which is then compiled for the STM32F103xx range of microcontrollers.

This simple extension opens out a wide range of new powerful 32bit ARM processors to the Arduino community.

Arduino_STM32 owes its heritage to the work done by Leaf Labs with their Maple and Maple-Mini dev boards. It has been further developed by a small team of unpaid enthusiasts - including Roger Clark and Bob Cousins.

Arduino_STM32 may be downloaded from Roger Clark's Github repository.

Update 23-5-2015

A couple of days ago, by happenstance, I rediscovered Espruino - a javascript interpreter for the STM32F range of microcontrollers.  I had seen the Espruino kickstarter back in September 2013 just when I was starting out my voyage of discovery with ARM processors. For some reason, I forgot all about it, until I was investigating Node.js prior to attending a NodeRED workshop.

The good news is that Gordon Williams javascript interpreter is very compatible with the Piano Forte board - and a few lines of js will have you blinking it's LED.

More about Espruino running on Piano Forte in a later post.

So, What makes a good Dev Board?

The Arduino was good in it's day. A simple 28 pin processor, with clock oscillator, reset circuit, power supply and programming interface connected. All of the 20 GPIO pins were broken out to SIL sockets - reasonably well arranged by function into Analogue and Digital pins.

This was a good clear arrangement, and the hardware abstraction layer, contained in the boards.txt file allowed the GPIO to be sensibly mapped to the physical pin arrangement.

That worked well for a 28pin IC, and the technique can easily be extended to ensure a clear programming model for a 64 pin IC.

Converting a fairly complex 64 pin IC into a much simplified programmer's model is a major part of producing a good dev-board.  Here's how I approached this.

A Minumum Setup

Every microcontroller needs a minimum setup in order to receive updated code and execute it. The ARM series of microcontrollers are provided with an in-built bootloader, which allows code to be programmed over a simple serial connection - using a FTDI or similar USB to serial adaptor.

The microcontroller needs the following support circuitry:

1.  Power Supply.   3.3V applied to all of the five Vss pins, and all of the Vdd pins connected to 0V
2.  Clock Oscillator - an 8MHz clock connected to the clock pins with 22pF loading capacitors
3.  Serial USART  - the Tx and Rx pins from the USB- Serial cable connected to PA9 and PA10
4.  Reset Switch  - connected to NRST pin with 10K pullup and 100nF reset capacitor.
5.  Boot Switch - The Boot0 line is normally pulled down with a 10K resistor - this switch pulls in up to VDD
6.  On the STM32F103 range of microcontrollers Boot1, (PB2) should be pulled down with a 10 K resistor.

Once these initial pin conditions are met - we have a minimal microcontroller system that can be programmed with a low cost USB-Serial adaptor cable.

The bootloader requires that Boot0 is high, when the mcu comes out of reset. This is one by pressing both the Boot switch and the Reset button, and ensuring that the Reset button is released before the Boot switch. This puts the board into Bootload mode - using USART 1 on PA9 and PA10 to communicate with the PC.

For completeness, I have added an LED to PC13 through a 470 ohm resistor, and a miniature speaker to PA5 via an NPN driver transistor.  This gives visual and audible feedback that things are working.

PianoForte  I/O Scheme

There's are 49 usable GPIO pins on the 64 pin STM32F103 package.  We need to create some sort of sensible programmer's model from all of these pins.

Some of the GPIO pins on the STM32Fxxx processor are best reserved for special use - here's my intention:

PA9        USART1 TX - used for bootloading
PA10      USART1 RX - used for bootloading
PA11      USB DM     - this is the USB D- signal
PA12      USB DP      - this is the USB D+ signal
PA13      SWDIO       - STlink programming/debug interface
PA13      SWCLK      - STlink programming/debug interface

PB2        BOOT1      - tie this low via 10K pulldown for reliable bootloader operation

PC13      User LED  A red LED in series with a 470 ohm resistor
PC14      32.768kHz clock
PC15      32.768kHz clock

So already,  10 of the GPIO pins have been assigned to a dedicated function.

Now lets look at the pins that have 12 bit ADC capability

On most of the STM32Fxxx range of microcontrollers, we find ADC inputs on PA0-PA7, PB0, PB1 and PC0-PC5  - so we can have 16 analogue input pins.

Once the analogue pins with ADC and DAC functionality have been separated out,  that leaves predominantly the digital I/O pins.  These have 5V tolerance, and to reinforce this capability, they should be placed away from the analogue pins that are only 3V3 tolerant.

Digital Pins

PB3 - PB15
PC6 - PC12

That's a further 21 pins that can be dedicated to GPIO/digital signal connection.

So if we tie up at least 4 or 5 of these for a SPI bus  - to communicate with a microSD card we have reduced the whole I/O scenario into a easy to remember arrangement of 16 analogues and 16 digitals.

A slightly daunting 64 pin microcontroller, simplified to 16 analogue inputs, 16 digitals and a handful of dedicated lines.

On the STM32F103 there are a few other signals in addition to the 48 regular PA0-PA15, PB0-PB15 and PCO-PC15 GPIO ports. We need to account for these signals and use them appropriately.

PD0   - Osc In   Connect an 8MHz crystal
PD1   - Osc Out  Connect an 8MHz crystal

PD2   - an unused GPIO line perhaps another User LED or a chip select for a SPI peripheral.

NRST   - the Reset line - active low
BOOT0  - pull high prior to reset to enter the serial bootloader state.

In addition to the signal pins, we have 5 pairs of power pins, which need to be connected to Vcc and 0V  (VDD and VSS).

The VDD and VSS pins should be stitched through to the low impedance power planes and decoupled/filtered with a closely coupled pair of capacitors (10uF and 100nF) and a 1Kohm 300mA ferrite bead.

There is also the Vbat pin - for battery backup. This needs to be connected to a supercapacitor.

A minimalist board could be made to support this about 3.0" long x 0.9" wide.

Additional Features Added to the PianoForte Design.

PianoForte is much more than the minimum feature set.

1. Provision for ESP8266 WiFi, HM-11 BLE and RFM69CW low power 433MHz wireless
2. LiPo battery and charger interface
3. Boost converter for powreing down to 0.6V
4. microSD connector
5. As a Pi-HAT can be plugged into a Raspberry Pi as an I/O coprocessor

Exploring PianoForte - Part 1

A minimum build PianoForte - under test with a STM32F103CB

PianoForte is an experiment in hardware. To create from scratch a small pcb design that brings the best qualities of recent open source hardware.  Arduino-like, with its familiar programming environment and language, plus the advantage of much more speed, more memory and better peripherals. All on a small battery powered pcb with up to 3 wireless options available!

In the last few days I have built up a couple of PianoForte boards in order to experiment with the hardware, write some code and generally rationalise the design.

The first board was fitted with a STM32F373 - which is an ARM Cortex M4 microcontroller with floating point unit, and the triple 16-bit ADCs. However, in order to write code for this, I had to fire up the CooCox COIDE - which is fairly hardcore programming, without the help of the familiar Arduino language, programming environment and libraries.

So in order to progress, the next  pcb was fitted with a STM32F103CB.  This is a Cortex M3 mcu with 256K of Flash and  48K of RAM. It also has the added anvantage in that it can be programmed using the Arduino_STM32, which is an extended version of the Arduino IDE. It's ADCs are only 12 bit - but that's still 4 times the resolution of the Arduino.

Details of Arduino_STM32 and links to Roger Clark's  Github repository can be found here

When introduced the Due, they had to extend the IDE to include the GCC compiler tools for ARM (as the Due uses an Atmel M3 ARM).  They created a programming framework that would allow the incorporation of other ARM based boards into the Arduino ecosystem.

So now the range of STM32F103 microcontrollers, can be programme using the Arduino IDE - which opens these ARM processors up to a whole new generation of programmers.

Programming PianoForte

There are several options available to us to get code into the STM32 chip on PianoForte.  In this post I will deal initially with the most basic.

ARM microcontrollers come from the chip manufacturer with a preloaded bootloader.  This can be programmed via a serial UART connection, using either proprietary or open source loader tools.  The open source tool used by Arduino_STM32 is called STM32flash.

To use it, you first have to put the ARM into serial bootloader mode. This is done using a dedicated line on the processor called "Boot0".  In the photograph above, the left hand side push switch is connected so that it pulls Boot0 high when pressed.  Provided that Boot0 is high when the processor is released from reset (releasing the right hand switch), it will enter serial bootloader mode.  It then communicates with the STM32flash program, and the code is loaded in a few seconds.

To use the serial bootoader, you need to have access to the USART1 Tx and Rx pins - and more specifically access them through ports PA9 and PA10.  On PianoForte, PA9 and PA10 have been brought out to a FTDI programming header, which is the connector at the bottom left with the FTDI cable plugged in.

This is the simplest means of programming ARM devices, but you will need a USB to Serial programming cable or adaptor pcb - but these are now available very cheaply, and are very handy for debugging other projects.

The ARM mcu may also be programmed over USB - using a program/technique called Device Firmware Upgrade or Dfu. This will be covered in a later post.

Additionally you can load a program to the ARM using the STlink - which is proprietary programming/debug connection, which uses a couple of pins on the processor for clocked serial data transfer.  For this you will need a ST Link programmer - but these are supplied on every STM Nucleo board  - an mbed compatible dev board  for about £10.  I have included a dedicated ST Link header on PianoForte for this purpose.  It's the located at the top left of the pcb.

Powering the PianoForte

PianoForte has a fairly flexible powering scheme based on the following options.

1.  Plug it into the GPIO header of a Raspberry Pi - where it will pick up +5V and 0V from the Pi.
2.  Plug a powered USB cable into the miniB USB connector. The PianoForte will run off the USB 5V supply. This can be from a PC or just a USB power supply.- plugged into the FTDI header.
3.  From a FTDI cable or similar USB to serial adaptor
4.  A 3.7V Lithium polymer cell - such as the 18650CA
5.  Via  a dc source  (0.6V to 5V max) on the Vin pin of the power header
6.  From two alkaline AAA cells plugged into a Keystone battery holder underneath the pcb.

The next post will cover the board features and running some test sketches on PianoForte, loaded from the Arduino_STM32 programming IDE.

Sunday, April 05, 2015

Arduino - Teenage Strife

It's probably common knowledge that all is not well in the Arduino household.

A rift has opened up between the original founders, who started and their long term hardware builder, who has now registered

These two organisations will continue along divergent paths, whilst their lawyers fight it out. - as a hardware supplier, were responsible for introducing a lot of the new hardware designs, such as the Due and the Yun - which are a move away from the earlier Atmel AVR boards.

In general, hardware suppliers need to keep ahead of the competition, because in the end, everything design gets copied and the market gets flooded with cheap imports from the Far East. So it's understandable that, want to put themselves in a position where they can innovate, and take on new product designs from other design houses.

Meanwhile, some of you will have noticed that are spewing out new versions of the Arduino IDE, almost on a weekly basis.  We quickly went from 1.60 to 1.63, and if you are a Due user or are making use of the GCC ARM compiler tools, you will found that you are somewhat left out in the cold.

Fortunately, have dragged themselves out of this quagmire of incompatibility , and released their own version 1.70. This continues to support all the newer board and processor variants, and currently looks like the best way forward. At least until the dust settles in the Italian law courts.

Saturday, April 04, 2015

Introducing PianoForte

A partly assembled PianoForte pcb before adding the wireless modules.


In a couple of previous posts I commented how many modern electronic products are built from a series of building blocks - generally consisting of a microcontroller, a power supply and a communications interface - these days, usually wireless.

If you put these three subsystems together onto a pcb you will then have the basis for creating some interesting devices.

Unfortunately, most dev boards don't tend to give you all these elements, sometimes you just get the microcontroller and power supply, but little or no thought has been given to the communications interface - which is of course how you get the data in and out.

So in early March, I tried to address these shortfalls, and come up with a dev board that delivers more in all three areas.


The STM32F373 was the obvious choice.  It's a 32bit ARM M4 Cortex part running at 72MHz. One of the attractive features is that it has three separate 16 bit ADCs  which are ideal for analogue sensing or energy monitoring applications.

The micro is in a 64 pin quad flatpack, making it relatively easy to use, and providing about 48 lines of GPIO and peripherals.

Some of the features:

3 USARTS - up to 3Mbaud datarate
3 SPI interfaces
2 I2C Intefaces
13 Timers for PWM generation and quadrature decoding
Real Time Clock
Floating Point Unit
72MHz maximum clock frequency
48 lines of general purpose I/O
12  12bit ADC multiplexed channels
3  16 bit Sigma-Delta ADCs for high resolution analogue signal measurement
2 DAC channels
Full speed USB
micro SD card holder
Battery powered either from LiPo or alkaline cells
Three different wireless interfaces to pick and choose from,  WiFi, BLE and 433MHz FSK

The GPIO is 5V tolerant - so there is little risk of damaging anything in a mixed voltage environment.

Power Supply

The PianoForte board uses a low cost boost converter at the heart of its power supply circuit.  It allows very flexible powering of the circuit, Not only can it accept a 5V supply - from USB or FTDI cable, but it can be battery powered from a 3.7V LiPo cell or even a couple of AAA alkaline cells. The boost converter will actually run off a single 1.5V alkaline cell, and run all the way down to 0.6V. This gives the freedom run any of the wireless module options, from battery power.


There are a variety of wireless communication options available today - and these generally take the form of small modules.  PianoForte is designed to accept three of the currently most popular wireless options - depending on application.

WiFi - we have a connector onboard to accept the popular ESP8266 WiFi module. This can act both as an access point (AP) or station (STA). It communicates with the microcontroller using an AT-command set over a USART serial connection.

Bluetooth 4.0.  Bluetooth Low Energy (BLE)

This is used on all smartphones, both iPhone and Android.  It provides a direct way for a smartphone to communicate with the PianoForte, with the possibility of uploading new firmware over the air.  Many BLE modules are available cheaply from China - and PianoForte uses the popular HM-11 module.

Low Power Wireless - this is for longer distance communication - up to 250m outdoors, 30m indoors.

PianoForte uses the popular RFM69CW device. Using either 433MHz or 868MHz ISM band, this has the capability of better propagation through buildings at lower power than any of the 2.4GHz devices. It is included to make the PianoForte compatible with popular open source energy monitoring devices.

PianoForte has two intended modes of operation.

1. As an analogue and digital I/O co-processor for the Raspberry Pi.

Let PianoForte handle all the real world acquisition and control stuff whist the Pi runs the high level apps.  The Pi communicates with the PianoForte via it's serial UART, using simple serial commands. Set PianoForte running with, for example a 16 bit, 3 channel analogue data acquisition task, and poll the data from it when convenient.

2. As a battery powered, stand alone wireless node.

Pianoforte is capable in its own right of running some fairly sophisticated measurement and control applications, and being battery powered and wireless is not tied to a conventional USB lead or 5V power supply. It can run on dc voltages down to 0.6V, as a result of it's on board high efficiency boost converter.

As this is the start of a series of posts, more details will follow in future posts.

Monday, March 02, 2015

Arduino programs ARM

OK - so for the last couple of days I have been waxing lyrical about a new extension to the Arduino IDE which allows it to program the STM32F1xx range of Cortex M3 microcontrollers.

This afternoon, I built up one of my ARMiGo boards with a STM32F103 ad managed to program it with Blinky - entirely from Arduino 1.60 - augmented with Roger Clark's Arduino_STM32.

Quick Start Guide.

1. Download the latest stable Arduino IDE from here.
2. Download the Arduino_STM32 from Github - here
3. Unzip the folder and place in the Hardware folder of Arduino 1.60
4. Make sure you have dwnloaded any drivers - eg ST-Link you might need for board programming.
5. Restart Arduino so that the changes in the Hardware folder are incorporated

When you select the tools menu, you will find that a load of new board options are available at the bottom of the board list:

Now I am using a ST Link programmer (off  STM F103RB Nucleo board) - so I chose the last option STM Nucleo F103RB (STLink)

Sunday, March 01, 2015

Ideas into Action

Last year, I backed a good friend's Kickstarter, for the Mirobot - a small open source, WiFi controlled turtle-like robot to help teach kids to code. It was well received, and well over-funded, and hopefully will be the start of a range of educational technology kits.

During the development of Mirobot, it became clear that a traditional through-hole pcb design, incorporating a DIL-socketed ATmega328, was not the way to go - especially when you could buy a complete Arduino Pro Mini, from China, for less than the cost of the microcontroller over here.

It also became apparent that there were a lot of interesting WiFi and BLE modules - available from China, at very low cost, that really meant that designing your own, was a non-starter. Devices such as the ESP8266 and the HM11 BLE module - that were now made accessible due to an easy to use serial command interface.  Developments such as these are changing the way in which we put hardware together. We buy a bunch of well engineered building blocks, and we stick them together like LEGO.
And just like LEGO - these building blocks are becoming more sophisticated (but cheaper) year on year.

The great thing about LEGO is it's simple User Interface.  Those studs and holes make it so easy to put pieces together - that even a toddler quickly masters the skills required. Well perhaps digital hardware is becoming much like this - but with the one advantage, that those studs and holes can be manipulated in software code to make things fit, in entirely new ways. It's like having an endless supply of Sugru, or 3D printer - from which to mould or print your own LEGO creations.

LEGO can also be used to convey somewhat abstract concepts in computing.  The "one by one" block is the LEGO equivalent of the bit, and by putting these together we can make more interesting blocks - such as the "four by two" or the "eight by one". I'm going to end the analogy here - before I get distracted thinking about teaching binary maths and logical operations in LEGO - that's for another time.

Building Blocks

Every modern digital product is based around a microcontroler, one or more communications interfaces and a power supply.  Indeed, solving how you get the power in and the data out remains one of the most creative challenges to the digital product designer.

So for any product, you have the following common blocks

Microcontroller block
Communications block
Power Supply block

Look at any product - say the Arduino Duemillenove or Uno, and you can clearly identify these parts on the board.  In the case of the Duemillenove, the parts are quite separate, there's the ATmega328, the FTDI chip, and the 5V regulator. The rest is just a few connectors - so that the whole lot plugs together in a useful way.

For those familiar with Arduino - they have learned the functionality of each pin, they know it's limitations, and they know where to find (or write) the code to make that pin work in the desired manner. Learning the capabilities of a 28 pin microcontroller, has been simplified by the Arduino ecosystem - but can easily be extended to highlight the capabilities of microcontrollers with 100 pins or more.

The combination of a hardware abstraction layer - which removes the need to understand, at a register level, the internal structure of the processor, plus a couple of layers of firmware abstraction which lifts the coder well above the machine language of the mcu - mean that the user can rapidly make progress with new creative ideas - without getting bogged down in the intricacies of the microcontroller architecture or machine language. This is what I like about Arduino, and why I think it has made microcontrollers  much more accessible to a whole new generation of programmers.

However, the 8-bit Arduinos have their limitations, and the IDE has been widely criticised - but as with all old friends, you learn to forgive their shortcomings and foibles.

Improving Arduino

For many newcomers, Arduino will be their first introduction to physical computing devices and compiled C and C++ code.  There is nothing fundamentally wrong with Arduino code - it's just a tool to get a job done.  The current IDE does not encourage good programming practice, splitting the task into multiple firmware modules, nor does it allow the user a means to debug or single step the code to identify where problems lie.

It does however have a huge user base, a massive community following and a vast resource of libraries. These are its strong points.

Recent developments have ported the Arduino "language" to a wider range of microcontrollers - including ARM chips from Atmel (Due), Freescale (Teensy) and STMicroelectronics (Maple). Additionally the Arduino language has been ported to FPGAs - such as the Xilinx Spartan 6 - on the Papilio Duo board - where it runs of a 100MHz soft-core - the ZPUino.

These are all great developments, and keeping the Arduino philosophy current and branching out into a wider range of hardware targets. We will perhaps reach the point, where chip suppliers offer their own versions of the Arduino language reference - so that digitalWrite() works on any microcontroller you happen to wish to use.

State of the Nation

"Procrastination got me to where I am today...."

There has never been a better time for the technically creative hobbyist. New devices are appearing almost daily and prices are constantly being eroded.  This is good news for the enthusiast, but bad news for the people who want to make a living out of selling hardware.  This became ever so apparent when I spotted yesterday that my local PC World were selling Raspberry Pi's for just £19.99.

Yes - I realise that they have just dropped the price of the Model B+, and A+, now that  Model 2 is available, but I never thought I'd see a big box retailer stock the Raspberry Pi, this side of hell freezing over. Perhaps I should get out more. More worryingly, is that I think I paid about £20 for my first Arduino (a Chinese Freeduino copy), and even more disturbing is that if you buy the official Uno R3 from the online store - it will still cost you 20 Euros.  But then, no-one is daft enough to buy the official ones, from the official store - are they?

So hardware prices are tumbling, and this is bad news for people that run online hardware shops, trying to maintain a living, when customers just trawl Ebay or TaoBao for the cheapest. It's an exact parallel to what is happening in the High Street - and why we are struggling to remain a nation of shopkeepers, let alone a world leading industrial manufacturing powerhouse. Those days are over.

So in order to remain afloat in the hardware business, you have to keep inventing the next great thing, or have something so unique about your product, that everyone flocks to it - religiously, and you can afford to keep your margins ridiculously high.

So that's where we are at right now.  Great for tech consumers, not so great for UK GDP.