Stackable shields

If this has been touched on, please point me to the thread.

I was wondering if there has been any though on stackable shields. What I mean is I can see there being conflicts on shields and pins if one wants to stack more than one shield on a arduino. There are not a lot of shields out yet, but I can see this becoming a problem in the future.

I was thinking jumpers on a shield could sort out this problem, letting the user set a jumper to decide which pin on the arduino actually connects to io on the shield. The jumper would have to do 2 things. connect the io and short the pin so it does not pass through to the next shield.

Seems like that would increase the cost of a shield, but not by much, but it may take up a bit of space.

The other option I though of was designating a set of pins for certain purposes... lots of problems with this idea, how many for what... etc...

A combination of the two could work too, say pins 2-8 for sensors(input) a few pins on the shield decide, and all other pass through the next shield.... pins 9-12 for output, again with pins, analog io on analog 0-5 again with a few pins...

For the user it seems like a simpler option than having multiple arduinos for multiple shields... not that I'm trying to turn these into legos... I'm curious to hear your thoughts on this... cause I'm a newb, and I'm probably over simplifying.

It would certainly be nice to make it easy for people to stack shields, but I don't know if it's clear the best way to do that. A lot of shields have specific requirements about which pins they use (e.g. the PWM outputs), and many use all or almost all of the pins. Also, it can be expensive just to use the long pin header that allow you to physically stack the shields. Still, I'd love to hear more thoughts on this, it could be good to come up with some guidelines.

ive got some stacky headers in the shop if people are interested in playing with them
i haven't had a good reason to stack stuff (yet) but i figure people have been asking about it ...

I haven't tried this yet, but I was thinking about those long pin headers being hard to find. A workaround would be to have two rows of through-holes for each bank of headers, offset by the same distance (this bit is critical). One set of holes (e.g. the lower set) would be for standard male headers to plug into the lower board; the other set of holes would be for standard female sockets for the next board up. One could flip-flop which set of holes got used for which (e.g. lower set male on one, then lower set female on the next) so you get a zig-zag effect instead of the leaning tower of Pisa.

Maybe not as neat/pretty/compact as the wire-wrap headers, but it would use standard parts.

-j

ladyada, your new motor controller board actually got me thinking about this.

I can easily see a small autonomous vehicle using an arduino, your motor/stepper/servo board on top... but anything autonomous will need sensors too... so another shield with a few bump sensors, a pir, maybe an ultrasound.... while I'm at it why not another board for gps, or wireless so it can report back on its scouting.... I'm sure I've run out of pins by now, but you get the idea

There are probably a lot of reasons to stack shields.

Maybe the best(and cheapest) option is to just make pins selectable via jumpers to help avoid a conflict? Then if someone wants to stack boards its up to them to use stacky headers where needed?

A different solution could be a protocol? I've seen one that was pretty clever, you configured each device(in this case a shield) to listen to pin x as device 0, 1, 10, etc... then rest of the byte was the command.... then you just share the pin.... that saves a lot of output pins.

Kg, your idea totally works, but what about two shields needing the same pin... thats the part where I think jumpers would be helpful.

Jumpers would be ineffective with more than a couple of pins and you'd have limited choice.

The only way I can see many shields working at the same time in harmony is by having a small processor on each shield.
Then they can communicate over I2C or similar.

This has the benefit of the person who builds the shield already has the tricky code done for you and you only need to talk to the processor. :slight_smile:
And timing for things like USB also becomes a non-issue.

Shields should pass through any pins they don't use, and some coordination would be required to make sure that the different shields use different pins.

Another (less than elegant) solution would be to allow a row of through-holes for the Arduino pins and another set of through-holes for the devices on the shield so that the user could jumper to unused pins, but that's yet another set of holes to take up space, and would cause problems writing a library for the shield (since the software would need to know where the pins are actually connected).

Maybe all the shields should just use I2C and I/O expanders. :slight_smile:

-j

I just found a great example of a very simple solution here, Totally user configurable... with just a few wires.
http://www.ladyada.net/make/eshield/wire.html

I think the simple solutions are often the most elegant, kudos to you, ladyada.

While that does work, its nowhere near as cool as making everything I2C with its own controller. ;D

What would be the additional cost/development on the average shield though? Would the I2C pins be shared for every shield, or would you need to identify pins for each layer? With shared pins how would each shield know which commands to respond to and which to ignore?

I'm sure my lack of I2C knowledge can be loud and clearly ;).. more for more to read up on..

I2C is a shared bus, so only those two pins (plus a signal ground, of course) are needed.

-j

Right, but with a shared bus, how would a shield know that 0x80, 0x100, was meant for shield 1, not 2 and 3.... this wold require a protocol correct?

Again, my newbness might be showing, but the idea of jumpers(or wires) solves the problem, and does not create any new ones... I'm not sure about I2C. Can you elaborate on I2C?

Basically I2C uses two wires and allows you to connect up to 128 devices to it without any complicated wiring.
The extra cost would be a couple of dollars. Something small like a ATtiny2313 would be suitable for most shields and its dirt cheap.
Plus DIP switch or something to select the address of the shield.

Its a great protocol. The Wire library makes talking to each device really easy as well.
You just say who your sending the data to and it handles the rest.

The real advantage is that you can never run out of pins and that you still get all the special pins (SPI/PWM/Serial/etc).
It would also simplify connecting shields and using them.

Sounds like a great interface. Would it really be that cheap to add I2C to a shield?

I recently saw an I2C LED going for like $12.95 a very nice LED, but say the LED was worth .50c thats $12.45 for the rest(I2Cand a tiny board)

The LED looked something like this
http://search.ebay.com/search/search.dll?query=50-PC-5mm-8Kmcd-Common-Cathode-Super-Flux-RGB-LED&MfcISAPICommand=GetResult&ht=1&ebaytag1=ebayreg&srchdesc=n&maxRecordsReturned=300&maxRecordsPerPage=50&SortProperty=MetaEndSort
I'm sure if quantity they would be cheaper.

Well for LadyAda's motor board for example it would only increase the price by about 3 dollars.
~$1.45 for a ATtiny2313 for the I2C interface and ~$0.75 for a DIP switch to select the address.
Those prices are for single quantities. Cheaper in bulk.

if you look at the schem, most of the motor control pins are for the PWM channels. theres only 3 pins that are used for 'data' - and those are behind a latch - clk, data, enable and latch.
turning into some i2c deal would thus save you a grand total of 2 pins.
unless you wanted to, say, put -everything- onto another microcontroller. in which case you would try to do the PWM on the attiny2313 and have that controlled via i2c. and the attiny2313 only has 2 timers by the way, whereas the atmega168 has 3, so you'd have to do the PWM in software which means tons of fun debugging that and i2c communication at the same time. especially difficult when the user wants 8-bit PWM is at >20khz!

also, where are you getting an attiny2313 for $1.45 in qty 1? and a 8-pos DIP switch for $0.75 in qty 1? :slight_smile:

+$3 in parts cost -> at least +$6 in final cost.

for example:
$0.40 led + $0.80 PCB + $1.80 chip/passives for i2c = $3 raw cost
$3 * 200% wholesale markup = $6
$6 * 200% retail markup = $12 final cost

unless you wanted to, say, put -everything- onto another microcontroller. in which case you would try to do the PWM on the attiny2313 and have that controlled via i2c.

Exactly. :slight_smile:
Makes the library controlling it far simpler and frees up timers.
Was it you who hit a snag with the timers and delay()?

and the attiny2313 only has 2 timers by the way, whereas the atmega168 has 3, so you'd have to do the PWM in software which means tons of fun debugging that and i2c communication at the same time. especially difficult when the user wants 8-bit PWM is at >20khz!

Well the ATtiny2313 was a example. There are enough different chips to fill any need. :wink:

also, where are you getting an attiny2313 for $1.45 in qty 1? and a 8-pos DIP switch for $0.75 in qty 1? :slight_smile:

Futurlec. :slight_smile:
Cheap shipping too.

In quantities of 100 the prices are $1.05 and $0.60 respectively.[/quote]

well, it sounds like a fun & interesting project. let me know when its done & ill check it out! ill look into integrating it into my designs if its robust

Futurlec. :slight_smile:
Cheap shipping too.

In quantities of 100 the prices are $1.05 and $0.60 respectively.

i wont copy and paste a 5-page long email thread i've had regarding orders placed with 'em, suffice to say, the prices are good because you're unlikely to ever get the parts.

i wont copy and paste a 5-page long email thread i've had regarding orders placed with 'em, suffice to say, the prices are good because you're unlikely to ever get the parts.

Heh. I've always gotten my stuff. Sometimes it takes a little while if you order one of their boards (waiting on a 3.3v switching regulator board atm) but the components come fast.