The Quub, new ATmega1284 processor board & sys

I've been sitting on this for a while and have decided it's time to see if anyone is interested before I go any further.

The current state is that most circuitry has been defined, the 1284 core processor PCB has been layed out and other PCBs started, however I'll be redoing the core PCB so can make changes.

The basic features are as follows.

  • Designed around AVRs but should be processor independent, core processor boards are being designed with AVR ATmega1284 and 328, PIC 18F2520 and Picaxe 28x2 at this point.

  • Arduino compatable (electrically and program wise) depending on the core processor used.

  • Adapter to allow any core processor access to Arduino shields.

  • Tiny form factor, 1.8 x 1.8 inches (46x46mm).

  • Fits with up to three daughter boards into a 2x2x2" aluminium cube (hence the name).

  • If not using 2x2" tube for an enclosure any number of daughter boards can be stacked (above or below the core processor).

  • Up to 9 (expandable to 16) daughter boards can be addressable (optional) and can therefore share the same processor IO lines.

  • Daughter boards can be dumb IO or intelligent co-processors.

  • Core and co processors talk with SPI.

  • Support for co-processors to interrupt the core processor with a priority system.

  • Up to two "communications areas" on core processor boards that can connect directly to USB or serial cables + provision for tiny interface boards for line drivers (RS-485/232, LIN, CAN etc).

  • Cable connection for power and network on the underside of core processor boards so the enclosure can be bulkhead mounted with no visible wiring.

  • 48-way backplane using stackable headers that has up to 32 IO signals, plus power, debug bus and 4 uncommitted user signals.

  • VCC and VBAT can be sourced from the main board, any stackable daughter board, either communications areas or the rear connector.

  • Provision for in-system programming of any co-processor (AVR at least, maybe others depending on the requirements) via the backplane using the SPI signals and a PGM control signal.

  • Provision for simple debugging of any processor via four debug signals on the backplane.

  • Low(ish) power options, for example stackables daughter boards can have provision to cut power from IO circuitry and enter sleep mode or th ecore processor can cut power from individual stackable boards.

A fairly complete description of the system with schematics for most boards can be found at

Note that most of the descriptions are written in present tense, this does not mean something already exists, it will just save me from rewriting when it does :slight_smile:

All code/designs etc will be open source.

Any comments welcome.


OMG, I thought from your subject line that you were going to put 1284 processors in a 2"x2"x2" cube :slight_smile: That sounded pretty impressive (and impossible).

How will you retain shield compatibility and also have 16-board addressability? If you are talking over SPI as you say then won't you need at least 4 I/O lines "stolen" for chip select decoding?

Perhaps a block diagram would help.

The Gadget Shield: accelerometer, RGB LED, IR transmit/receive, light sensor, potentiometers, pushbuttons

put 1284 processors in a 2"x2"x2" cube

Now that would be a good trick.

How will you retain shield compatibility and also have 16-board addressability?

As the stackables can be used with only 5 IO lines the rest are free, they are of course subject to the usual clashing issues but there are probably enough free to allow coexistance with many shields.

The current adapter design just routes the signals and therefore doesn't help in this regard, however I do have plans to make the adapter itself addressable so Arduino shields appear at a single address. Just how practical this is I'm not sure as all 19 Arduino IO lines would have to be isolated and possibly pulled high/low when not selected.

If you are talking over SPI as you say then won't you need at least 4 I/O lines "stolen" for chip select decoding?

The "chip select" (called BRDEN) comes from the decoder chip on the daughter board, therefore only 3 SPI lines are needed. On a smart board this would go to the SS input of the processor, when using an IO expander to the EN pin, and on a dumb board it is used to enable tri-state buffers.

I'll work on a block diagram to (hopefully) make it clearer.

Here are some block diagrams showing the 4 ways I see stackables being used.

Dumb logic. Not addressable, just 32 IO lines read directly by the processor.

Dumb logic. Addressable, number of IO lines used depends on the design but all are tri-stateable so boards can share signals.

Addressable and semi intelligent with an IO expander chip, uses 5 backplane signals.

Addressable with co processor, uses 5 backplane signals.

So the worst case is that stackables use a heap of pins and the same clashing issues apply as with Arduino. Best case is only 5 pins are used (still allows up to 16 daughter boards on those 5 pins) and there's a good chance Arduino shields can be used as well.

It may be worth analysing a heap of shields to see if there's any grouping of pins used and ensuring that the 5 I need are on other pins to decrease the odds of a clash. The 3 SPI pins of course cannot be moved but software SPI could be used at the expense of speed.

put 1284 processors in a 2"x2"x2" cube

Now that would be a good trick.

Shouldn't be too tricky :smiley:
Use 328s in 32QFN package with a 4 layer board and you might even be able to break out some pins from each one!

Anyway, looks like a cool idea!