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.

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.

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.

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.