Prospects: Arduino DUE

Yes, it's finally out, and I definitely scrambled to be one of the lucky to get one from the Maker Shed.

I've been waiting for this thing for over a year.  At the beginning it was just the prospect of more hardware ports (namely serial and I2C) that I was interested in, but as more specs and details were revealed, I was pleased and intrigue.  What follows in the specs that I'm most interested in and how they apply to the DPHP.

525% Faster

Specifically, the clock rate of the DUE is over 5 times that of a normal Arduino/Mega/Teensy/etc.  This doesn't include some of the operation efficiency increases because of the 32 bit processor.  I'll probably do some calc time comparisons once I get the code base going.  I can also comfortably use a single processor, where some of my previous designs with the Teensy had one processor for animation work, and another one for HUD and system management.

12x the RAM

While the minimum variable size has gone up, the DUE still has 3x the memory by comparison to a Mega or Teensy.  This means that I can make the trade for higher memory usage,  and get faster code operations.  Normally, the more numbers you can store, the less you have to manipulate the number 'in place' or with multiple operations, which takes more steps and longer overall.  More efficient code and faster processor means more time to do more things or more complicated tasks.

Two I2C ports

This is the big one that first got me all excited.  The DPHP uses Rainbowduinos to drive the main display, and these rely on the I2C protocol for sending display data to each of the Rainbows that make up the display.  Most large scale LED display use SPI because of the high data rate, however I2C for the rainbow and the 12 bit color it uses is quick enough.

The only problem has been that I2C is also a great protocol for connecting multiple Arduinos into a 'local network' for the various ancillary components that make up the suit for the helmet.  Specifically, the Arduino Wire library is one of the few one out there that enables 'slave mode' so that the 'main' controller can recieve 'pushed' updates from any of the other controllers on the network.  The alternative is a 'pulling' system that is normally used, whereby peripheral I2C devices are polled for updates or sensor samples.  This way, when there is an update to the system, like a button has been pushed or power system has a problem, it can 'push' relevant data to the main controller, rather than the main controller wasting time polling all the devices looking for updates.

So back to the problem.  One I2C port is really needed for full time 'display' duty, and likely will be at or near data saturation.  With a second port, where the other devices are more likely to send updates and thus the controller is primarily a receiver.  The second port the DUE helps keep that bus relatively open for the random point in time that update will arrive, where with everything on a single bus would mean more chance of collisions.

Four Serial Ports

Really, the Arduino DUE and Mega have more like 3+1 serial ports.  One of the ports is your serial port to the computer, and it's generally a good idea to leave the port open for debugging purposes.  You can use it, but I make it a habit on the more capable Mega/DUE/Teensy to not use the port for talking to anything but the computer.

Where I see the biggest advantage is in talking wireless devices.  I have grand plans for XBee radios talking to some wireless projects in the future.  I had planned to impliment the XBee with the Teensy++, but that chip only has one Serial port on it (the second port is a through the USB only for the terminal and programming, it cannot be used to talk to a device).  But that would be the only serial device I could setup.

Something I think would be interesting to impliment would be WiFi.  It would be less proprietary and more cross capable than the XBee radio.

Form Factor

Funily enough, the form factor of the DUE might be helpful compared to the Teensy++, even though the Teensy is a smaller component.  The problem I was having with my board layout is that I had to fit two Teensy's on the board, and that put a large density of through hole via into the middle of the board.  These via took up a good deal of space and made routing traced around them quite difficult.  The DUE will put all the signal pins on the periphery, and may make packaging easier.  Time and trying it out will tell.

Audio

This was deifinetely something I wasn't expecting.  The DUE supports playback of .WAV files.  I may be able to integrate a 'simple jukebox' that is easyily controlled from the DUE and the HUD since I won't have to interact with an external device.  I've considered devices like the MP3 Trigger from Sparkfun for this role, but that particular device is quite large.  With the internal audio library, I'll just need the footprint of a microSD card.  Testing will tell what the processor usage is for this particular feature.

Built in Scheduler

Also a nice feature I wasn't expecting.  Arduino has put in provisions for running multiple LOOP functions, allowing for a level of protothreading from what I understand of how the code works.  I probably won't be using this option over the threading library I discovered recently, as that one has the ability to add and remove threads during run time, which the Arduino library doesn't seem to support.  That is a particularly useful feature for adding/removing animations based on user input.

Overall, should be a fun piece of kit to use and more suited to what I'm trying to accomplish.