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.

Background

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()
{  
  Serial.begin(115200);
  
  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.

http://www.saanlima.com/download/dhry21a.zip

Results:

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.


Conclusions

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

https://gist.github.com/anonymous/4f45827b32a1fc66db27

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  http://www.espruino.com/

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

PA15
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

http://www.rogerclark.net/stm32f103-and-maple-maple-mini-with-arduino-1-5-x-ide/

When Arduino.cc 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 Arduino.cc and their long term hardware builder, who has now registered Arduino.org

These two organisations will continue along divergent paths, whilst their lawyers fight it out.

Arduino.org - 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 Arduino.org, 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 Arduino.cc 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 Arduino.org, 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.

Introduction

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.

Microcontroller

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.

Communications

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.




Pushing Arduino Further

Every programmer desires to surround themself with a familiar programming environment which allows smooth and efficient code development, without having to constantly struggle with the foibles of the tool chain.

About 15 months ago, when I first got started with the STM32 series of ARM microcontrollers, I found the CooCox CoIDE - a free/open IDE based on Eclipse and GCC. Within about a week, I had mastered the complexities of the STM32 peripherals sufficiently enough to allow me to blink a LED and print characters to a terminal. It was hard work, dealing with an unfamiliar environment, but once over the initial hurdles, my rate of progress increased significantly.

During that time, I thought that it would be a whole lot easier if these newer microcontrollers could be programmed within the familiar Arduino environment - and shortly I found the Leaf Labs Maple board, with their version of Arduino which ran on an STM32F103. Unfortunately they had abandoned developing this product further for Windows, which was a disappointment, for us mortals that have yet to discover the joys of Linux.

Last summer, I had a student intern join our company, and I quickly had him up to speed developing a product on the ATmega328 and coding using the Arduino IDE.  By September, he had sufficient experience of Arduino, that we progressed onto mbed so that he might develop a product based on the STM32F103.

The beauty of mbed is that it allows rapid progress, and when used with the very low cost STM Nucleo boards, within a few days we had a working prototype of a current and temperature monitoring system for a dc motor drive.

However, neither CooCox or mbed really have a Cinderella fit into the "Arduino Slipper", so it was to my delight that I learned about Bob Cousins and Roger Clark's work on Arduino_STM32.

Roger's Wiki describes the Arduino_STM32 project thus:

Arduino STM32 adds the ability to develop for STM32F103 based boards, including the Maple and Maple mini using the Arduino 1.6 IDE
There is also experimental support for STM32F3 and STM32F4, however code for both of these devices is in early stages of development / porting, and only the STM32F1 is close to full support for the Arduino 1.0 API (and mostly compliant with the Arduino 1.6.x API).
With Arduino_STM32, you now have the familiar Arduino development environment, but for a faster, more capable 32bit processor, which is available in a wide range of standard packages, with a choice of peripherals and on-chip resources to suit the application and budget.
I realise that Arduino have long since moved into 32bit ARM territory with their Due board - but do I really want to base my designs around a processor that costs £8.33 in 1 off.  Admittedly - as with all Arduino products, there are plenty of Chinese rip-offs of the Due board - starting at £8.00.
I really think that Arduino have backed the wrong horse with their Atmel ARM M3 offering, and will be losing out to STM32 based development boards such as STM's own Discovery Boards, and their Nucleo series of boards that work within the mbed environment.
It is however encouraging to see that talented code developers are pushing the envelope of Arduino, and making it available to a wider range of microcontrollers.
If you want a no-thrills, very low cost, breadboard friendly dev board for your next project - consider the likes of these STM32F103 based boards from China - yours for a couple of pounds.








Sunday, February 22, 2015

Heating Controls - There has to be a better way

Every year, around this time, I get interested in improving my central heating control system. With time off work, and heating being very important over the Christmas break, it's easy to start thinking that there must be a better way to improve the average home's heating controls.

UK homes, are by European standards, very poorly insulated and the average heating controls are very primitive. This combination makes for poor heating efficiency, and in times of rising fuel prices the cost of heating a UK house starts to get expensive.

A basic heating controller consists of little more than a timeswitch and a room thermostat. Very often the thermostat has been located in the hall, and often close to a radiator. This is the worst possible arrangement. Nobody spends much time in the hall, and as soon as the hall is at the set temperature, the heating will turn off - often leaving the other rooms of the house poorly heated.

The thermostat should be located in the room that you spend most time in, generally the living room, and it should be located at a suitable position and height to give an accurate reading of room temperature, free from draughts and the direct effect of any heat sources. If you live in an older house with solid brick walls, the thermostat should not be fixed to an outer wall - as these can be colder than the rest of the room, or an internal wall.

With the advent modern wireless devices, it is now common to have a wireless thermostat.  This makes it possible to sit the thermostat in any convenient position, and if you spend a lot of time sitting on the sofa in winter, then having the thermostat on a coffee table, or low bookshelf is a convenient and practical place to put it.

Thermostats are becoming more sophisticated, often with the timeswitch function built in. These combined units are called wireless heating controllers and are generally battery powered - however they perform the same basic function, of turning on the boiler at a time when heat is demanded.

I've had a wireless thermostat for about the last 8 years, since I put in a new boiler in 2005.  It's a simple device, by Drayton, and every 15 seconds sends a wireless packet to a receiver device, the packet corresponding to either a "boiler on" or "boiler off" request. As a safety feature, the receiver will automatically turn off the boiler if a valid packet is not received for a given time period. This is to prevent the boiler being left on if there is a block in the wireless signal, or if the batteries in the sender unit are exhausted.

The Drayton unit was easy to hack, and it was just a case of replicating the two boiler control packets at the right baud rate, using an ON-Off_Keyed (OOK) 433MHz transmitter, and the Drayton receiver was easily fooled into thinking that it was seeing packets from a legitimate Drayton thermostat. This quick hack has served me well, and I have had an Arduino controlling my heating since Winter 2009.

However, in the last couple of years, there have been some great advances in open source hardware, and with new devices available, it's time to revisit the home heating arena, and see what can be done to improve the system.

As heating fuel costs rise by some 10% per year, an external insulation is not really an option right now, the only way to reduce bills is to have the heating on for less time.  This can be done by a combination of the following means:

1. Turning down the thermostat,
2. Reducing the time of the heating periods,
3. Heating less rooms - or adjusting TRVs to lower individual room temperatures
4. Not heating the water unless you really need it, and only as hot as you need it
5. Limit the heating in milder weather
6. Make small lifestyle changes to help reduce heating demand

Over the Christmas break, or at weekends and other times of high home occupancy there will be noticeably different demands put on the heating, compared to normal workdays where the house is seldom occupied during the day.  However, I found that when I was working from home for long periods between 2003 and 2009, it was easier to maintain a better control over the heating and minimise gas consumption.

In older houses, it is often better to keep them heated at a low temperature than cycle the heating on and off twice a day. Once the fabric of an older house has cooled down, it takes considerable heat to get it back to a comfortable temperature.

So what features would make a better heating controller?

1.  User friendly graphical display with simple user interface
2.  Bath Boost - heats just the hot water tank and tells you how long it will take to reach temperature.
3.  Comfort Indicator - RGB LED lets you know if your room is in the comfort zone.
4.  Simple button interface  "Increase Comfort"   "Reduce Cost"   - the choice is yours
5. Link to remote web interface

Not all of these requirements are easily met with one device, and so a practical system is likely to be based around two or possibly three modules. This modular approach allows the basic system to be set up first, and then further sophistication added later, if desired.  I anticipate a system with three main devices:

1. A wireless operated relay unit to switch the boiler and any motorised valves for selecting heating or hot water or both.
2. One or more wireless thermostats located in the main rooms. One will have a graphical display and user interface.
3. A web interface for remote monitoring, control and update of the time and temperature program.

The simplest system consists of the wireless thermostat and the wireless relay unit. This is the equivalent of the most basic of commercial systems, but will be lacking in any real user interface.

The next level would be to replace the single wireless thermostat with a combined graphic display unit with user interface. The interface would be limited to a few buttons, so without an elaborate menu system might prove a little tricky to program.

The top level system would include a web connected microcontroller, providing a browser based user interface and full functionality for programming, remote control and monitoring. One possible, and popular candidate for this would be the Raspberry Pi - fitted with a suitable wireless interface so that it can communicate with the thermostat and the relay board.

The Hardware.

The open source hardware community is good at coming up with useful building blocks from which to construct a better heating controller. Central to this is a proliferation of low cost wireless enabled hardware, usually based on Arduino clones.

One particularly well matched unit is the GLCD module from openenergymonitor.org  This is an Arduino compatible backlit LCD Graphic display fitted with a temperature sensor, LDR light sensor, 3 user buttons, red-orange-green LEDs and a RFM12B wireless device - compatible with the JeeNodes library.  This will form the basis of the User Display.  It can be located in the living room, in a suitable position to act as the thermostat, temperature display and user interface.

Secondly, we need to replace the existing time-clock/controller with a pair of wireless controlled mains relays. These allow the boiler, circulation pump and motorised valves to be switched, depending whether heating and hot water are needed.

This requires a special relay board to be designed - an early draft layout of this is shown below:


This board is still in final design stage, but is expected in a month or so.

It provides three mains relays, and a simple button and LED interface - for local manual control of the relays.

Additionally it can support a variety of temperature sensors - including thermistors and DS18B20 one-wire sensors.

It has wireless module and real time clock, and will accept a variety of microcontrollers, including the ATmega1284 and the RFMPi69 module from Open Energy Monitor.




Useful Hardware Helper Functions

As microcontrollers continue to offer ever increasing performance and overwhelming arrays of sophisticated on-chip peripherals, the task of getting an unfamiliar mcu up and running may at first appear very daunting.

One approach is to use a small library of useful helper routines, which allow you to achieve the basics, and confirm that the hardware is indeed working.

Most microcontrollers, these days come with some form of in-circuit serial programming capability, generally incorporated into the IDE - which makes loading a hex file into flash, quick and easy.

Every microcontroller needs a minimum hardware support system, consisting of a power supply, a clock oscillator and reset circuit.  It's also a very good idea to make a serial communications (UART) port available - and the standard 6 pin "FTDI" USB cable connection, makes a very simple way of both powering and communicating with the fledgling target hardware.

For decades a program to print "Hello World" was normally the first program to be written for any new system, but for the microcontroller, turning on and off a LED connected to a digital output is often the best way of proving that there is indeed life in the target board.

This involves writing to two of the on-chip registers.  Usually one defines the direction of the port lines - whether they are configured as input or output - sometimes called the Data Direction Register. The second is the Port Register itself, from which the port data can be written to or read from.

Arduino effectively deals with the low level register interaction with the pinMode, digitalWrite and digitalRead functions - and the equivalent of these are needed in your armoury for whichever micro you are dealing with.

The ability to change the state of an output pin, when entering or leaving a block of code, provides a simple but effective debug method. I often use an oscilloscope to check for changes of pin state, but a LED or even a small speaker could provide an indication of pin activity.

With high clock rates, code execution speed can be very fast - even when writing in a high level language such as C.  Some means of introducing program delays is needed to slow things down to a more sensible speed.  The simplest delay is a for loop, and by executing a for loop multiple times, delays of some microseconds can be achieved.

Suitable nesting of the microsecond delay loop can be used to achieve millisecond delays, but it should be noted that these are blocking delays, and the micro cannot execute any other task whilst in the middle of a delay.  They are fine for initial debug, but generally should not be used in real code. As most microcontrollers have counter timer peripherals, these can be used to provide system tick or millisecond counting, which can be used later on for non-blocking delays and other task timing functions.

With a controllable delay and the means to change the state of an output pin, we are now in the position to flash an LED - and this is the classic "Blinky"  popularised by Arduino.  However, with time-controlled I/O operations it is possible to write functions to provide "bit-banged" serial communications, and this was often done where there was no on-chip UART provided. Bit-banging is a simple but powerful technique and can be used to communicate with shift registers or even SPI devices.

So with the means to provide serial output, we are close to sending characters and numerical output to a terminal program.

The simplest serial operation is to send a single ASCII character to a terminal - and in C this is generally called putchar.  Using putchar with characters from an array, allows operations such as memory dumps to be performed and even simple file transfer.  I often combine putchar into a function I call printnum, which provides the means to send an integer number to a debug terminal.

As most microcontrollers have an on-chip UART, it's fairly simple to write a version of putchar to send a character to the USART transmit register.  To avoid embarrassment, it's best to check the UART Tx status flag first, to ensure that the UART has finished sending the previous character, before the next is loaded.


The complementary function to putchar in C is getchar.  This reads the UART Rx register and returns any character that may be present in the Rx register. Once again the status flag should be read to wait for the character to be clocked in, before the Rx register is read.

The story so far....

We now have a small collection of 8 routines which will allow us the basis of input/output, timing and serial communications:

pinMode
digitalWrite
digitalRead
delayMicroseconds
delayMilliseconds
putchar
printnum
getchar

These routines can be considered the fundamental building blocks of any high level application as they are the ones that interact with the peripheral registers at the lowest level.

With these in place, others can rapidly be implemented to handle other peripheral functions that might be present such as ADC, Timers, SPI etc

analogRead
pwmWrite
spiRead
spiWrite

And a very useful millsecond counting function millis() will help immensely with programing time-keeping tasks and implementing non-blocking longer delays.



Big Computer -Little Computer

Early in 1963, a  couple of engineers from the recent technology startup company Digital Equipment Corporation (DEC), drove up to Ontario, Canada to visit a nuclear science laboratory at Chalk River.

The scientists at Chalk River wanted a custom digital control system to monitor a nuclear reactor and pass data back to their mainframe computer. The DEC senior engineer, Gordon Moore, realised that rather than building a custom piece of dedicated equipment for the Chalk River Labs, the job could be done much more easily with a very small programmable computer, and so the minicomputer was conceived.

The PDP-5 was a revolutionary design, and a champion of minimalist digital design - yet it still occupied 2 full sized equipment racks - as can be seen from the photo below.

What  the PDP-5 offered for the first time was an affordable computer, and at $50,000, it was a lot cheaper than it's nearest competitor. It was cheap enough to use for scientific monitoring, and as it was fully programmable - could be applied to many different tasks. It could also be used as a data source for a larger mainframe, allowing the mainframe to get on with other tasks whilst the PDP-5 collected data.

This was one of the first examples of what I'll call Big Computer -Little Computer - a combination two machines of widely differing sizes connected together, in order to make a more overall flexible system.

The PDP-5 was by today's standards a very simple machine. In fact a $10 Arduino is many times more powerful than the PDP-5. But, as the predecessor of the renowned PDP-8, which using an instruction set based on that of the PDP-5, launched in Spring 1965, the minicomputer revolution. This led to the start of the microcomputer revolution, about 10 years later, in December of 1974 with the launch of the Altair 8800. The rest, as we say, is history.

PDP-5  c 1963

The Big Computer - Little Computer concept has been exploited many times as a means of achieving functionality that exceeds the "sum of the parts".

Recent Examples.

In October 2011, ARM Holding announced their big.LITTLE heterogeneous computing architecture where relatively low power smaller cores are coupled to larger, power hungry devices, to give an architecture that can respond efficiently to dynamic changes in computing load, than just clock frequency scaling of the larger cores could achieve.






The PDP-8: A lesson in longevity

The PDP-8 was launched in March 1965 and was produced in various forms for the next 15 years, each time benefiting from technological advances and cost reduction.

Now as we approach the 50th anniversary of the PDP-8, there is still much to be gained from studying it's simple architecture and instruction set.

The PDP-8 was the immediate successor to the PDP-5 (1963), DEC's first 12 bit minicomputer. As such it ran the same instruction set,  but more than 5 times as fast. First a little history of the PDP-5.

The PDP-5 was originally conceived as a "Digital Controller", and even a week before it's launch it was called the DC-12. In a mad rush, the management at DEC decided that it was a real computer, and designated it the PDP-5. They spent the week changing all their marketing literature to reflect the name change.

The PDP-5 was intended to be a "small computer" for industrial monitoring tasks, which was to be connected to a larger mainframe, originally the 18 bit PDP-4.   This combination of a small computer, acting as an I/O handler for a larger machine was first developed by Seymour Cray in 1960, with the 12-bit CDC 160. Inspired by the CDC 160, the engineers at DEC decided to design their own small, 12 bit computer.

For a flavour of what it was like to work with a 1965 vintage PDP-8, I watched the excellent videos from the National Museum of Computing, based on their restored PDP-8. I later spent a great Sunday afternoon last summer, looking at the real PDP-8 at the Museum in Bletchley.

The architecture of the PDP-8 has been widely studied, copied, and implemented in various technologies from 7400 TTL gates right through to high speed FPGA designs, written in VHDL or Verilog.

Although originally built using discrete transistor and diode logic, using the standard logic modules DEC had developed in the late 1950's, as time progressed, and technology improved, the PDP-8 was re-implemented several times, each time getting smaller and cheaper.

Inspired by the simplicity of the early 12 bit designs, I pondered for a while how to make the essence of these machines more accessible to the enthusiast or hobbyist.

I'm not a FPGA engineer, so I decided that I would make an exploration of the PDP-8 architecture and instruction set  and implement it on a modern hardware platform by way of an emulation based on the popular Arduino.

Instruction Set.

Wikipedia has a good description of the PDP-8 Instruction Set, and it shows just how much could be crammed into a very simple design.  Unfortunately, the instruction set has very few op-codes, with only 8 basic instructions, - so if you wanted to do anything clever, it had to be done using some fancy tricks and multiple instructions. This led to the use of macros (multiple instructions), for some of the operations that today would normally be handled by a single instruction.

Later versions of the PDP-8 had an Extended Arithmetic Element (EAE), which was an add-on extra that provided multiply, divide and other arithmetic operations - accelerated by the use of dedicated hardware rather than coded in firmware.

C++ Interpreter - written on Arduino

The aim of this experiment - and it is little more than an experiment, was to determine whether a fairly modern 8-bit microcontroller, running at 16MHz and programmed in relatively standard C, and C++, could interpret PDP-8 machine code, at a rate that is comparable to the performance of the original 1965 machine.

This was the primary aim, but the project also has an educational basis, helping to teach the fundamentals of simple computer architecture, instruction sets and assembly language programming - and also trying to give some insight into what programming was like, almost 50 years ago.

In the 1960s, it was normal to represent numbers on computer systems using the octal system.  At that time (before the introduction of ASCII), the fundamental unit for a printable character was 6 bits. So computers had word sizes based on multiples of 6 bits. Early DEC computers were designed around 36, 18 and 12 bit word lengths - so that characters could be efficiently packed into memory.

These days, it is hard to comprehend how much the core memory cost.  In 1967, based on a DEC pricelist to extend the PDP-8 memory by 4K words, would cost almost half the cost of the $18,000 PDP-8 machine. (In 1967, a new VW Beetle cost $1769).