Arduinos, Agents and Mailboxes

Today I look at some hardware ideas - on a quest for a Universal Programming Platform. It's probably the programming equivalent of the Holy Grail, but there has to be an easy way to switch between broadly compatible platforms depending on application.

Physical Computing Platforms are all the rage now - The "open source poster child" Arduino has a popular following, and is ideal for small monitoring and control tasks. The Arduino Mega takes over for more I/O intensive jobs, and if you want something with raw power the mbed offers ARM M3 Cortex power at a sub-£50 price.

Arduinos - Everywhere

Right now, there seems to be Arduinos everywhere, at home, at work in the office and in my shed. I guess I'm partly to blame, having introduced them into my life in winter 2009 - and they seem to be breeding.

The Arduino is an almost perfect tool for small monitoring and control tasks. It's small, cheap and readily available. If you need one in a hurry you can build something on stripboard in under and hour costing less that £5. This is the approach I take for most of my rush-jobs. Recently I have invested in some professionally made pcbs for the Nanode - an Arduino compatible board with the advantage of internet connectivity.

Since last October there has been an Arduino Mega controlling and monitoring my central heating, and logging my gas usage.

Two weeks ago I started work on a solar thermal heating controller, based on a DIY stripboard version of Arduino. I hope to be revisiting that controller this weekend and updating the control algorithm - as soon as we have some sunshine I can test it!

Last weekend at the Snowdonbuild 2 session, I put together a simple solar PV tracking system and used my ethernet connected Nanode to send solar PV data up to the internet, where it was displayed on the openenergymonitor EmonCMS server.

This week at work, I have been debugging a powerful white LED driver board which will be used as a "sun simulator" for a PV educational instrument we are developing. It should come as no surprise that I have an Arduino controlling the brightness of the LED arrays, and another Arduino (Nano) measuring the output of the PV module under test.

As I said, Arduino is almost the perfect prototyping tool. It's the first thing I reach for these days when I have an idea I wish to try out. Years ago, I used to use Microchip PICs, but not knowing C at that time meant that progress was slow and painful. In the last couple of years I have learned sufficient C to be able to make good headway on the Arduino, and this new skill has allowed me to program other processors. C is virtually a universal programming language, and provided that you have the compiler tools, you can switch from one micro to another with surprising ease.

More Grunt?

Given a highly portable, almost universal programming language - how about a similar "universal" hardware device which means that applications can easily be ported from one system to another? The Arduino comes close to this for small applications, and if you need more memory and I/O pins you can always reach for an Arduino Mega 2560.

But what if you need a lot more processing power for applications such as audio or video processing or realtime control of advanced dc motors. What about an "Arduino" with an ARM processor or even a DSP at its core. The ARM is widely used in mobiles and PDAs. An estimate is that 98% of all mobiles produced use at least one ARM device.

The ARM M3 Cortex as used on the Mbed rapid prototyping board is also gaining momentum. How do you main compatibility with such a wide range of new processors without throwing away all your investment in code?

Connecting Stuff

One of the things I've been working on recently is a universal instrumentation and control board. It takes a USB feed in at one end, and expands this out to a whole range of ports which appear on a easy to use 2 x 30 pin DIL header. I'm developing a couple of educational instruments at the moment which need a variety of control signals, and I decided to base each instrument around the same control board.

The hardware has to be rugged enough to survive the abuse likely when used by undergraduates, so all the I/O ports are buffered and the analogue input feature current limiting resistors and zener overvoltage protection diodes.

The board uses a Cypress 8051 derivative to provide the USB interface (this is for historical legacy and compatibility reasons) and then has a second microcontroller to act as the main "grunt".

The processor I've chosen is a blisteringly quick 32-bit floating point DSP , the 28335, from Texas Instruments. This comes on a little plug in daughter board or "control card" which fits into a DIMM (memory) socket. Texas have released a number of their DSP devices on this same plug in format - so you can pick and choose a processor to suit your application - from 16 bit fixed point to 32-bit 150MHz floating point.

I've chosen to hedge my bets and make either the Arduino, or Arduino Mega as one of the processor options. By putting down a series of headers on the board in the right pattern, an Arduino, Mega or even an ethernet connected Nanode can be plugged in.

The interesting thing that led me to this course of action was that the Texas DSP presented some general purpose I/O lines which were almost identical in function to those on the Arduino Mega - i.e. 16 ADCs, 12 or 14 PWMs and about 30 other digital I/O lines. It occurred to me that with the portability of programming in C, it shouldn't matter whether you are dealing with a Mega2560 or a 28335 DSP - it's just a block of programmable hardware. The common hardware model continues as the DSP offers 3 serial UARTs, an I2C and an SPI port - all of which are found on the Mega 2560.

Mailbox Communications

To get all this lot to work I have devised a dual port memory scheme so that a PC via USB can access a common block of memory into which a register model of the instrumentation controller has been configured. The memory is actually a 32K x 8 serial SPI SRAM. Whilst not the fastest device, it has the advantage of a low pin-count needed to access it, and by using a TTL buffer it was fairly straight forward to implement a dual port access system. The 8051 USB processor did not come with an SPI port, but the SPI protocol is simple enough to program by bit-banging a couple of I/O pins - so can be implemented on virtually any micro.

The proposed way it will work, is that the main processor (the DSP) will run a main instrumentation loop, which involves taking readings from its ADC channels and processing them, it then stores the processed results at certain reserved locations within the shared SPI SRAM. After posting these results, it relinquishes control of the access to the SRAM, by raising an I/O pin. The 8051 micro can then access the RAM, grab the results and send them up to the PC for processing and display.

In the same manner, data from the PC can be loaded into the SRAM, and each cycle of the main loop, the DSP checks the SRAM for this data, and if necessary updates the state of its I/O lines or changes the PWM values or whatever. Its a simple generic method which allows two unrelated systems to communicate with each other by way of a "mailbox" implemented in shared SPI SRAM. The PC doesn't really have to know anything about the DSP - just where to collect the data and where to post data to drive its I/O. The whole I/O and peripherals of the DSP are effectively memory mapped to specific locations within the SRAM.

Now when we decide we don't want to use the DSP, but have come across a new processor such as an ARM or whatever, we just plug that in, and have a small routine running on it which implements the register model and the mailbox system. The PC would be none the wiser, as far as it's concerned it's just talking to the same processor.

This is analagous of how spies and agents communicate with each other using a mailbox or drop box. The agents don't know each other, for security reasons this is essential - all they know is to leave messages at a given location and check back at regular intervals for a reply.

The 32K x 8 SRAM can be allocated in whatever way suits the application. The access registers to the I/O will probably all fit on a single 256 byte page, leaving loads of room for expansion. Large arrays of sampled data from the instrument and monitoring processes could be written to certain pages of SRAM and picked up a page at a time by the PC.

A similar dual port memory scheme has been implemented using EEPROM. This allows the PC to download the application program into the EEPROM and a routine within the DSP allows it to boot from this EEPROM and so pick up the new firmware. The hardware to drive the SPI SRAM and EEPROM and implement the access control is just a couple of 74HC244 octal buffers.