Sunday, May 29, 2011

Converging Threads

Friday May 27th.

The Nanode project is at last starting to gel, with a whole lot of separate threads coming together.

On Friday I met for lunch with Mike McRoberts to discuss the possibility of a commercial version of Nanode.

Later in the afternoon, I was joined at the London Hackspace by Andrew Lindsay, who is the leading light in maintaining and developing a library of routines to exercise the ENC28J60 - the particular Ethernet controller that we use on the Nanode.

Andrew demonstrated his latest code example of DHCP. This allows the Nanode to automatically be assigned an IP address which dramatically simplifies the connection to the router.

Andrew put together an example which involves an RGB LED being controlled by a dashboard app running on Pachube. The code was loaded onto the Nanode board and then it was plugged into the network router at the London Hackspace. Within a few seconds the Nanode had performed a DHCP request and had a IP address handed down to it. Andrrew loaded up his simple dashboard application with Pachube and soon he was controlling the colour of the RGB lamp completely remotely - see photo.

Andrews example is described in detail on his Blog here.

Whilst at the LHS we got talking with Martin Dittus, a regular member about how it would be really great to have a simple interpreted language running on the Nanode, so that users could set up their own scripts and modify how the Nanode is used for particular applications. The example I gave was similar to the old interpreted Basics, from the early home computers. Nanode has basically the same resources as those early computers - so why not a Basic like command shell.

Minutes later, Martin had a link to a project called bitlash, an interpreted language written specially for this sort of application and running on the standard Arduino. Bitlash takes about 14K of the Nanode program space, leaving about 16K for the ethernet and wireless functionality. Fortunately, bitlash is a true, serial command interpreter, and bitlash functions and scripts can be stored in EEprom or external memory, or provided across any serial link - which in Nanode's case would be a serial terminal window, or telnet running in a browser.

Bitlash has it's own API which allows the user's C program to interact with bitlash. After a few quick trial examples - I was reasonably convinced that bitlash running on Nanode would be almost ideal for our applications.

And so with two of the key elements of the Nanode project coming together we set of to "MiniBar" - a networking evening in Shoreditch.

Saturday May 28th

A bit of a foggy head after a lot of free Magners at MiniBar last night. Day spent loading Andrew's new EtherShield library into Arduino 0021 and looking at a version of Tiny Basic which runs in under 4K on the AVR.

Sunday May 28th.

The response for Nanode has been phenomenal and the batch of 100 initial version 5 boards have now been sold via the London Hackspace. A second batch of 25 has now been ordered to maintain a small stock.

Been looking more into Bitlash - this is a dream sent from heaven. It's exactly what the Nanode project needs to get commands and scripts over the web, wireless and other interfaces, via serial or telnet session. Here's what the Bitlash Wiki says:

The Bitlash embedded interpreter that runs in about 14k of memory on an Atmel AVR processor. It works nicely with Arduino to make a development and prototyping tool for those situations where you need to bang some bits on the Arduino but writing a sketch in C is premature. It's very convenient for bringing up and debugging new hardware.

The Bitlash command language is very similar to Arduino C and includes a large repertiore of the familiar Arduino C functions so you can hack your hardware from the serial command line or even over the internet via telnet.

You can store commands as functions in EEPROM and autostart them at bootup, making the automation and maintenance of small applications very easy.

A Bitlash enthusiast in the US is now storing and running bitlash scripts and functions from SD/MMC card. See here:

This language is so cool and opens so many doors for small products like Nanode. Time to stop blogging and get blashing!

Curious that an anagram of bitlash is HiBlast and so is Shit Lab - depending on how its going.

Saturday, May 21, 2011

RAM and MAC


Today I have been working on a couple of the newer features of Nanode 5 - namely the SPI SRAM and the MAC chip.

As part of the improvements over Nanode 2, it was decided to make provision for an SPI memory device - surface mounted to the underside of the pcb. This device could be SRAM, EEPROM, data flash or FRAM - the choice would be left up to the user.

Personally, I have chosen SRAM for this first board, as it is cheap and easy to use and I am using similar devices on a project at work.

However the 23K256 SRAM has a maximum voltage of 3.6V and the Nanode is 5V, in order to maintain compatibility with the Arduino. However this compatibility issue is starting to cause problems, and so I decided to reconfigure the board so that everything is powered from 3V3. I had also just received a new batch of MCP1702 250mA 3V3 regulators, so it was a good opportunity to test the board running on one of these regulators. More and more hardware seems to be going down to lower voltages in order to save power, so it is fitting that Nanode should follow suit.

Once the 3V3 rail was up and tested, it was time to solder on the tiny 23K256 SRAM chip - and the even tinier 11AA02 MAC device - which just looks like a SOT23 transistor. Above are the two devices soldered to the board underside. The thin green wire is a temporary modification to power everything at 3V3. The SRAM is fairly central, and the tiny MAC chips is to the south west of the SRAM.

Later on, I modified some example code in order to test the SRAM. It takes about 4 seconds to write to the whole 32K bytes. This isn't very fast - but quick enough for Nanode and the sort of HTML serving tasks likely to be encountered.

I was hoping to work on the MAC chip which uses a unique 1 wire protocol called UNI/O and only needs one dataline to communicate with the microcontroller. Unfortunatelythe Microchip server which serves their data sheets and application notes is on maintenance today and the code examples are not accessible. Tomorrow , I'm of to the London Hackspace with Sam Carlisle and Matt Gaffen, so I should have an opportunity to get the Nanode reading its unique MAC address.

Monday, May 16, 2011

Talking about Nanode - at OxHack. Sunday May 15th.

The one thing I like about Nanode is that it gets you out of the house. A chance Tweet from Oleg Lavrosky from OxHack, suggesting that I join them in Oxford on Sunday seemed a much better option than messing about in the garden.

Having packed my "hack-pack", grabbed my laptop, I bundled them into the Golf and set off around the M25 and up the M40 to meet up with Oleg and his friends in Cowley.

The irony was, that driving 75 miles to Oxford on a sunny Sunday morning is actually quicker and a lot less stressful than trying to cover the 20 miles from my house to the London Hackspace in Shoreditch by public transport.

I arrived in Cowley after an hour and a quarter, but for a variety of reasons, none especially important at this moment, it was about 4 hours before the hacking began in earnest.

By 2pm we were fed and watered at the fantastic Atomic Burger restaurant in the Cowley Road, I even managed to trade a couple of JeeNodes bare boards in exchange for my lunch, with Oleg's Hacker Pal, Ben.

We then headed around the corner to the offices of "White October" - a web design house with co-working space for startups.

Oleg was joined by half a dozen friends and fellow hackers, so I put the LCD projector together on a suitable stand and offered to run through the Nanode presentation, I had prepare for the Pachube Hackathon - about 5 weeks earlier.

You can see it here on Youtube - in 2 parts.

Part 1

Part 2


So instead of spending the day on Nanode documentation and in the garden, I was out promoting Nanode to one of the "up and coming" hackspaces.

Monday 16th May

Back to work with a usual 7:15am start at my desk. Today I had to get the Nanode boards ordered and make a start ordering the components for the proposed 100 off batch build for the weekend of June 4th and 5th.

Nanode in A Box - a self-fund - self-build model

The whole ethos surrounding Nanode is that of accessibility. From the outset it was designed with ease of building in mind - with the use of through hole components and DIL IC packages, it can be built by anyone with basic soldering experience. I have put together a step-by step guide on an earlier blog post.

Whilst the concept of open source software has been around for several years, it was probably the Arduino Project which effectively extended this thinking to the hardware arena. Software is easily downloadable and easily shared, but with hardware you actually have to make something. This process is simplified by the fact that pcb designs share a common file format know as Gerbers, and these are readily accepted by pcb manufacturers so that boards can be made readily. Many PCB manufacturers are offering low cost services for the amateur constructor.

With Nanode, I have chosen to upload the pcb Gerbers to Thingiverse - a repository for electronic designs.

You can find the files here.

The pcb ordering process could not be simpler. Some board fabrication houses have a complete online service on Ebay allowing you to use PayPal for your purchase and buy several of the pcbs at a discounted rate. One such service is Spirit Circuits which will produce a batch of 20 Nanode pcbs for approximately £40 via Ebay when you email them the zipped gerber files for Nanode 5.

You can then download a shopping list or Bill of Materials (BOM) of the electronic components complete with the part numbers for popular component vendors. If you pool purchasing for 20 sets of components, you can build Nanode for under £20 each.

Two weeks later you get 20 Nanode boards back from the pcb manufacturer, and you can then run a weekend workshop showing your fellow hackspace members how to put it together and connect it up to the net and run some apps. Any spare Nanode you have left you can sell and put towards Hackspace funds or use to fund the next batch of 20 units.

Nanode is currently spreading exponentially. I started by building one on a breadboard last August. In March I produced 10 on pcbs and in June there will be a further batch of 100. If it takes off, and continuies to grow at this rate, the whole of the world's global manufacturing output could be committed to producing nothing but Nanodes by April 2014 ;-)

Fortunately, this is unlikely to happen, but hopefully Nanode will evolve into a platform with similar popularity and offshoot projects in the way Arduino has developed.

Saturday, May 14, 2011

Nanode 5 - The Heat is On

The last week has been a fever-pitch of activity getting the Nanode pcb ready for volume production.

With at least 80 pcbs having been pre-sold to friends, associates and members of the London Hackspace, it looks like we will have to prepare for a somewhat larger batch.

Nanode is entirely open source, so anyone can take the zipped gerber files from Thingiverse and have a board or a small batch of boards made up by a pcb fabrication company. Alternatively if you start with the Nanode schematic, you can modify it to produce your own custom variant and re-purpose that for some alternative application. provided that all Nanode derivatives remain in the public domain, the spirit of Open Hardware is not breached.

Nanode 5 follows on from Nanode 2j, just 5 weeks later. In this time we have added a lot more functionality and hope that we have made a product that will address most peoples needs. Addition of a unique MAC ID, a serial memory device and a simple interface to a low cost wireless transceiver will greatly extend the capability of the original design.

A Week In the Life....

This week, mostly, I have been soldering......

It's been a busy week, with 2 new arrivals - Nanode 5 and a new DSP microcontroller board I am developing for work.

Sunday 8th May

Make hopefully final changes to Nanode 5 pcb schemeatic and layout. Send off to Roger Light so that he can add the London Hackspace logo onto the correct layer and give it a check over.

More tinkering with my solar heating controller code, and get a chance in the evening to cut the grass, which was way overdue because of my week trip to Wales.

Monday 9th May.

Receive files back from Roger, but notice that there are one or two areas of the screen print layer which could be improved. I edit just this layer and recompile the design to produce a zip file containing all the Gerber files and drill file needed for manufacture.

Tuesday 10th May

I contact Spirit Circuits in Hampshire to get a quote, and apply to have a free "Naked" pcb done as a trial sample to prove the design. The naked pcb is basically a low cost advertising device for Spitit Circuits, where they produce your board for free in 48 hours in the middle of a larger board which contains their latest ad-campaign messages. I send off the gerbers and get an email in the afternoon to say that my naked sample will be with me on the 12th.

Travel up to the Gypsy Moth pub near Greenwich Pier. Have an enjoyable evening of strawberry "Fruili" beers wit my nephew Adam and his college mates who were celebrating his 21st birthday. Get home a little worse for wear, having rushed across town on the DLR through Docklands and tube to Victoria to catch the 23:37 home to Redhill.

Wednesday 11th May.

First of the DSP/microcontroller boards arrives at work. I spend the morning building up the board and have it flashing LEDs by the afternoon. I had to order some thin solder (26 gauge) and some surface mount flux in order to make a reasonable job of the SMT assembly. Finished the day wishing that a) I still had the eyesight I had when I was 30 and b) wish I was a more competent C programmer.

Thursday 12th May

Complete the SMT build of the DSP board at work and continue testing. Arrive home to find that Naked Nanode has arrived! Too much eyestrain to start building it tonight - will do it tomorrow after work.

Informed the London Hackspace of a proposed "Nanode Weekend" for 4th and 5th of June. This will be the official launch of the Nanode, which will include a distribution of the kits, a DIY build session (with experts on hand) and a full day of instruction about the Nanode programming and Apps. If we get 10 people who can solder, I intend to set up a short production line, so that we can build lots of boards to a high standard in a relatively short time.

Friday 13th May.

Not a good start. For some reason the USB JTAG emulator I use to load code into the DSP packs up - after I unplugged it from the board. I spend 2 hours rebooting machine, re-loading drivers etc, only to find on the manufacturers website that this is a known issue, and it happens when you plug another FTDI serial device into the PC. If the JTAG, which uses the FTDI chip is removed, priority goes to the 2nd device and that stops the JTAG from being recognised. I spent half a morning dealing with this totally crap issue, which is so typical of the computer industry releasing badly thought through products.

As a consequence my 1pm Friday finish was delayed to 16:45pm, but I did get a lot more debugging done without the interruptions of phone and co-workers. I also sent off for an Ebay batch of Nanode boards, where you get a square foot of boards for £37. This works out at about £2 per pcb. These will be ready about May 30th.

Friday evening 6pm - time to start building up the Nanode 5 board and test it. Because of the lack of solder resist layer you need to be very careful soldering - as it is way too easy to get shorts between adjacent tracks and pads. By 7:30pm the board was running code on the ATmega and printing out readings to the serial window. A brief interruption to go for a pub meal with Elaine, and then back to debugging Nanode 5.

Unfortunately, the only 3V3 voltage regulator I could find was a very old Holtek 7533. These are only good for 100mA - which is really not enough to run the ENC28J60 ethernet controller chip. As a result the 3V3 rail sags to about 2.9V which is not enough for ethernet comms. I adopt a trick of using 3V3 "jump leads" from another Nanode board, and the ethernet springs to life - first with a successful response to a ping and then serving a full webpage.

Saturday 14th May

Intend to document some of the week's proceedings and work with the guys developing the Nanode application software so that its ready for the Nanode launch in three weekend's time.

Sunday 15th May

I expect I will be resting or pottering in the garden - as I am sure the grass will need cutting again.

Sunday, May 08, 2011

Nanode 5 - Progress Update


A bit of an early start this morning as my cat woke me at about 4:30am. By 4:50 I was up and starting to finalise the Nanode 5 pcb layout.

Nanode 5 will be the first commercially released version and it has undegone significant improvements since Nanode 2 - the first prototype board.

The Nanode development team has gained a lot of experience in the last month since the prototype was first shown at the Pachube Hackathon. We have taken the opportunity of these last 4 weeks to update the design and make sure that it meets all the expectations, and we have crammed in some new features.

Following our recent build session in Snowdonia it was decided that from the outset, Nanode 5 should make more use of wireless and be easily configured as an ethernet to wireless bridge. We have decided to take full advantage of a low cost wireless transceiver module by Jee Labs.

So I have updated the circuit and connectors slightly so that the Jee Labs RFM12B transceiver breakout board will plug directly into one of the Nanode expansion connectors. This board is available for about £11 as a full kit or £4 for a bare pcb from Jee Labs shop. With this board, the Nanode 5 functions just like the JeeNode with ethernet, so we can make use of all of the applications firmware already developed by Jean-Claude Wippler at Jee Labs.

One of the limitations of the ATmega328 processor is the 2k of RAM. This can be partially overcome by fitting an external memory device. The SPI bus lends itself to communicating with such devices with a low pin-count interface. On the bottom of the Version 5 Nanode board we have included a footprint which will accept an 8 pin SPI memory device. This can be SRAM, FRAM or EEPROM/Flash and accept devices up to 256Kx8. Extending the memory of the Nanode will be useful for many applications. The device can be purchased for about £2.

Nanode also has a footprint to accept a unique ID MAC chip produced by Microchip. This contains a 48bit unique identity plus 2k bits of EEPROM memory which can be used for storing the Nanode configuration etc. This device is 38p from Farnell.

As a result of the aim to have full compatibility between JeeNode and Nanode, we have had to move some of the SPI chip select lines around. Here is a quick list of the main I/O pin functions:

Digital 0 Serial Receive
Digital 1 Serial Transmit
Digital 2 Interrupt for RFM12 wireless and ENC28J60 ethernet controller
Digital 3 Interupt for Vusb - virtual USB
Digital 4 Virtual USB data pin. Servo control output, Display output with software serial
Digital 5 Used by Nokia 3310 LCD shield
Digital 6 /TXEN - enables the transmit line to local serial bus. LED indicator
Digital 7 Data input/output for MAC chip

Digital 8 Chip Select output for ENC28J60 ethernet controller chip
Digital 9 Chip Select output for SPI memory chip
Digital 10 Chip Select output for RFM12B wireless tranceiver module
Digital 11 SPI MOSI
Digital 12 SPI MISO
Digital 13 SPI SCLK

In addition to the above signals, the expansion connector also has +5V, 0V and +3V3 to allow the RFM12 module to plug straight in. Digital 8 and digital 9 have been removed from this connector as they are used internally by the ENC28J60 and the SPI SRAM as chip selects. They do however still appear on the Arduino shield connectors as standard.

As you can see a fully populated Nanode with ethernet, wireless, SPI memory and a MAC chip is going to be pretty much maxxed out in terms of available I/O. However a wireless only node, or serial node will have a lot more I/O available for the users sensor application - essentially 6 or 7 digital lines and 6 analogue inputs.

Of course a Nanode pcb can be partly populated with just the ATmega328, crystal and reset circuit and used as a very low cost Arduino clone. This could be a very cost effective way to get a load of work-alikes.

One of the projects whilst in Snowdonia was to develop a low cost single axis solar PV tracker. This uses a single radio control servo to angle a small PV panel directly towards the sun and record the power produced. Nanode 5 has a 3 pin connector which will directly take an R/C servo which is controlled by Digital 4.

Here's a short video showing the tracker working. Following a reset, the servo turns the panel to face east and then it searches in 10 degree steps for the solar power maxima. After completing the 180 degree search it returns to the maxima position - about 39 seconds into this clip. Once a minute (at about 1min 05), it then tracks east by 5 degrees and performs a 1 degree incremental sweep for 10 degrees to see if it can find a better maxima.



We have developed a fair bit of code for Nanode and this is now up on GitHub

The updated pcb artwork is very nearly completed and after checking this weekend will be released to Spirit Electronics so that a batch of 100 bare boards can be manufactured. This will take approximately 2 weeks - so we expect to have Nanode pcbs available for assembly about 23/5/2011.

Saturday, May 07, 2011

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.

Wednesday, May 04, 2011

Reinventing the Wheel

It's a case of what goes around, comes around.

This post takes a retrospective look at some minimalist computing solutions which have been historically significant over the last 45 years, - effectively - my lifetime.

It's a quick look back at the last four decades of computer development, highlighting a few significant events, and how they have become intricately woven together to influence the modern world.

Can we take a lesson from earlier times to make interaction with modern systems, more intuitive and easier for newcomers to learn "real" computer programming.

Mid 1960's

Around about the same time as I was conceived (late '64), MIT labs and Raytheon Inc, were contracted to come up with a digital control and guidance computer that would be used throughout the Apollo moon-shot program. Thus was born the Apollo Guidance Computer or AGC

The AGC was assembled from approximately 5600 individual logic gates - a brief specification was given as follows:

Word Length: 15 bits plus parity.
Fixed Memory Registers: 36864 Words.
Erasable Memory Registers: 2048 Words.
Number of Normal Instructions: 34.
Number of Involuntary instructions (Increment, interrupt, etc.): 10.
Number of Interface Circuits: 227.
Memory Cycle time: 11.7 microseconds.
Addition Time: 23.4 microseconds.
Multiplication Time: 46.8 microseconds.
Number of Logic Gates: 5,600 (2,800 packages)
Volume: 0.97 cubic feet.
Weight: 70 pounds.
Power Consumption: 55 watts.
The AGC was used in conjunction with a display/keyboard unit or DSKY which weighed a further 17.5 lbs.

Despite its basic specification, the AGC was used on Apollo missions right up until 1972, including the first successful moon-landing of 22nd July 1969. If you want to get an impression of the AGC it is well documented on Wikipedia, including this rather superb replica.


The 1970's

Approximately 6 years after the first moon landing mission, a young programmer, Paul Allen was on his own important mission. On a flight to Albuquerque, New Mexico, he was to meet and deliver a roll of paper tape to MITS, makers of the new Altair 8800 microcomputer system.

The tape contained a BASIC interpreter program, written by Allen and his business partner, William Gates, and it was the first real job for their fledgling company Micro Soft.

Allen even had to write a paper tape reader routine in 8080 machine code whilst on the plane, as in the rush to get the job done, he had forgotten to include the necessary paper tape loader routines to get the code into the new Altair machine. The original implementation fitted into just 4K of program memory, but was later expanded to 8K so as to include extra functions including trigonometric maths. This was the first implementation of a usable high level language on a hobbyist microcomputer, and the outcome of that meeting was to change the computing world for ever. Paul Allen and Bill Gates went on to deliver variants of BASIC for most of the early 8 bit microprocessor families, and their company grew into global giant Microsoft.

Paul Allen had a vast experience of mainframes and effectively devised an 8080 emulator to run on a PDP- 10. It was with this software tool, that the young Bill Gates wrote much of the original 8080 BASIC interpreter, and delivered it working to the client at MITS without ever having seen an 8080 system! Gates was certainly a smart kid. The same mainframe emulator was used to produce BASIC interpreters for most of the popular 8 bit micros.


A few years later, as far as I recall, in the summer of '79, microcomputers eventually arrived in the UK. My school had an early Research Machines 380Z (A CP/M Z80 machine) with a cassette interface and very little else. Software was lacking, but there was a BASIC interpreter and a few games written in BASIC. One was the numerical game "lunar lander" which had been around on programmable calculators for a couple of years - where you had to try and landd the lunar module, or crash and burn on the moon's surface through lack of fuel. Later a copy of Space Invaders written in Z80 machine code turned up from somewhere. It was just like the arcade game and very popular. A particularly geeky mate of mine taught himself Z80 machine code, aged 14 - so that he could manipulate and hack the variables within the space invaders programme to his advantage. However, I hadn't a clue what machine code was, and so I wasn't to write my first bytes of raw Z80 hex for another 2 or 3 years.

The 1980's

In 1981 a far-sighted teacher brought a ZX81 into the classroom, and I learnt to program (badly) in BASIC. As a sixth-former I ran an after school computer club for a couple of years in my spare time, and generally found many similar excuses to flunk my A levels.

The photo on the right shows the corroded remains of my ZX81 built from a kit in the spring of '83. I fitted a 2K RAM and a much bigger heatsink. It was put in a custom case and used to control a Turtle robot. It ran for about 20 minutes at a time from C-size rechargeable NiCads. Sadly it has been in a damp trunk for the best part of 25 years - so perhaps not looking in the best of health. I dug this out tonight, dusted it down, and perhaps one day I will clean it up and get it running - though I notice the ROM chip is long since gone.


The ZX81 was a fairly minimalist machine, consisting of the Z80A clocked at 3.58MHz, a custom ULA (uncommitted logic array) from Ferranti, the 8K BASIC ROM and either a pair of 2102 512 byte RAM chips or a 1Kx8. I fitted a newly affordable 6116 2Kx8 and gave myself a machine with 5 times the previous codespace (768 bytes of the original 1024 were used by the display leaving a barely adequate 256). At university, a friend and I made a FM wireless link between two ZX81 machines from a FM "bug", and were able to transfer programs from one machine to the other over the FM link using the quirky audio cassette interface.


During Live Aid in July '85, I remember I spent the day in front of small small black and white portable TV set, watching the bands whilst hand wiring a prototype Z80 control card - a 4MHz Z80 maxxed out with ROM, RAM, 8255 Ports, PIO, SIO, CTC and keyboard interface.

With 6 chips on the board it was about 4" x 5" and a mass of bus wiring - my own personal homage to early computer construction! A picture of the Z80 control card is below. It was built to run an electronic synthesizer project - so has 5, 8 bit ports, a keyboard scanner and a Z80-SIO and Z80-CTC to provide MIDI serial and counter-timer functions. It is striking to think that this is a very much slower equivalent of the likes of the Arduino MEGA.

Hardware certainly was hard 25 years ago - I remember it took me most of a week to design, build, wire and debug that board. I hand coded a monitor ROM from a version I had cribbed from another Z80 machine which allowed hexadecimal program entry and text output to a terminal.

The hand-wired "verowire" prototype is shown below, showing the pink wiring held in place by nylon combs. Just wiring 3 x 40 pin and 3 x 28 pin chip sockets took a lot of connecting up. I guess it might still run code if I apply power! The white socket on the bottom was to allow me to plug it into an early development system called a Multitech "Micro Professor" MPF-1B a Taiwanese built Z80 micro trainer that I bought in Edinburgh in the spring of 1984. Multitech Industrial Corporation later became Acer - another historical link. The MPF-1B is actually still available from Flite Electronics - 27 years after I bought mine!


The 1990's

What began in the mid 70's with the introduction of the 8080 - the first real microprocessor IC, heralded a succession of cheaper and more powerful micros from all the main IC manufacturers. Fuelled by the PC industry, we saw hardware, clock speeds and memory increasing yearly with every new generation of Intel x86 processor. It's hard to believe that we take clock speeds in the low gigahertz, RAM memory in gigabytes and hard drive capacities in terabytes for granted these days.

At the same time that PCs were developing there were rapid developments in embedded microcontrollers. In the 90's I worked with 68000, 8051, Z8, PIC and TMS320 DSPs. We had entered the era of system on a chip, where microprocessor core, program memory, RAM and I/O peripherals were reduced down to a single IC. The rather clunky Z80 board I built in 1985 could be replaced with a single 40 pin IC runing at about 10 times the clock speed of the earlier design. Microcontrollers were given a massive boost with reprogrammable Flash memory for program storage, and on-chip analogue to digital converters and simple PWM allowed a certain amount of analogue processing to be done. I recall in the late 1990's developing a single chip telephone modem device based on a low cost PIC, where all DTMF and modem tones were synthesized and decoded in firmware.

Into the 2000's

Some 30 years after Paul Allen's world changing business deal, some clever guys, Massimo Banzi and David Cuartielles at the Interaction Design Institute, Ivrea, Italy, put together a simple microcontroller board and introduced the world to the Arduino and the world of open source hardware and software. The Arduino core development team now consists of Massimo Banzi, David Cuartielles, Tom Igoe, Gianluca Martino, David Mellis and Nicholas Zambetti.

Ironically, the ATmega AVR microcontroller which runs the Arduino is almost identical in specification to the AGC, the Altair and the ZX81. A small board costing around $15 has the same potential processing power as the AGC which cost $15 million back in 1965. The ATmega328 which runs the Arduino is a mere $2 to $3. How far we have come in 40 years!

2010 and Beyond

So this retrospective post is by way of considering whether we can re-purpose some of the methods and techniques devised by early computer engineers to make their machines useful with a minimum of resources?

The reason that these particular machines and events have special meaning, is not only that they have been milestones in the personal computing industry, but they also mark major milestones in my own life. I recall being woken up at 4am on July 22nd 1969 to watch grainy pictures on a black and white TV set, of Neil Armstrong's decent from the LEM onto the lunar surface.

The other connection between them, is that the specification of the computers involved was roughly the same in terms of memory and speed of operation - there really is not a lot of difference in processing power between the AGC, the Altair 8800 and the ZX81 - just 15 years and about 70lbs in weight.

So this got me thinking about these early machines, how they were programmed and what could be done with them. The Altair and the ZX81 shared a BASIC interpreter, numerous BASIC dialects arose out of public domain code originally developed by Dartmouth College in 1965, and written for a GE 225 mainframe.

If Paul Allen managed to shoehorn a workable BASIC interpreter into 4K of code back in '75, how about doing the same thing for the 32K program space on the ATmega328. Back in 2008, an AVR enthusiast Klaxon44, wrote a BASIC interpreter in C and successfully ported it to the ATmega128. Capable of some 50,000 empty loops per second, it wasn't lightning fast, but good enough to run interpreted commands from the serial link. Had the BASIC interpreter been coded directly into AVR machine code, and not in a round-about way involving compiled C, it would have been many times faster.

To anyone who grew up with the early home micros, the ability to edit programs on the fly, and type commands directly at the keyboard which would be executed immediately was a neat way of program interaction. Klaxon44's version allows direct manipulation of the ports, so you can write to the I/O directly for testing hardware such as LEDs and sensors directly.

We've come a long way, even since my early coding days on the ZX81. We now have self programming flash memory, and SPI devices which only need four signal connections to connect them. SD cards and wireless modules allow easy storage of large quantities of data and allow simple communication between processors. Imagine a simple BASIC interpreter running on an Arduino which could be used to introduce school kids to the basics of programming and controlling electronics with simple keywords, - without having to first learn embedded C!

BASIC is no substitute for C, but it is certainly easier to lhttp://www.blogger.com/img/blank.gifearn, debug and is more forgiving than C with it's finicky syntax and over-zealous use of punctuation marks and various types of http://www.blogger.com/img/blank.gifbrackets.

I don't want to re-invent the wheel, but is there not a case for a easier way to interact with and program embedded microcontrollers?

AS I write this, it seems that there is a new kid on the block - Raspberry Pi a tiny linux ARM based computer expected to sell for under $25.

A video of the Raspberry Pi and founder David Braben appears on the BBC on May 5th 2011.

Could this be the future of minimalist, easy to program, real computers?




Tuesday, May 03, 2011

JeeNodes Arrive!





The JeeNode kits I ordered just before Easter have turned up.

I ordered 2 JeeNode kits and 4 bare pcbs, which I will make up as and when I need them.

During the Snowdonbuild, we used JeeNode extensively to act as a wireless "shield" to complement Nanode.

Jean Claude Wippler at JeeLabs has written some neat code to allow a JeeNode to run the Microchip ENC28J60 ethernet controller. This is the same one we use on Nanode, which makes it fairly straightforward to get code to run on both systems.

JeeNodes use the RFM12 wireless modules from Hope RF. These are available very cheaply as "Alpha" wireless modules from suppliers such as Maplin in the UK.

In the next week I hope to duplicate some of the developments from the Snowdonbuild and get my JeeNodes transferring data from my solar water heating system back to an internet connected Nanode.

The JeeNode kit is very easy to build. It took me under an hour to build the first pair, pause for a ham baguette and then test out the RFM12 Demo sketch which comes preprogrammed into the ATmega328. I have not yet fitted the port connectors - because I have yet to decide whether I want these to plug into a breadboard or some sort of a connector on the Nanode.
The success of running the 16MHz JeeNode at 3.3V makes me wonder whether I should run the Nanode at 3V3 to reduce power consumption significantly and to simplify some aspects of the design.





Monday, May 02, 2011

#Snowdonbuild - Final Day

Day 6 of #snowdonbuild - a unique collaborative project in open hardware and open software, held in rural Snowdonia.


The remote farmhouse in Snowdonia, which has been Snowdonbuild HQ for the last 6 days.



Most of the team, Bethan, Sam, Glyn, (PV Panels) Matt, Trystan, Suneil - and Ken behind the camera.

So we've nearly come to the end of the build session - and judging by the lack of bodies at 8:30am - it seems that last night might have been a late one!

Today is the day that we pull all the project threads together and put together a full system and documentation.



The "Bothy" extension to the farmhouse, which forms the accommodation and lab areas.

The team prepare to line-up for a final mug-shot by the solar PV panels.


Over the last few days we have built a solar PV monitoring system and used the Nanode to control a simple solar tracker.



Making full use of the popular wireless JeeNodes, Glyn and Trystan have incorporated the JeeNode wireless functionality into the Nanode, and also devised ways of configuring the Nanode from a web browser.



Sam has been looking at the server side of things, and found ways of making very efficient web pages from minimal amounts of served HTML.


Matt has been working on various drawings and artwork, which will be used on the new Nanode and openenergy websites, and throughout the documentation pages. Here's an example of a Nanode graphic that Matt has produced to help illustrate some of the Nanode documentation. As an attention to detail - the resistor colour codes are actually correct - Nice one Matt!




Suneil has built up a veroboard version of the solar PV measuring circuit, so that it can be plugged directly into the Nanode to make a simple demonstration board which anyone can copy.


And on the last day, I was mainly responsible for lunch - a real feast of porkchops and sausage casseroled in Strongbow Cider and Chardonnay - with mountains of potatoes and gravy.



Back Row. Suneil Tagore, Ken Boak, Matt Gaffen, Sam Carlisle.


Front Row Trystan Lea, Glyn Hudson (Photo: Bethan)




In all, we had six developers working on collaborative openenergy and Nanode hardware and software projects for the best part of five full days, and two half days. At times the development work continued to 5am (Sam holds the endurance record) and restarted at 7:30am.


The outcome of the exercise is a strong development team with a wide variety of skills and expertise - who have proven that they can work together efficiently on exciting open source energy projects. I hope that the Snowdonbuild 2 is the first of many such collaborations.



























































Sunday, May 01, 2011

Nanode Serves Solar Monitoring Data


Day 5 of #snowdonbuild - a 6 day collaborative Open Hardware and Open Software hack session.

To further develop Nanode and Open Energy Monitoring Applications - held at a remote farmhouse cottage in rural Snowdonia.

After a morning of intensive hacking here in Snowdonia, the Nanode solar monitoring system serves its first web page with solar data.



As a reminder of the set-up we have here, there is a small 1W solar panel mounted on a wooden frame with a single axis solar tracking system driven by a standard size radio controlled servo.

One Nanode controls the solar tracking algorithm, and is powered from a solar charged 3.6V NiMH battery and super capacitor. The solar generated power, and the serial communications is connected back to the lab area using a 15mm length of telephone extension cable - this was mainly for convenience, as neither my LCD digital scope, used for measurements, nor my laptop screens are particularly visible outside in the sunshine.

The serial output from the measuring Nanode, is connected to the serial input of a Jeenodes wireless module. Glyn has written a small interpreter programme to run on the Jeenode, which takes the 5 fields of comma separated integer data relating to solar voltage, current, wattage, tracking angle and temperature, and converts them into a byte packet format which the JeeNode uses for over air transmission.

The data is received by a RFM12 module connected to a master Nanode, which is in turn connected to the internet. A byte packet decode scheme, takes the off-air data and reconstructs it into the 5 measured arguments.

The Nanode then serves these data fields up to the web, so that they can be viewed by any browser.

The solar data is also served up to the EmonCMS graphing server for long term storage, we have added the graphing capability which is generated by the EmonCMS energy monitoring system server and it is from this server that the graphical data is served.

The bandwidth and update frequency of the Nanode means that it is best used for serving small packets of numerical data, and not data intensive images.

Because we just handle integers at the moment the voltage is actually 5.32V and the temperature is 21.9C.

We've had the solar tracker running since early this morning logging the solar data to file. Although this is a very small scale system it can be easily extended to monitor full size solar installations.