The goalposts keep moving!

The microprocessor has been with us for some time now, on my radar since 1974 with the release in April 1974 of the Intel 8080 which I first applied only a few months later. So I grew up and was 'educated' before the microprocessor. In those early days the choices were minimal, Motorola introduced the 6800 a little later in 1974. Despite protestations to the contrary that one or the other had some great technical or architectural merit it was really a matter of religion which path you followed. You could make a choice then being comfortable that it would hold good for a few years.

More recently the same religious fervour is evidenced by the proponents for the Freescale (formerly Motorola) 6800/6802/6809 ancestored chips versus Microchips PIC and Atmels much newer 'C' code optimised AVR and megaAVR. Each has its benefits, but logic defies any choice other than the one that I like!

But now the game has a completely new set of rules. ARM, of Cambridge UK, has turned the world upside recently with the introduction of the Cortex-M3 IP core. In a very carefully staged collaboration with Luminary (now part of TI) we saw the introduction of the Luminary Stellaris parts - the first M3's. Now everybody is on the band-wagon! Atmel (ATSAM3 is Cortex M3 based), TI through the acquisition of Luminary, NXP with the LPC17xx series, ST Microelectronics STM32, Toshiba and a new Norwegian startup - Energy Micro. All good viable companies, and don't count Energy Micro out, although only 2 years old they have some well experienced talent from Chipcon (now part of TI) and Atmel.

So now we don't get each manufacturer offering us a new architecture - we get them offering us different customisations and peripheral mixes all based on the same CPU core and interconnection fabric.

Oy vay!

Arduino/Leduino mechanical drawing

The Arduino concept, and our own LEDuino, have been a great success. But one persistent difficulty I see is the lack of an accurate board outline drawing. At least supposedly "authorative" template I have seen had errors. So based on the Eagle files of the official Arduino Diecimila I created a layer in my EDA package that has the dimensions that as far as I can tell are accurate. This PDF file is a copy of that layer. Unfortunately I do not use Eagle but if you do, feel free to translate my drawing and I can happily post it on my site if you want.

Atmel Xmega - some more thoughts

Work continues here in the background on a small development platform based on the ATXmega128A1. One very interesting point which becomes salient with these devices is the peripheral multiplexing issue. Until now the functions available on each pin were minimal - you used a pin as IO or you might assign it to a timer, or a UART.

But with the Xmega we have more choices, how many UARTs can we use while using various SPI or TWI ports? Which functionality do we lose by choosing some other function? Lots of fun and something that we have been insulated from in the AVR world.

LEDuino in the wild.

Well, the first LEDuinos are making their way into the wild. The very first shipment went to Australia. I hope the unit enjoys going back to my home country! Response so far has been very gratifying. We are working on some application examples using the LEDuino specific capabilities, more news soon.

Arduino field to get a new entry

For some time now my colleagues and I have been using Arduino ( http://arduino.cc ) style hardware based on the Atmel ATmega168 processor and a very easy to use development environment. The Arduino IDE environment is flexible enough for much rapid prototyping work, but simple enough for non-technical people to use, in fact it was originally designed for teaching design students how to build interactive projects.

The more we used the system, the more we liked it. But the more we used it the more we found we were missing some things we take for granted on our more sophisticated development platforms.So why not add some interfaces to the Arduino to make it more usable in a variety of applications?

So we sat down and figured out what we use most commonly. Thus is born the LEDuino.

• Buffered I2C bus for longer cable runs and higher bus current operation. So we added an IES5501 bidirectional driver.


• We play a lot with designs for model railway layouts. Already we use a lot of DCC, so we figured that a standard DCC decoder input, complete with basic acknowledge facility. So we added that with full galvanic isolation both ways for convenience.


• In a number of situations we use CAN Bus. Several developing or proposed model railway layout control busses use CAN, so we figured we could be compatible and give ourselves a simple development platform for that too. CAN is also used in a variety of other fields where we have some professional involvement.

So why the name LEDuino?

Well, one of our engineers develops a lot of LED based technology for architectural, visual effects and signage, he often wants to talk to serial interface devices like the TLC5940 from TI. So we added an entirely custom connector on the bottom edge of the photo, it has a serial interface that is designed to mate with some of our other products. As time goes on some of these products will be added to this range of products.

So this is it, the beginnings of a new range of Arduino inspired technology which is in fact already well proven, well used, and well liked.