Thursday, April 09, 2015

Exploring PianoForte - Part 0

The minimum build PianoForte - just 20 components
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

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.

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










Using the Arduino for Retro-Nostalgic Computing

In just about 4 weeks time we come to the 50th anniversary of the PDP-8 Minicomputer.  (23rd March 1965).

As a tribute to this game-changing machine, in the last week I have been thinking about the user interfaces used on minicomputers of the 1960s and how the early computer users interacted with their machines.

It was common in this era for the machine to have a large front panel consisting of lights and switches, allowing the contents of registers to be examined and simple programs to be toggled into memory using the key switches.  The machine that most typifies this period of computing was the PDP-8 - first introduced in 1965, and by many, said to be the first minicomputer.

Here's how it started 50 years ago:



It got me wondering if a similar front panel consisting of LEDs switches could be created cheaply - as a nostalgic retro computing accessory shield for the Arduino.

LEDs and switches can be easily serviced using shift registers - an ideal application for them, which saves on I/O lines - as per my posting "A Little Bit Shifty" .

A good example of this is in the recreation of the KenBak 1 computer - using an Arduino as the KenBak-uino- here.

Why should I not like a minimalist computer system that is virtually named after me :)

FPGAs.

These are becoming very popular as a means of creating custom hardware and emulation of old microcomputer/microprocessor hardware.

I had thought about implementing a PDP-8 cpu on an FPGA, and then thought whether I really wanted to get involved with PDP-8 assembly language - probably not. However it would be neat to have a front panel reminiscent of those from the mid-1960s, where you could see the value of the program counter and the various registers, lit up in lights, and blinking sequences as the program is run.

Having tinkered around with the SIMPL language on Arduino, I have added a few LEDs, and it is perfectly possible for an Arduino to mimic the LED register displays typical of the PDP-8. A few simple instructions can be used to echo the instructions stored in RAM up to the LED display.

The standard Arduino is limited to 18 I/O lines, if you assume that digital 0 and digital 1 are committed to the serial port. This allows a single 12 bit LED array, plus 6 inputs for either analogue or digital signals.

I wrote a little bit of SIMPL code to send a 12-bit number directly to 12 LEDs conected to Digital2 - Digital 13. This works well if you just want a quick binary number LED display. For larger displays and keyswitch inputs, it's generally best to resort to using shift registers. My blogpost of May 2014 describes how to write out patterns to both 8 bit and 16 bit shift registers and how to control stepper motors from SIMPL using commands to drive a shift register.

More LEDs and Switches

On the Arduino MEGA, there are 52 usable digital I/O lines plus 16 analogue inputs - that would be enough to recreate lots of blinkenlights and switches, without having to add extra ICs as LED drivers.

The first Arduino MEGA 2560 I bought cost about £45.  They are now less than £12 from ebay/China, which makes the MEGA a very attractive, low cost starting point for a variety of simple computing projects.

However, it is unlikely that an AVR could satisfactorily emulate a PDP-8. The PDP-8 was a 12 bit machine, originally with 4K of RAM.  The AVR cannot directly execute a program out of RAM, unless it is an interpreted language, such as SIMPL, Bitlash or Tiny BASIC.

It might be possible to program an Arduino with a PDP-8 machine code interpreter, written in C, but I suspect that the speed would be at best 1/10th that of the original PDP.

So it might be best if any efforts along these lines was done as a tribute to the computers of the 1960s, rather than a true emulation.

A penny a thought, - a pound for 32 bit thoughts.

The humble Arduino based on the 8-bit AVR ATmega328 is now showing it's age (21+).  A new generation of small, very low cost 32 bit microcontrollers have arrived and are benefiting from a smaller architectural geometry and low pin count packages. If the Arduino was being designed in 2015, instead of 2005, it would use a 32 bit mcu.  They are better than half the cost of the 8 bit AVR parts, and include more peripherals and better ADC resolution.
 









What can I get for a Pound?

Poundland don't sell microcontrollers in their raw form - but if they did, they would probably sell these.

The STM32F0 range of 32 bit ARM micrcontrollers are designed for low cost applications that don't need on-chip USB.

They offer a 48MHz ARM M0 core,  16 - 64kB of flash memory and 4 - 8kB of SRAM and a good rich mix of peripherals.

Up to 2 USARTS
Up to 2 SPI
Up to 2 I2C
12 bit ADC  - 10 channels
Several timers - including quadrature decoder and PWM
On-Chip USB - STM32F042 range

They are available in several package sizes from a 20 pin TSSOP to 64 pin LQFP, family members are pin compatible for easy upgrade - and they start at under £1 in 1 off quantity. For greater volumes - the price drops to around 34p.

The 48 pin LQFP is no bigger on the pcb than an ATmega328P-AU, but provides 35 lines of I/O plus the crystal oscillator and a 32768Hz oscillator for a Real Time Clock. It provides two USARTS and 2 SPI interfaces which massively increase the communications capability over the ATmega328.  The 12 bit ADC offers a 4 fold increase in resolution over the Arduino.  If you choose the STM32F042 range - they even come with on-chip USB, and don't even need a crystal.

There has never been a better time to take the Arduino philosophy and reinvent it using a cheap 32bit microcontroller - offering about 10 times the computational throughput.

By implementing it on a breadboard friendly 40 pin DIL footprint - a bit like the ARMiGo.  It can be powered through the mini B USB socket on the right, and programmed via STLink and FTDI using the connector on the left.






SIMPL - A Quick Start Guide

 SIMPL 

Serial Interpreted Microcontroller Programming Language

This draft post attempts to introduce SIMPL - a simple interpreted language for microcontrollers.

SIMPL is a small language resource that resides in flash memory on the target microcontroller. It contains an interpreter that allows the user to have control and interactive access to the memory and peripherals of the mcu without placing an unnecessary burden on its limited resources.

SIMPL can be used as a development tool to exercise new hardware, or as a compact and efficient programming environment that may be ported to virtually any microcontroller or FPGA soft core, that supports a C compiler.

SIMPL can be implemented in Arduino ++ code, or in standard C code.  It compiles to under 10Kbytes on most systems so can reside alongside the user application program.

SIMPL defines a 16 bit integer virtual machine.  With this VM present on the target microcontroller, the user need not get involved with the machine specifics of a particular microcontroller.

The Advantage of SIMPL

SIMPL is a minimalist interpreted language for direct control of microcontroller hardware, via a communications link. This may take the form of wired serial connection, a wireless or Bluetooth Low Energy link. SIMPL will  run on virtually any microcontroller, or FPGA that supports a C compiler. It's instruction set is small, just 50 commands, and designed to be human readable. Snippets of SIMPL code are compact and can be embedded into communications packets or even web URLs (such as REST), for commanding remote devices.

SIMPL reduces program code down to a few lower case alphabetical and punctuation characters - which each character representing a function or block of functions, which are stored in the flash memory of the microcontroller. These operations can be further reduced to a concatenated block of code that is represented by a single upper case character, however these operations are stored in RAM, and can be updated and modified at run time.

In this way, a microcontroller device, containing the SIMPL interpreter in flash, will execute commands sent to it via a communications link - such as serial, or BLE UART link, or wireless packet protocol conveyed over low power wireless - for example RFM12B or RFM69 and Jeenodes. It can also be reprogrammed remotely.


A Brief Outline.

SIMPL uses a very small interpreter, that sequentially scans through characters stored in a buffer, decodes the character, and executes a small block of code from flash, that is associated with each character.

The interpreter looks at each character in turn, checking if it is a number (0-9),  a lowercase character (a-z), a punctuation character, or an uppercase character (A-Z).  Depending on the type of character encountered, the interpreter follows a different strategy. Non-printable ASCII characters  (less than 32 or greater than 128) are currently ignored by the interpreter.

Numbers 0-9 are decoded into a 16-bit integer variable called x.

Lowercase and punctuation characters, known as primitives, and are decoded in a series of Switch-Case statements to execute small blocks of code.

Uppercase characters, known as Definitions, force the interpreter to jump to a given address in RAM, and execute the string of characters found there, rather than the input buffer.

SIMPL uses a very simple, 16 bit virtual machine model for its operation.  This model fits nicely with C code and 16 bit integer maths.

It contains two 16 bit registers,  x and y into which the operands are loaded.  These registers are used as a pair of operands for all arithmetic, comparison and logic operations, with the result being placed in x.  In this respect, x may be considered to be analogous to the accumulator in other systems.

x is also used as the data source and destination register for any memory or I/O operation.  The y register is used to supply the address for memory operations.

In addition to x and y, there is a loop counter variable k. This is decremented each time a loop is executed and is used to force the interpreter to exit the loop when k reaches zero.

Implementation in C and Arduino

Whilst the SIMPL interpreter is written in C code ( and C++ on Arduino) for portability, it could be ported to run under the native machine language of any specific processor, if much greater execution speed were needed. However with mcu clock speeds now 10 to 100 times faster than early 8 bit processors, resorting to machine code may seldom be needed.

However, there is a case to warrant the use of direct register manipulation - especially for the digitalRead and digitalWrite commands as used in Arduino. These can be sped up by a factor of 10 using direct port manipulation.

Instruction Set

Alpha Primitives


a
b
c
d                     Define a digital port pin
e
f                      for-next structure
g
h                      Set an output pin High
i                       Read an input pin
j
k                     The loop counter operand
l                      Set an output pin Low
m                    A blocking delay in milliseconds
n
o                     Write to an output pin
p                     print x to the serial device as an integer number
q
r
s                     Get an ADC sample
t                      print the current microsecond count (for timing functions)
u                     A blocking delay in microseconds
v
w                    While structure
x                     The primary data (Accumulator) operand
y                     The secondary (Address) operand 
z                     Sleep - a non-blocking pause for x zeconds - whilst still monitoring UART and I/O

Maths Group

+                     Add x and y and put the result in x              
-                      Subtract  x from y and put the result in x
*                      Multiply x and y and put the result in 32 bit pair [y:x]
 /                      Divide y by x and put the result in x, and remainder in y

 %                    Calculate y modulo x and put the result in x

space               Move the number just entered to y (allows for 2nd variable)

Comparison Group

>                     If y greater than x, put result in x (equiv to x = y-x)
<                      If y less than x, put result in x (equiv to x = y-x)
=                          If y equal to x, put result in x (equiv to x = y-x)

Logical Group

&              Bitwise AND of y and x
|                        Bitwise OR of y and x
^                       Bitwise XOR of y and x
~                       Bitwise Complement of x

Memory Group

@                     Fetch the data into x  from the memory address defined by y   (PEEK)

!                       Store the data in x  to the memory address defined by y (POKE)

Definition Group

:                        Start a colon definition
;                        End a colon definition

Block Group

{.................}    Loop the code contained within the braces whilst loop variable k is +ve
(................ .)    Conditionally execute (or skip) the code contained within the round brackets
[,,,,,,,,,,,,,,,,,,]    Create an array of comma separated elements within memory (enumerate and store)
_Print String_   Print the string contained within the underscores
"Store String"   Store the string between the quotes in memory
.A.                   Print the characters assigned to A (list the word A)
'A'                   Retrieve the string from memory stored at address A

Control and Miscellaneous

?                      Print out the contents of the program stored in user RAM   (LIST)
,                       A separator between elements stored within memory - store and increment
\                       Escape from interpreter - stop all commands
 £                     Restart interpreter
 $                     Load x with the ASCII value of next character - do not interpret/execute
 #                     Send a number as a bit pattern to a device, such as port register or shift register


Timing, Sleeping, Pauses and Delays

Much of what a microcontroller does is to synchronise events with time. This might be as simple as flashing a LED once per second, or toggling a square wave from a port pin at a given frequency.  Arduino has been equipped with the millis() and micros() functions, and the delay() and delayMicroseconds() functions to make time synchronised coding simpler.

The delay functions are blocking - in that the microcontroller cannot execute any other code until the delay period has elapsed. This is OK for short periods, up to about a second, but it prevents the system from responding to external events, such as a change on an input pin, or the User trying to stop the program.  For this reason, SIMPL has been given a non-blocking delay command z, which allows it to pause for a while, whilst still monitoring the UART Rx buffer for certain characters - such as the \ escape character, or for a change in status of any input lines, which might signify an external event.

z - is often associated with sleeping, so appropriate for a command that effectively allows the microcontroller to take a nap, until something happens to wake it up.

I also propose at this point the zecond - that is a non-blocking nap for a second.  This allows for naps of 1 zecond up to 18.2 hours to be defined.

Waiting for External Events

This is a common use for While statements for in C.

while(some condition is met)
{ Execute this block of code, and continue to test condition}

This simple construct needs to be efficiently coded into SIMPL.

For example  - wait for a value to be exceeded on an ADC input, say 600 on ADC 5.

600 5s>(............)

600 is first loaded into x, and the space character transfers it to y.  Then we read ADC 5 (into x) and compare it with the value in y.  If the result in x is positive - we execute the code in contained between the round brackets. This code could just be an idle loop or a pause - non-blocking delay. After this code is executed, we need to test again.

To code this into SIMPL we need to have a mechanism to repeatedly perform the test, and a means to execute an idle loop.

We can make this distinction using the two flavours of brackets. The code to test for the condition is enclosed in round brackets, and the code for the tasks to be done whilst idling is enclosed in the curly brackets (braces). This makes our code as close as possible to the C construct.

We then have the general form, where w defines the while statement

w(...condition..){...idle loop.....}

or as in the example

w(600 5s>){loop here until condition returns zero or less}

This is a kind of conditional form of the general loop, which decrements the loop counter k each time around the loop, until zero is reached.

Can we use the same constructs to implement for-next loops?

General form in C

for(i=0; i<=10; i++)

Here we have a loop variable i, which is initialised to zero, tested against an upper limit (to execute a conditional block of code) and then incremented (or modified) each time around the loop.

Let' use f to designate a  for loop. We need to supply 3 parameters

initial value, test condition, modifier

We could do this by setting up the initial value and modifier outside of the test condition - by using x and y

Lets run from 0 to 100 with a modifier of +1

0 1f(100<){ loop}

A better method might be to borrow the loop counter k, so that 3 parameters can be entered into the conditional statement.

Using the space as a stack pushdown, the sequence

10 11 12
puts 10 into k, 11 into y and 12 into x.








The Decimalisation of Time- A SIMPL means to handle regular events.

This comes as a result of the need to control equipment at specific times during the day, and on specific days of the week.

It allows very simple code to be used to determine the time and day, and decide whether an action routine should be executed.

By reducing the time and the day of the week to a 16 bit integer, simple comparison operations can be done to decide the program flow.

In applications such as central heating control, there is no need to resolve to the nearest second, when 10 second accuracy is perfectly acceptable.  It also allows the table that schedules operations to be condensed into an array of 16 bit integers.

Let's invent a new measure of time - the decond.  A decond is 10 seconds and there are 6 deconds in a minute.

1 hour  = 360 deconds
1 day   =  8640 deconds
1 week =  60480 deconds (less than 65536 - so can be expressed as16 bit unsigned integer).

As there are less than 10000 deconds in a day, the most significant digit of the 16 bit number can represent the day of the week between 0 (Sunday) and 6 (Saturday)

In addition, the Arduino millis() function can be used for timing, and incrementing the decond counter.  10000 millis in a decond, and 60000 millis in a minute. Both of these will nicely fit into a 16bit unsigned integer.






More Applications for SIMPL.

A few notable things have happened since I was last using SIMPL to control stepper motors and LED arrays using shift registers. I have developed a new compact RFM12/69 wireless I/O breakout board for the Raspberry Pi in association with my friends at Open Energy Monitor and I have invested in a couple of FPGA dev boards - launched via Kickstarter.

Both of these developments can benefit from using the SIMPL language to exercise them and try out ideas on new hardware.

The RFM-Pi board is a compact I/O board (33 x 28mm) fitted with an RFM12/69 wieless module and ATmega328P, running Arduino with the Jeenodes wireless protocol.  The pcb plugs into the I/O header of the Model B+ and Pi 2, where it picks up 3V3 power, Rx and Tx from the Pi's UART and a GPIO line for reset.  This is a very simple way of providing Jeenodes/RFM12 wireless communications for the Pi, so that it can be used as a basestation for the series of wireless energy monitoring products developed by OpenEnergyMonitor.

However, in the latest version of the RFM-Pi, I chose to make available most of the I/O pins of the ATmega328 - so that in effect, this board may also be used as a I/O expander for the Pi - providing up to 8 analogue input channels and 5V tolerant I/O pins.It can be used as an Arduino compatible wireless I/O extender for the Raspberry Pi. It breaks out 12 digital I/O pins and 8 analogue pins from the ATmega328 SMD package, giving almost complete Arduino functionality in a small form factor.

Additionally, the board may be used as a plug in module, providing RFM12 wireless and Arduino functionality for some other project. It can act as an analogue sensor interface, or hardware controller and be controlled remotely from distances in excess of 100m using the Jeenodes wireless library.  It is compatible with the other products in the Open Energy Monitor Range - and could form the basis of a new form of sensor.  It requires a 3V3 supply - which could be provided from a coin cell or from a larger lithium cell- such as these 2250mAh common size 18650CA cells.

By running the SIMPL interpreter in the background, the RFM-Pi board can execute SIMPL commands via a 250m range wireless link.

SIMPL is also great way of getting the Pi to drive the I/O board - by a series of easy serial commands. This would open up the Pi to driving LED arrays, stepper motors and indeed, anything that the Arduino can do - just with a few high level commands.  The Arduino has 5V tolerance, so best to have it take the knocks when experimenting with I/O - rather than frying a more expensive Pi.







A SIMPL Compiler?

Having "lifted the hood"  again on SIMPL, I have been thinking about the possibility of a SIMPL compiler. There might be a way in which  C code source could be compiled into an interpreted SIMPL program. A machine compiler would help with more complex programs and reduce human errors in coding.

SIMPL has a number of primitive operators, that are mapped into machine language, using an interpreter written in C.  Lower case alpha and punctuation characters limit the primitives to just 58 instructions.  This ensures that a microcontroller that runs SIMPL  - has a memorable and easily managed reduced instruction set.  For future implementations it means that a machine could run SIMPL from a 6 bit instruction.

This would allow more complex SIMPL programs to be machine generated from C source code, and reduced to an interpreted text file to be run on any micro.  It's kind of like the Java Bytecode idea where common code can run on a variety of different platforms - provided that they have the interpreter.  Imagine what sort of a SIMPL program could be conveyed in a 140 character text message - sent to a remote device by SMS.

Better Branching

For this to happen, SIMPL needs some further augmentation to allow easier branching and decision making - in what I call  "If this  - then that" or IFTTT- popularised by a recent new IoT service.

Ideally, and in its simplest form, a parameter needs to be tested against a number (using subtraction) and then branch if the result is positive, negative or zero. The branch would be to either execute the next character (code block) or skip it. This would allow the popular constructs of If-Then-Else and While loops to be generated.

I have implemented a simple < or > test, but it's a little clunky and also needs an equality test as to be included as well.

The round brackets (.....)  represent a block inline of code that should be executed on the outcome of a test or skipped. This would allow While and For constructs to be programmed.

The square brackets [....] could be used for a switch-case construct to be generated.

Whilst I am running out of lower case characters for the primitive commands - only e,f,g, t and v remain, there is loads more scope for expansion by using some of the remaining printable punctuation characters - a total of 32. Some such as +, -, *, / ,>, <, {, }, :, ;,@, !, _ and ? have already been defined leaving about 18 for later.  Logical operators such as & and | (or) are an obvious extension leaving a few like £, $, %, ^, ~, # to acquire some meaning - probably similar to their meaning in a C context.

So in theory, SIMPL can have a maximum of (26+32) primitive commands plus 26 user defined words - as defined by uppercase alpha characters.

Better Arithmetic

SIMPL currently has an x variable and a y variable that can be set to the previously entered value of x using the @ (fetch) and ! (store) operators. This is a bit clunky and a better way of handling multiple variables would probably be by using a stack. I want to try to keep the interpreter simple, and not implement the full stack logic. As most microcontrollers only combine 2 variables in their math operations,  just x and y will be sufficient to handle this.

In FORTH, numbers are automatically put on the stack, but in SIMPL, they always go into x, unless stored to y using the ! operator.  A neat idea would be to use the space character (instead of !)  to inform the interpreter that another number is expected immediately, and so that x should be stored to y, so that x is free to accept the second number.

This would make the math operations a whole lot more readable - just by separating the variables with a single space.

123 456+p  would add 123 and 456 and print it out.

As well as the math operators, the logical operators would also benefit from this increased flexible notation.  The space operator implies - push the top of the stack down to make room for another parameter - allowing constructs such as

123 456+ 23-p    so the interim sum of 123+456 is pushed down by the 2nd space, allowing room for the 23 and the subtraction operation.  This makes it a lot more FORTH like and very much improved readability for numerical operations involving two variables.

Rule: A space following a number implies that the number is automatically copied from x (top) to the y (next) variable.

More Operators

&   Bitwise AND
|     Bitwise OR
^     Bitwise XOR
~    NOT (invert)

$     String operator
%    modulo operator
(...)  Conditionally execute this block of code
[...]  Use x to select an option from the list contained within the square brackets
£     Invoke SIMPL interpreter
#  
,      separate a list of integers
.      Pop x and print it (FORTH compatibility)
?     Print out the current set of definitions
\    
"
'  
:     Start of colon definition
;     End of colon definition
_     Text string identifier