Shield-Duino

There are a lot of things that the ATmega CPU on an arduino could be programmed to do, relatively easily, that are a bit ... exclusive ... of having the arduino do other (normal) things. They might have tight timing requirements, use up large amounts of the available CPU time, use timers in ways that conflict with analogWrite(), and so on. Multiple servo motors, multiple serial ports, and large display (video or LED) refresh are typical examples. Yet the Arduino environment is known and understood, and it would seem a shame to require a special purpose shield to do the same thing that an arduino could do.

So... What do you think about putting the basic Arduino core (16MHz Atmega168/etc) ON A SHIELD. Essentially a "slave" arduino, or an arduino "co-processor" based on Arduino...

It would communicate with the main arduino by serial or SPI. It could be programmed by running a special "relay" sketch on the main arduino, or by ICSP, or by unplugging the 168 and plugging it into a real arduino. It would tap power from the main board, as per most shields, and replace the power and usb areas of the normal arduino with a prototyping area for additional circuitry. The PCB could double as a "reduced" arduino "runtime board." Ardunio shield connectors would stack, and new connectors would show up "elsewhere." Even mere pin expansion would be reasonable; a shield board with an ATmega8 wouldn't be THAT much more expensive to build than a shield board with a couple if 74hc595s, and it would be a LOT more flexible.

What do you think ?

http://picasaweb.google.com/lh/photo/aNIGofgMSIJ6i17Xtshedg?feat=directlink

I think the link is broken. :wink:

Works fine if your logged into picasaweb as me :slight_smile:
Fixed? maybe? It's just a rough draft picture anyway...

I like it!

What about having two set of headers? One that are just brought up from arduino host, and on from the Shield-Duino. one could easily just jumper some connections for communication and such.

So that one could stack an additional shield on top of shielduino.

It would communicate with the main arduino by serial or SPI.

I wouldn't take the one UART on the arduino - make it "I2C or SPI".

I've got a couple of prototypes for a similar shield, but the design is a dedicated UART.

-j

As far as programming the slave board, I often use my arduino as a glorified programming dongle for an off-board ATmega running the bootloader. It just needs 5 jumpers from the Arduino to the slave board for power and pins 1, 2, 3 (reset and serial). It would be problematic to have the main MCU and slave MCU in the circuit at the same time.

At some level I like this idea, but at another, I'm tempted to say just go with a dual core Arduino for the same basic result.

dual core Arduino is "just" dual... this could be "multi" core, if designed correctly, right?

this could be "multi" core, if designed correctly, right?

Yes, assuming SPI or some multi-drop serial protocol. But mostly it probably equates to an easy way to make a stock arduino into a "dual core" arduino.

What about having two set of headers?
So that one could stack an additional shield on top of shielduino.

Yes, that's the plan. The original arduino shield connectors would stack, and the equivalent connections form the "coprocessor" would go somewhere else. (next to the proto area in the pcb pictured.) That lets you add additional shields to the original arduino, but doesn't let you add shields to coprocessor.

I would definitely go with I2C or SPI.

Also, I guess I see no value in all these shields that "bring up" the ICSP headers from the original board-- if a user wants to reprogram the processor downstairs, then they should unshield and reassemble afterwards. Otherwise, why is this a shield to fit the removable headers?

As for layout, I would like the child board to have a little bit of proto space on the east end, too. Maybe reduce your 4+4 to 3+3 on the west end and add 2 columns on the east end. The user could then put in components, jumpers, or angled headers for middle boards or even straightup headers for the penthouse of the tower.

I see no value in all these shields that "bring up" the ICSP headers from the original board

The original (and followon) Zigbee shields use the ICSP header for power (grr.) Several shields (mostly proto shields?) that pre-date diecimila use it to extend "RESET" of the arduino to the shield (button, or for bootload-via-shield capability.) I don't like it either :frowning:

I like the idea; I haven't needed to slave Arduinos yet, but I recently bought a couple of old barebones boards to make some "reduced" boards. A couple of suggestions:

  1. Allow a FTDI cable to program any slave by putting the 6 pin header (or just a footprint for it) on the board; there's no extra circuitry required so its a no-brainer! And if you are going to be slaving a bunch of arduino boards, its more economical to have that logic in the cable anyway. This gives you a "reduced" board that is shield compatible, which is what I think is most important for "project finished" (but maybe just one last tweak!) arduinos.

  2. Expose the I2C or SPI or whatever you choose for the A-2-A communication on the sides (2 or 4 sides) with some sort of side-to-side connector so that you can checkerboard these slave boards on the plane (whereas the normal shield is stacked above the plane).

  3. Make the slave's pins shield compatible. Perhaps you could extend the breadboard area a bit to allow another shield to fit over it. This could allow the original arduino and the slave to both have shields. If that's too big of a board I think that you should still place the pins in a shield-compatible manner so the user can choose whether he wants to plug a shield into the slave pins or the master arduino pins. After all, if he wants a shield on the master pins he could always put it under this board.

Also, if you combine ideas 2 and 1 you can then tile arduino slaves on the horizontal and have shield stacks rising up from any of them!

Also, if you combine ideas 2 and 1 you can then tile arduino slaves on the horizontal and have shield stacks rising up from any of them!

As much fun as it is to picture, there comes a point where it's just so much easier to integrate a netbook or even a pico-ITX board into your project.

I know! I am constantly amazed by people who have incorporated arduino + shield extender + input + OLED + Xbee to make a $20 radio control.

But look, it opens up cool possibilities at hacker fests where everyone can plug all of their stuff together...

...but most importantly I think that my suggestions are each individually useful:

Making the slave shield compatible. I don't think I really have to defend this one. There is no benefit to NOT having it shield compat since it comes with breadboard space.

Adding FTDI serial header + shield compatible = the cheapest barebones shield compat board, and also means you don't HAVE to use the board as a slave which might be nice as a person's projects change.

Side connectors -- well the original idea was to connect slave Arduinos so my idea is only a way to move the slaves out of the way of other shields. I don't think that 1 row right angle connectors are that expensive

One problem is that the Arduino form-factor is pretty limited on the amount of space you have at the edges for putting connectors, especially if you're trying not to interfere with the "tall" components on the main Arduino board...

This is a pretty neat idea. A couple of thoughts:
-- Tying it to the form factor seems limiting. What you might want to be able to do is to chain devices where the slaves are cheaper/lower power/simpler etc, or separated by a cable. On the other hand, having it as a shield has benefits too.
-- Given a goal of chaining processors, does this devolve into a communications protocol problem?
-- This thread is connected to that problem: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1237661816/0#0