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


EagleCAD Layout


The Solution






The Design.




The Sting


The Worm








The freshly minted board back from Ragworm




Initial Testing.









From Ragworm - with Love :)



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()
  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....










Tools in the Toolbox



A Historical Note




Move on Up











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.



Here are some key points about the PianoForte design:


That's why I'm excited about PianoForte.



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.





About Arduino_STM32




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

Update 23-5-2015



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

So, What makes a good Dev Board?





A Minumum Setup


The microcontroller needs the following support circuitry:





PianoForte  I/O Scheme



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


PC14      32.768kHz clock
PC15      32.768kHz clock


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



Digital Pins

PB3 - PB15
PC6 - PC12





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


NRST   - the Reset line - active low





Additional Features Added to the PianoForte Design.

PianoForte is much more than the minimum feature set.

2. LiPo battery and charger interface
3. Boost converter for powreing down to 0.6V
4. microSD connector

Exploring PianoForte - Part 1

A minimum build PianoForte - under test with a STM32F103CB








Programming PianoForte








Powering the PianoForte


3.  From a FTDI cable or similar USB to serial adaptor
4.  A 3.7V Lithium polymer cell - such as the 18650CA


Sunday, April 05, 2015

Arduino - Teenage Strife







Saturday, April 04, 2015

Introducing PianoForte

A partly assembled PianoForte pcb before adding the wireless modules.









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
2 DAC channels
Full speed USB
micro SD card holder
Battery powered either from LiPo or alkaline cells


Power Supply





Bluetooth 4.0.  Bluetooth Low Energy (BLE)




PianoForte has two intended modes of operation.



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



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.