[Gghc-discuss] Conceptual design of electronics for duinolab - please provide feedback quick

[Jonathan Manton]

Preface - I want to finalize the chip selection for the initial prototype and start designing circuit boards ASAP.  So give me your comments on this by Monday, so I can order parts and we can have a chance of having a first prototype built next weekend.

-------------------------

The electronics supporting duinolab have the following functions:
- Manage the display on the LCD (I am assuming a graphical LCD for more "bling" value)
- Get inputs from buttons next to the LCD to implement a menu system (How many buttons?  What is shown on the LCD anyways?)
- Control the LEDs that indicate what is connected to what.  18 I/O lines, x 4 LEDs/line = 72 LEDs to control
- Switch 6 analog inputs to either connect to the connected arduino or not
- Switch the 6 digital inputs to either connect to the connected arduino or not.  Low current switches.
- Switch the 6 digital outputs to either connect to the arduino or not.  Higher-current LEDs.

Below I state my proposal.  It is based on what I know about already - there may be better solutions/components, but this is what I've come up with.  I'm totally open to alternatives, as long as we can quickly identify and source the alternative components.

My suggestion is that we run the board electronics using the I2C (2-wire) serial interface.  There will be another arduino that listens to that, plus other peripherals as stated below.  I picked I2C over SPI simply because we only have 2 pins to run the serial interface (SPI takes 3 for one-way, 4 for bi-directional) and we don't need the increased speed of SPI (~ 10Mbit/s vs. 400Kbit/s).

Graphical LCD
- Generic-ish 128x64 graphical LCD supported by this library:  http://www.arduino.cc/playground/Code/GLCDks0108
- Tons of sources (see chart of supported devices on link above) - my default is always SparkFun (I know Erich doesn't agree) - http://www.sparkfun.com/products/710
- The SparkFun serial version of this is panned pretty badly in their comments, so I'm assuming we get the parallel one and directly interface to it using the library linked above
- Takes 13 digital I/Os

Inputs for buttons
- Use small, less impressive buttons directly mounted to circuit board
- Need 1 I/O per button - for planning assuming 5 buttons

LEDs
- Cheapest option I've found in a monolithic device is SAA1064, which can run 32 LEDs per chip at $2.79 ea. (DigiKey)  We would need 3 of them.
- Use I2C (2-wire) interface, meaning we can control them directly from the user's arduino

Analog switches
- Use a MAX4549 ($8.87 at DigiKey).  This is kind of overkill (it is a 3x 3:2 audio crossbar, rather than a switch), but the part I wanted to use (3x MAX4584 2-port switches) is both more expensive and has too small lead spacing to make the boards at the fablab.  Could also use MAX4571 or MAX4572 if we can find a supplier (no stock at DigiKey)
- Can control directly from master arduino

For the digital I/O we could go a lot of different ways.  My suggestion is for the GGHC, we go with the easiest solution to implement, which is to just use two of our Arduino Uno boards to power the electronics in the duinolab (so the prototype would have three arduinos - one that the user is programming, and two driving our electronics).  One handles the LCD + menu buttons (18 I/Os), the other switches the LEDs and buttons (12 I/Os).  "Switching" in this context just means using the high-impedance input state or outputting 0V or 5V (whatever is necessary) to "switch" the second terminal of either the LED or button.

For the "final" version of the board (done some time AFTER GGHC), we use an ATMega chip that has enough I/Os (30+), and uses a fablab-friendly package (at least .4mm gap between pads).  For example the ATMega 165P (54 I/Os, $6.41 at DigiKey).  We would have to recompile the arduino firmware and design a custom board and stuff for this to work, which would kill our schedule for GGHC.  But in the long run it would make the solution about $50 cheaper, so it would have to be done.

So, to summarize this long-ass post, we would have a block diagram that sort of looks like:

Arduino provided by user -> I2C bus to communicate with everything else

I2C bus -> arduino powering LCD
I2C bus -> arduino switching digital I/Os
I2C bus -> 3x SAA1064 to control LEDs
I2C bus -> MAX4549 to switch analog inputs/output


In the "final" version (after GGHC) we would replace the two arduinos with a single custom-designed board that uses something like an ATMega165P running a recompiled version of the arduino firmware.  We could also use the option of running the analog switches and LED controller from this second board at that time, and maybe choose some components that cost less.  But for GGHC, the components I specified appear to be the simplest to get up and running fast and write software for.