Sunday, February 22, 2015

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 C++ 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 reduces a program to a sequence of ASCII characters, which may be entered interactively from the keyboard. It offers a means of executing a series of subroutines (stored in Flash) from a sequence of characters stored in RAM.

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




Monday, February 09, 2015

Hello 2015 - What's New?

FPGAs

Last summer, I backed a couple of Kickstarter campaigns - and now they have both delivered.

I am now the owner of a couple of FPGA boards - and I am slowly learning FPGA technology - aided by the subtle democratisation of programmable hardware. More on this later.

Meanwhile, I am still tinkering with the minimalist programming language SIMPL.  As of Feb 9th 2015 - I can report, with some joy and enthusiasm, that I have managed  a quick and dirty hack, to port it to one of my FPGA boards.  I now have a FPGA, hosting a 32 bit, 96MHz soft core processor - that runs one of the simplest interpreted languages on the planet. Is all a bit bass-ackwards, but it's fun.

The sketch is here as a Github Gist. You will need a Papilio Duo and perhaps a LogicStart Shield - or just run it, native on an Arduino if you want a quick play.

https://gist.github.com/monsonite/97730b0456762da20a98

I'm currently trying to condense all my Txtzyme and SIMPL experimentation into a single, easy to read, Quick Start Guide. please bear with me on this - it might take a little time.

SIMPL and BLE

A meeting with an old work colleague over a pub lunch, rekindled my active interest in SIMPL.  As such I have compiled the various blog posts from 2013 and 2014, into a single document, and I am working out the best way to present it as a useful document describing SIMPL and how it can best be used.

We discussed the idea of passing SIMPL programs via a Bluetooth Low Energy (BLE) connection between a Smartphone and a BLE device. SIMPL programs are very compact and ideally suited to the short packet format of a BLE communication packet.


Lithium Battery Developments

I have also been doing some work developing hardware that runs on a single Lithium Ion cell.  This has involved the use of the MCP1640 boost converter and also the MCP73832 battery charger IC. This development work has gone very well and I am confident that I can make an economical battery powered design based around these ICs. The MCP1640 at just 30p in volume, is a fraction of the cost of the LTC3525 boost converter. Combined with a small inductor - such as this one from Farnell - you have a very compact boost regulator for about 50p.

FPGAs - The Democratisation of Programmable Logic

Meanwhile, a couple of Kickstarters that I backed last summer have come to fruition - I have now entered the exciting world of FPGAs and soft-core processors.  The great thing is that now an Arduino can be emulated by a 32bit 100MHz soft core processor on an FPGA, and as such SIMPL can be ported to the FPGA ecosystem.   Here's an update on FPGA developments:

Field Programmable Gate Arrays (FPGAs) are definitely the future for digital electronic design.

They are a "blank canvas" of logic gates and registers, onto which you can paint your own digital design.

However, the FPGA manufacturers tool chains are certainly not intended for easy access to this wonderful technology, and to be thrown in at the deep-end of the various hardware design languages - Verilog and VHDL will appear daunting to most.

Fortunately, some forward thinking individuals have succeeded in providing an abstraction later to these tool chains in the form of an Integrated Design Environment (IDE) and with this easier entry level, have managed to make FPGA technology open to a much wider market of hobbyists and enthusiasts.

Background

There are two competing FPGA manufacturers - who between them each hold about 45% of the world market. With this combined 90% world market domination - there is very little space for their competitors.

Altera - known for their Stratix and Cyclone families of FPGAs.


Xilinx  - known for their range of Spartan FPGAs.



Recently, two crowd funded FPGA dev-boards have come available via Kickstarter. Whilst subtley different - they share the same Xilinx Spartan 6 FPGA.

Scarab Hardware  MIniSpartan 6+ 

This is a professional dev-board with two HDMI sockets, 3.5mm audio jack, 8 channels ADC, miniSD card socket and 2MB of SRAM.   The Spartan 6 is a BGA package  - and most of the I/O is brought out to a pair of dual row headers. There is a miniB USB connection via the ubiquitous FTDI chip.  The board is white in colour with great care taken in matching track lengths for maximum performance.

Gadget Factory    Papilio Duo 

The Papilio DUO - whilst sharing the Spartan 6 FPGA offers a different approach in familiarising the hardware.  It has the footprint of an Arduino MEGA, and additional hardware may be attached in the form of shields or "Wings".   The FPGA is in a LQFP pagkage as opposed to BGA.  There is also the same FTDI  USB interface IC, but on the bottom of the pcb is an Atmel ATmega32U4 which can be programmed as an Arduino (Leonardo).

Whilst not providing on board video, Audio or microSD connectors - these can be added in the form of a "LogicStart" Shield or Gaming shield.

The unique selling point of the Papilio DUO, is that it is supplied with a soft-core processor - the "ZPUino" - which emulates an Arduino, but at 100MHz on 32bit hardware.  Once the hardware is loaded with the logic design for the ZPUino, it will then accept and run a normal Arduino sketch - but at many times the speed performance. 

Arduino users can port their sketches almost directly across to the DUO board and run them on the soft-core.  They can also progress to designing their own hardware designs to accompany the Z- core on the FPGA. 

In my opinion - this allows the Arduino user a smooth transition into the world of FPGAs.

Thursday, November 27, 2014

At Last - The Long Awaited Relay Board!

A General Purpose 3 Channel 16A Relay Board


Every year, for about 5 years now, I get motivated on a long term project of mine, to make an open source heating control system, and every year, I get distracted and fail to make any real progress.

Well, this year it's different.  I have had a week off work at the end of November, and I was determined to progress the project along a little further.

I've come up to North Wales this week to meet up with Trystan Lea and Glyn Hudson of OpenEnergyMonitor.org to have one of our irregular meet-ups, to work on collaborative projects together.

The relay board was something I had wanted to do for some time, and to do it as a potential project with OEM was an attractive idea. Not only will it reach a wider user base, but it has been designed to be compatible with and complement the existing OEM ecosystem - consisting of emonTx, emonGLCD, emonCMS etc.

The board is intended to be a plug in replacement for existing central heating controllers, though with 3 16A mains relays, it is also a very versatile board for other applications.

Power Supply.

The mains section consists of the 3 relays and a 2.3VA transformer power supply. This restricts the live, mains-potential voltages to the upper third of the pcb where they can be kept out of harms way with a suitable insulating enclosure.

Sensor Connectors

The lower two-thirds of the pcb is the microcontroller section, expansion connectors and user interface.

The expansion connectors allow a range of temperature sensors to be plugged in.  

There is an RJ45 connector which allows the Dallas "One Wire" DS18B20 temperature sensors to be connected.  OEM use these already on their emonTx and emonTH products, and so it seemed sensible to use these again, benefiting from their stock item and existing firmware. Additionally they stock an RJ45 break out board, which will accept up to six of these sensors, and can be daisy-chained using standard RJ45 network leads to extend the sensors 6 at a time.  If you have a lot of sensors to wire in, this would be a neat solution.

In addition there is provision for up to 6 analogue inputs. These have been tailored for 10K thermistors, but any analogue signal up to 3.3V may be measured.  I prefer thermistors to the digital type sensors, because they can give better resolution, and they are available in a handy "pipeclip" package, from Rapid Electronics - which are great for making measurements on heating pipes.

Open Collector Output

In addition to the temperature sensing channels, there are some unbuffered digital inputs which are 5V tolerant, and one 200mA open collector transistor output which can be used for driving a 4th external relay.

User Interface.

The user interface is designed to be simple and intuitive - just 4 push button switches and 4 LEDs.  As this device will generally be commuicating with the rest of the system via a wireless link, to a remote display (emonGLCD), the user interface can be very simple.

The LEDs give positive confirmation that the relay has switched to its ON position, and the push buttons are arranged below the LEDs - and can be used for selecting a "boost" or "over-ride" function for any of the 3 relays or external relay drive.

Microcontroller Section

This unit is designed to have a plug in microcontroller module, which includes the wireless device.

The reason for this is that it will allow various combinations of microcontroller and wireless to be used. It also puts all of the slightly tricky surface mount components onto the one pre-built module, whilst the rest of the board uses through hole components for easy home construction.

The first module to be used will be the newly updated RFMPi from OEM - below.

This is a combination of an ATmega328 and either an RFM12B or a RFM69. Whilst this module has previously been used to provide RFM wireless connectivity for the Raspberry Pi, we have updated the design this week, to break out most of the I/O to a 24 pin connector (on the left) - allowing access to 8 analogue input and 8 digital I/O lines plus the SPI bus.  Indeed this should make a compact and useful module with many possible applications.

Another option is my RFM_Stick. It's based on the ATmega328 and has a position for an RFM12 and the new Espressiv ESP8266 WiFi module. This is a new board from me, and no samples are available yet.




The RFM_Stick is the first of a series of boards that share a common 40 pin footprint. There will be a choice of AVR or ARM based boards, designed to have a range of communication options and be breadboard friendly.  ARMiGo is the first of these.

On the right hand side of the pcb is the standard "FTDI" connector footprint which allows serial comms and local programming of the microcontroller.

For those who wish to use another microcontroller or wireless, all of the I/O appears on a 40 pin DIL footprint - which is compatible with my recently updated ARMiGo module. This is a high performance ARM M4 Cortex - with a choice of 48 pin package microcontroller options.

Real Time Clock

I have included an option for a real time clock on the pcb. This can either be a DS1307 or similar, (industry standard footprint) - or my preferred MCP79410 - which is very cheap. The RTC has back-up from a supercapacitor - so that time is maintained during a power outage.

In some applications, operation from a dc supply or a battery might be applicable. A 3 pin connector allows a LiPo or similar battery pack to be added if required.

It is anticipated that samples of the relay board will be available around the 10th of December. Please contact openenergymonitor.org in early December for full details and availability.







A Sneaky Week In Snowdonia



It's not every day your daily commute includes a view of Snowdon in the early morning November sunshine!

Sometimes you just need to get away......

With an enforced week off work in late November, I decided to travel back to North Wales, where I was a student back in the early 1980's. For 3 years, Bangor, Gwynedd and Snowdonia was my immediate life.

With a bit of nostalgia, I left a very wet Surrey last Sunday afternoon, and drove the 250 miles up to southern Snowdonia.

Now 30+ years on, I am back in my old familiar university stomping ground, marveling at the changes that have occurred since I was last her, 3 decades ago.  A lot more retail parks, more roads, and bigger buildings than were here when I was a student. My old hall of residence Neuadd Reichel still stands, but now surrounded by a cluster of new student accommodation blocks painted in garish pastel colours.  Any Bangor alumni who remembers the Plas Gwyn and Tryfan halls, will be shocked to see how they are now demolished and replaced with the modern blocks.  Gone also are the old students union building and the Theater Gwynedd - currently under re-construction, over budget and months behind schedule.

Whilst I have lost touch with almost all of my University contemporaries, I now have new friends in and around the Bangor area.

The Bothy - home for a few days

I'm staying in a bothy, a small traditional cottage, about a mile from the village of Llanfrothen. It's a stone built Welsh cottage, located in a valley that contains a small stream.

Inside it's about 12' x 18' living space with a bed on a mezzanine floor. Roof lights make the most of the natural daylight. Downstairs a small kitchen, with two ring gas cooker, fridge and washing machine. The all important woodstove becomes the focal point of the room. Adjacent to the main living space is a toilet/shower-room. It's basic - but sometimes basic is just what we need to bring us back to realise some of our fundamental values.

The bothy is located in a wooded valley and so is well supplied with firewood for heating, there is an electric immersion water heater, telephone landline and broadband. Mobile reception here is at best flaky on some networks - at worst, non existent.

So, I'm here for a week, not exactly for relaxation, but to catch up with some of my good friends who live in this little corner of North Wales.

My hosts this week are Trystan Lea and Glyn Hudson - who founded Open Energy Monitor about 4 years ago.  The bothy belongs to Trystan's father, and was once used as an architect's studio, before Trystan and Glyn took it over a few years ago as the premises for their start up, open source energy monitoring company, Megni.

Megni has now outgrown the bothy, and has moved to a serviced office premises in Parc Menai - a fairly new development on the southern outskirts of Bangor.

It's a 25 mile commute from Llanfrothen to Parc Menai - and so Trystan has wisely invested in a Nissan Leaf Electric Car.  With a range of 60 miles, it easily meets his daily commute requirements - and what a commute that is, through the beautiful scenery of south Snowdonia.

Trystan's  electric Nissan Leaf, on the Pen Y Pass, en route to Llanberis.

The Nissan Leaf is an all electric super-mini.  It can seat 4 adults in comfort, and has a  boot that can easily swallow a couple of mountain bikes, with the back seats lowered.

A 50 mile round trip uses about 13.5kWh of mains electricity, or about £2 worth.  The same trip in my Golf TDi would cost about £6.50 in diesel.

Trystan uses the Leaf on a daily basis and at weekends, recharging at night on a standard 13A extension lead, and occasionally with a top up at the office, on the end of an extension lead.

Snowdonia was an early pioneer of renewable energy.  A little research shows that hydro electricity was first developed here in Snowdonia in the early 1900's. Today there are several hydro schemes in operation, including the pumped storage scheme at Dinorwic - which was under construction 30 years ago, when I started as a student here.

"Chapel in the Valley"  Cwm Dyli.  Hydro-electricity generated here has served this part of Snowdonia for 110 years.

A mirror-like lake, Llyn Cwellyn - on the way to Caernarfon

Though early morning mists we see, visions of reality....


A visit to my old engineering department revealed that Engineer's have a sense of humour too




TBC



Sunday, November 16, 2014

As Easy as ABC (and D)

The Arduino has definitely been a major force behind the open hardware movement, democratising hardware and making it much easier to develop microcontroller based gizmos.

However, despite it's popularity, the Arduino is showing it's age and has a few flaws. It has however shown that a simple microcontroller board combined with an IDE , an ecosystem based on shields and a strong community following is certainly one way to gain traction in a market for ever more complex products.

The 8 bit AVR at the heart of every Arduino, is a success story in itself. Conceived in the early 1990s and comercialised in partnership with Atmel in 1996, the AVR is a leader in the 8 bit microcontroller market.  However, there is much competition from 32 bit micros - especially ARM, so perhaps it is time to work on a new platform, with its own ecosystem, and for the next few years, there is no reason why AVR and ARM cannot co-exist in the open hardware community.

A great YouTube about the "AVR Story"

So how would you design a better "Arduino" ?  Here's some of my thoughts:

1. A smaller footprint  60 x 20mm  (about 1/3rd the size of an Arduino Uno).
2. Pins on a proper 2.54mm pitch that can be easily plugged into a breadboard
3. USB as standard for VCP comms, programming and power
4. Easily identified ports - arranged by function
5. A forgiving footprint. If you plug it is backwards, you won't fry the microcontroller
6.  More I/O  -  32 pins, as opposed to 20
7.  Higher resolution ADCs:  12bit and 16 bit available.  2 DAC channels
8.  More UARTS, SPI and PWM
9.  Wireless connectivity - with a choice of BLE, WiFi or low power 433/868MHz
10 Upgradable as new microcontrollers arrive in the marketplace

Many vendors sell their microcontrollers in a 44 or 48 pin surface mount package.  This is nice and compact, but not easy to prototype with.  So let's mount the SMT device on a carrier pcb, add a crystal and reset circuit and bring the pins out to an industry standard 40 pin DIL footprint.  A mini B USB connector at one end allows the device to be plugged into a laptop for programming, communications and power.

Here's one I made earlier - ARMiGo a platform for 48 pin STM32F ARM devices:



As you can see, there's a 48 pin LQFP at the centre, a mini USB B at the right hand side and a SMT crystal.  The 5 pin header on the left is for programming, using the ST Microelectronics ST-Link programmer.

Now this was based on the STM32F303, a great little ARM Cortex M4 device.  But it could equally use the STM32F103, or STM32F373, or STM32F411, or even the stonking Cortex M7 - a 200MHz mcu. The great thing about the STM series of ARM devices is that once you have settled on a package size, you can move up and down the family to suit the needs of your application, as packages are fully pin compatible.

The ARMiGo was my first attempt at a generic module, and I must admit, I did not get it right first time. It was tracked out in such a way that gave maximum convenience for pcb layout  - rather than in a logical manner where pins were grouped by function.  The other faux pas - was my power pins were at opposite corners (common on many DIL packages). If you plug it in backwards - you fry the microcontroller.

I decided to look at the DIL package AVR devices - in particular the 40 pin ATmega1284. These parts have their power pins in the centre, and the ports are generally symmetrical. Plug it in backwards, and no damage will occur.

Here's a neat diagram to illustrate this point:

ATmega1284 - a great layout for a 40 pin DIL package


Notice how the power pins are at the centre - so if you did plug this in the wrong way it wouldn't fry - it just wouldn't run. Also, see how the ports are more or less symmetrical - at the corners of the package.  The 4 ports are PA, PB, PC and PD.

Now whilst PA is exclusively for the ADC inputs, ports B, C and D are a bit of a mixture.  It's a good layout, but not perfect.

So I came up with the idea of 4 generic ports, A, B, C, D - each which has a specific function.  


Here's the key point of this post:

Any microcontroller, of 48 pins or less, from any manufacturer,  could be fashioned onto a 40 pin carrier pcb. Regardless of the specific micro, the boards would be interchangeable.


I like to keep things simple, so here's the naming scheme:

A  Analogue
B  
C  Communications
D  Digital

Ok, Port B does not have an easy to remember name yet, but A,C and D are pretty much memorable.

Port A  - 8 Channels of A-D converter
Port B  -  Plan B - all the pins that don't go with the flow
Port C  -  UART (Tx, Rx), SPI (MOSI, MISO, SCK & /CS),  I2C (SCL, SDA).
Port D  -  General purpose digital I/O, timers, PWM etc

Port B is a bit tricky to define at the moment.  In the case of the STM32F373, it would be 8 channels of 16-bit high resolution ADC, but in the case of the STM32F103 in would just be 8 consecutive pins that constitute part of GPIO PortB.

I know this is a bit of a cop-out - but bear with me. 

What about AVR devices - can they be moulded into this common format?  

The 32 pin LQFP ATmega328-MU certainly can be pinned out into the common format.  It has 8 ADC channels to route to Port A,  the UART, I2C and SPI can be routed to Port C - the communications port, and the remaining digital I/O routed to Port D.

Here's our old friend the ATmega328P-PU

As you can see, the power pins are in the centre of the package and the ports are generally arranged in the corners - not perfect, but manageable.

Here's the SMT part - the ATmega328-AU





This can readily be mounted on the carrier pcb and tracked out so that the various peripherals and ports appear on the correct pins. The 8 analogue inputs map to Port A. The obvious communications pins   TXD, RXD, MOSI, MISO, /SS and SCK map to Port C.  The PWM channels map to Port D etc.

This same philosophy could be applied t0 the 44 Pin ATmega 32U4 which is used on the Leonardo.



Summary.

This post has outlines that any 48 pin or less microcontroller from ARM and AVR families can be placed onto a small carrier pcb in such a way that the GPIO and peripherals are located in the same place. This allows the developer to rapidly switch between families or manufacturers.

More on this next time.......


Plot It - a useful graphing programme for serial data


Plot It allows data to be exported in various image formats


An immensely powerful technique when developing smart sensor systems is the ability to capture data in real time from a microcontroller and save it either as a CSV file or plot it graphically.

Several open source programs are available, but the ones I have tried never seem to do exactly what I need, so it was great news when a software colleague of mine produced Plot It, and has agreed to make it widely available for hobbyists and enthusiasts.

Plot It takes in data from a serial port, by polling the microcontroller at regular intervals with a serial character as a request for data packets.

The data packets were designed to hold up to 32 bit data, and Plot It currently accepts 24 bit data - as it was intended to be used as a diagnostic tool for debugging a 24 bit ADC system. 

The data packet consists of 4 data bytes - of which the most significant byte is set to zero.

Following the data bytes, a single byte represents the data channel number. This allows for up to 256 separate sensor channels.  The early version of Plot It caters for just 2 channels at the moment.

Finally, there is a packet terminator consisting of the bytes 0x0D, 0x0A.

The code to send these packets from an Arduino or Nucleo is fairly simple.  The microcontroller waits to see a character arrive in it's serial receive buffer, and then executes a routine that sends out the data packet.

A sketch for Arduino has been put on Github Gist  - here.

Plot It currently works at 9600 baud, but can be tailored up to baudrates of 921600 baud.  The 24 bit ADC system we were testing was sending packets at 20kHz (50uS) - and so we needed a super fast baud rate to get the data across quickly.

Temperature Monitoring - A Typical Application

Plot It can be used for local monitoring of sensors.  One example is my  Arduino based central heating controller, which reads a series of temperature values from analogue thermistor channels.

Thermistors are a fairly cheap method of measuring temperatures, and an alternative to the digital devices such as the one wire Dallas 18B20 series.

Although the Arduino ADC is just 10 bits, multiple readings can be averaged to produce a smoother data. In addition, a simple 100nF capacitor across each thermistor input is a good way of reducing analogue noise.

As a consequence, the thermistor can produce fairly high resolution data - down to about 1000th of a degree.  Whilst the absolute accuracy of this measurement may only be to 1/10th of a degree, the high resolution allows minute changes in temperature trend - such as those caused by draughts etc to be analysed.

Plot It may be used to provide an insight into how quickly a room responds to having the eating turned on, or how quickly a tank of hot water cools down after heating.  Seeing how these systems respond to inputs over time allows better analysis, and better control systems to be designed. 

The "Blue Room" heats up smoothly, whist the "Red Room" is prone to draughts and air movements

Note how each graph has its own scale, blue on the left hand side and red on the right


Temperature fell by 0.7C - until a door was closed, removing the draught

The right hand mouse button allows several features to be selected - such as auto-scaling, image export, and setting the scaling to default.  The left mouse button allows drag selection of data to pan and zoom into any area of interest.

Plot It can export your data to a CSV file for further analysis in spreadsheets etc.

It is anticipated that further features will be developed in time.








Sunday, November 09, 2014

Using the SDcard, RTC and SRAM on WiNode and Nanode RF

This is an update of a post to the Nanode Website from October 2012.

The original is here

Getting to know Nanode and Winode Hardware

Part 1. Using  the SD Card and RTC to make a 4 channel datalogger.

Nanode and Winode are something of a departure from the usual Arduino hardware, and when functioning as a pair, form a unique extension of the Arduino platform to include ethernet and low power wireless connectivity.
Nanode and Winode are both based on the ubiquitous ATmega328 microcontroller, but include the following common functional blocks.
1.  An RFM12B  low power wireless transceiver module.
2. A MCP79410 Real Time Clock. This provides RTC, two alarms, 64 bytes of battery backed RAM and 1kB of EEPROM.
3.  microSD socket – accepts up to 2GB microSD cards for long term datalogging.
4.  32kB battery backed SRAM.  Can be used for downloading sketches or buffering larger quantities of data from the web.
Using freely available libraries it is possible to utilise these hardware blocks, and quickly put together applications on the Nanode or Winode.
The RFM12 is connected to the SPI bus and is selected by Digital 10
The MCP97410 RTC is an I2C device using An4 and An5. It’s multipurpose output connects to Digital 3 – or Interrupt 1
The SD card is also connected to the SPI bus and is selected by Digital 4
The 23K256 SRAM is connected to the SPI bus and is selected by Digital 8 (Winode) and Digital 9 (Nanode).
In this post I will look at the operation of the SD card and the Real Time Clock.  
The SD card is extremely useful for long term datalogging applications whilst the RTC, as well as providing clock and calendar functions for real time control, also provides two alarms or a square wave output which can be used to wake up the ATmega from sleep at regular intervals.  The RTC also contains 64 bytes of non-volatile SRAM and 1K of EEPROM.
The  SD card Library is included with the Arduino IDE.  For my examples I am using Arduino IDE 1.0.1.   This is an easy to use library, and if you are a newcomer I suggest Jeremy Blum’s excellent video tutorial. 

This has 3 examples, how to write to the SD card,  read and write and how to datalog several sensors to the SD card.
For both the Nanode and Winode, the SD card is selected with Digital 4. You will need to modify the code to use the correct chip select line.
The MCP94710 is a powerful little chip – not just a RTC, but includes 2 independent alarms, 64 bytes of battery backed SRAM and 1024 bytes of E2.  If you buy the MCP94712 version, it also includes a uniquely assigned  64 bit MAC address. These devices are available from Farnell for about £1.00. It is connected to the ATmega via the I2C bus, and so needs the Wire library to support its functionality.  It has a multipurpose output which is connected to the Digital 3 (interrupt 1) input of the ATmega.  This can output a squarewave to generate regular interrupts, or be triggered on either of the Alarm conditions. Please refer to the Microchip MCP9471X data sheet for full details of the internal registers.
I decided to write some code to exercise the main features of this RTC and also make use of the microSDcard for datalogging.
Before using these devices we have to include the SD card and Wire (I2C) libraries – so remember to add the #include statements at the top of the code.
#include
#include

The sketch initialises the RTC and the alarms, and then writes a 64 character text message to the battery backed SRAM.

The main loop then proceeds to log the analogue input from ADC0 to the SDcard every 5 seconds.  The alarm has been configured to trigger every minute, and print out the 64 byte message to the serial terminal window, as well as illuminating the  LED.

The code for this demo is available here on Github Gist.  

It compiles to 18054 bytes on the ATmega328.

This second sketch on Github Gist logs the four analogue input readings to the SD card, once per second.  It compiles to 19166 bytes on the ATmega328.  

The sketch sends out the current time, the value of the four analogue input channels – and once per minute, acting on an alarm it outputs the message “The Quick Brown Foxy Leapt over the Lazy Dog whilst he snoozed”.

I found it important to declare and reserve space for the various strings:

String dataString = ”      ”;
String stringZero = ”      ”;
String stringOne =  ”       “;
String stringTwo = ”       “;
String stringThree =  ”     “;
String stringId = ”        ”;
And then form individual strings for the analogue readings which are then concatenated together.

int temp_0 = analogRead(0);
int temp_1 = analogRead(1);
int temp_2 = analogRead(2);
int temp_3 = analogRead(3);stringZero = String(temp_0); // Form strings from the individual ADC readings

stringOne = String(temp_1);
stringTwo = String(temp_2);
stringThree = String(temp_3);
stringId = String(id);

//Create Data string for storing to SD card using the CSV Format
dataString = stringId + “, ” + stringZero + “, ” + stringOne + “, ” + stringTwo + “, ” + stringThree; // Concatenate the strings to write to the SD card
An early attempt using a different approach resulted in a memory leak which caused the ’328 to crash after about 5 writes to the SD card:

This code example will be further developed to make a real time logging, 4 channel temperature controller, as part of a central heating controller project.

The next post will combine the SDcard and RTC code example with simple 2-way wireless packet communication – allowing the temperature measurements to be send to a Nanode Gateway or other RF compatible device.

November 2014 Update.

It has been a couple of years since I wrote any code for WiNode. I got back from California and had to find myself a job, so WiNode went on the back burner for a while.

It was always the intention to make the WiNode part of an integrated system based around the JeeNode RFM12B wireless communications library.  This library is popular amongst the hobbyist community and is supported by several open source devices including the emonTx, emonGLCD and Nanode Gateway produce by OpenEnergyMonitor.

The first step was to include the JeeNodes library with the code example - such that packets could be received from other RFM12B equipped nodes.

I have put together a fairly simple example of this, plus the ability to read temperature values from local thermistors connected to the ADC channels 0- 3.

This code is also available as a Github Gist

WiNode Revisited

I am currently revisiting WiNode, with the intention of designing a new version aimed specifically at central heating control applications.

This will retain the RTC and SDcard of the original, but include a mains power supply based around a small encapsulated pcb transformer and bridge rectifier, and a pair of 8A rated mains relays.

The intention is that this variant will be compatible with existing central heating controllers, providing control over hot water and central heating functions, remotely via wireless, from either a display such as the emonGLCD or via a web Gateway such as the Nanode RF.

In fact any RFM12B or RFM69 based module should be able to interact with WiNode. This opens out applications for Raspberry Pi users, and also other applications that require mains loads to be switched - such as solar hot water system pumps.

I will cover more detail of the new design in a future post.