The article, Designing A Small Peripheral Module Standard, generated a number of response including on from Rob Gray, a Quubist (One who engages in the act of building embedded QUUB microcontrollers). It turns out there are plenty of designers with a similar idea and Rob executed on his design. The result was QUUB, a tiny, stackable, "quirky" (Rob's description) controller system. It is a well documented project and I asked Rob to provide some insight into his design.
QUUB takes aspects from many platforms including Arduino (see Arduino Expands Into More Demanding Applications) including stackability. More on the Arduino tie-in later.
Also, if you are looking for compact projects then check out Raspberry Pi. It's a PC with an ARM processor on an HDMI stick with a target price of $25. Plug it into an HDMI display and it draws power for the system. USB and Ethernet connectors take up more space than the electronics.
So here is the interview with Rob about QUUB.
Wong: What is QUUB?
Gray: QUUB is a Small Form Factor processor and co-processor design like this ATMega1284-AU based core processor board (Fig. 1). The basic system topology is that of a "core" processor and up to 16 addressable daughter boards known as "stackables". Stackables can be smart (with co-processors) or dumb (just hardware IO).
All boards share a 48-pin bus which is split into two 24-pin stackable headers. Boards can be in any location, for example the core processor does not have to be at the bottom, normally it would be but there may be applications that require a different order, such as a small robot where the bottom board has the motors, gearboxes and driving electronics.
The name QUUB comes from the fact that up to four boards can be stacked and still fit inside a 2x2x2" length of aluminum extrusion.
Wong: Why did you design QUUB?
Gray: Quite apart from just being an interesting design exercise I had a need for a monitoring and control sensor/actuator network system that allowed me to easily distribute the processing power around a serial network.
Wong: What were the design goals?
Gray: Small - The boards are 1.8x1.8" (approx. 46x46mm). My feeling is that even the current so-called "Small Form Factor" designs are too large. Maybe there's room for a new term, "Tiny Form Factor".
Networking - The system should allow easy networking of modules. By "networking" I do not mean Ethernet, rather various combinations of SPI, I2C, RS-422/485/232, LIN, CAN, USB etc. To this end core processor boards have two "comms sites". These are connected to the core processor's various sync and async serial ports and allow the insertion of tiny daughter boards (called "Commints", a short form of Communication interface). Commints usually just have line drivers appropriate to the serial interface being used although more complex functions can be performed by them as well. This allows a given core processor design to be easily re-tasked from say RS-232 on one port and RS-485 on the other to maybe USB on one and CAN on the other by just plugging in different Commints.
Addressable daughter boards - I like the Arduino platform but I do see one major flaw in the design, that being that you cannot combine many shield types because they use the same pins. Also, you cannot use two of the same shields unless the designer has allowed for jumpering of the signals the shield needs to alternative pins (and most don't).
Therefore I felt that the design should have addressable daughter boards. The QUUB allows for up to 16 such boards in a stack although current designs limit this to 9.
Smart/dumb daughter boards - Daughter boards can be either smart or dumb. While the basic tenet of the design is to distribute the processing power there are many applications that just need a little more IO and the overhead of inter-processor communications is an overkill. Therefore QUUB stackables have three basic types, addressable intelligent co-processor, dumb hardware that is addressable (say an IO expander chip) and dumb hardware that is not addressable (maybe just buffers or even no active components at all, just connectors).
All three types can co-exist but of course if you use non-addressable stackables you may have the same pin clash issues the Arduino has.
Low-speed backplane - QUUB is not intended to be a high-speed bus like PCI/SUMIT et al. Those high-performance busses have their place but that's not everywhere and anyway by distributing the processing there is less need for high speed.
An example may be a robot controller; it can have an intelligent stackable that controls 16 servos, all the core processor has to do is command the stackable to say move servo #5 from 45 to 98 degrees over a period of 3 seconds. The core processor is then free to get on with its main job while the co-processor controls all the servos with almost no load on the core processor and no need for high bandwidth on the backplane.
Using the same robot example another stackable may be tasked to monitor ultra-sonic distance sensors and only inform the core processor if something gets too close.
I call this "set and forget IO".
The fundamental inter-processor communications link on the QUUB backplane is SPI, with I2C being an option. Therefore speeds are in the order of a few MHz serial, not fast by today's standards but more than enough for small projects.
Interrupts - Having set and forget IO is all very well but if the core processor has to poll the co-processors you lose much of the advantage. Therefore QUUB has an interrupt protocol defined.
A co-processor can interrupt the core processor and provide an interrupt vector (its priority level) as a response to an acknowledge from the core processor. In the case of simultaneous interrupts the stackable with the highest priority (ie lowest value) will be serviced first. This is similar to the Z80 system although the "vector" is really just a number used by the core application to address the interrupting stackable.
Note that there are only three signals allocated for the interrupt vector, thus only eight co-processors can use the interrupt feature.
Cheap - QUUB is designed to be cheap to build, the standard enclosure is a simple length of aluminum extrusion, and custom faceplates can be laser cut from thin plate in any material. Another aspect of the design where price and availability are factored in is the backplane connectors; these are standard Samtec 2x12 stackable sockets with a 0.1" pitch, also the Arduino-style 1x6 sockets can be used.
Processor agnostic - The QUUB design is independent of processor family, largely because it's not trying to be too clever or too fast. To get full performance the core processor and all co-processors should have a hardware SPI port; however bit-banging will work as well. Current designs feature an ATmega1284, ATmega328 and a Picaxe 20x2.
Enclosure - As mentioned the standard QUUB enclosure is simply a length of 2x2" aluminum extrusion. Provision is made for a connector at the rear of the core processor boards. This connector carries network and power signals and it is designed to allow bulkhead mounting of the enclosure with no visible wiring. This mounting style is good for displays, RFID entry panels etc.
Power supply - As the QUUB will often be powered directly from 12- or 24-volt battery systems and these can reach 30 volts under charge all onboard QUUB regulators must be able to handle a VBAT of 7-30 volts (the lower value allows the use of 7.2-volt batteries in applications such as robots and model aircraft). This VBAT signal will run up the backplane so a stackable can be designed to control the power for the whole stack. Thus a stack with a human interface (say a touch panel) or a real time clock can have soft power on/off capability for the entire stack.
Debugging - QUUB has support for multi-processor debugging built into the system. It's not an all-singing all-dancing solution, more a simple method of getting information out of the system and onto some form of display device. To facilitate this the backplane has 4 signals dedicated to debugging.
At the most primitive level these signals just connect a slave processor to a LED on the core board so an application program can flash the core processor's status LED or toggle signals to trigger a logic analyser. At higher levels the signals can be used to drive say a serial LED or LCD display or connect a full- featured monitor program running on the co-processor to a PC via the port USB port on the QUUBugger (Fig. 2).
The QUUBugger is a special stackable that is similar to the extension boards used on many stack- and rack-based systems. It allows a board to be worked on outside the QUUB stack. It also provides a USB interface for monitor programs.
The unusual design of the QUUBugger PCB allows both sides of a stackable to be accessed with the board outside the stack. The "jaws" of the QUUBugger can be snapped off and reconnected with a 50-way ribbon cable thus allowing the board being debugged to be more conveniently placed on a workbench. The QUUBugger features its own processor which provides a USB gateway to a PC for the co-processor being debugged.
All relevant backplane signals are broken out to headers for easy connection of a logic analyzer or other test instruments.
A further tool for debugging is QUUBmon, this is a small-footprint monitor program that allows access to co-processor variables and registers with almost no intrusion into the application program.
Processor programming - Another aspect of multi-processor systems that is often not addressed is programming of the various co-processors. When developing with two or more processors it's common to make many changes to all of them and this either requires several programmers or the constant unplugging and plugging of a single programmer. Also these boards are so small that adding an ISP header can have a major impact on the available board real estate.
Therefore QUUB allows any co-processor to be programmed in situ using the SPI signals on the backplane.
IO connectors - Small form factor boards will always have problems with large amounts of IO connectors. QUUB is designed to allow two sides of the PCB to be free for connectors. At 1.8" wide a QUUB stackable has room for 36 standard .1" pitch headers (18 on each end) if the board is extended slightly to clear the backplane connectors.
Without such extension there is room for 28 headers.
Of course with modern small-pitch connectors more IO can be accommodated.
This stackable features an ATmega1280/2560 co-processor (Fig. 3) and implements 45 hardware IO channels, each with a 3-pin GVS (Ground,Volts,Signal) header. The board is larger than standard to allow more connectors and also to place them outside the enclosure.
Wong: What lessons did you learn building QUUB?
Gray: I learned that these days you can pack a lot into a very small space. In my previous life as an embedded designer this sort of design was a total pipe dream.
After many years out of the embedded game I found that everything had changed yet everything was still the same. By that I mean that we are still dealing with the same devices, RAM, UARTs, parallel IO, timers, etc., the capabilities have increased somewhat but in general the actions required of a software engineer are the same.
What has changed is the integration. What used to be a board with 20 chips is now a single component. I find this to be good and bad. Good for the obvious reasons, size, cost and the fact that all the low-level timing issues are dealt with by the chip manufacturer. Bad because it's no longer possible to connect a logic analyzer to the bus to diagnose the data flow to and from a peripheral device.
Wong: What changes would you like to make to the system?
Gray: JTAG debugging. I'm still not convinced this is required mostly because the majority of processors used with QUUB are small and many don't even have JTAG capability. However there are the four debug signals on the backplane so this should be relatively easy to add at the system level although often not so easy at the chip level because the JTAG pins usually have other functions.
Debugging in general. The current debugging system requires the core processor to be running to control the co-processor access to the debug signals. This control should be moved to the QUUBugger processor. From a debugging point of view all processors should have the same status.
Also I need to look closely at the hardware interface on the QUUBugger. It needs to allow the connection of any debugging device from any processor family. It probably already does because I use an analogue MUX to switch the four debugging signals to the outside world and these in turn can be connected to whatever debugging device you choose. But this part of the design does need some deep thought.
VBAT on the backplane. Currently VBAT does run up the backplane but there is no provision for a stackable to intercept it and provide power supply control. I think this is worth looking into.
Other core processor support. I'm a self-confessed AVR freak and this system has basically been designed around the capabilities of several AVR processors albeit with an eye to being a processor-agnostic design. I have designed core processor boards using PIC and Picaxe processors but that's been done strictly from data sheets, not from first-hand knowledge.
Maybe the MSP340 has a great feature that could easily be incorporated and currently would not be supported by the backplane pinout.
Maybe processor X cannot be programmed with low voltage on the SPI signals.
I could answer these sorts of questions myself in time but someone familiar with these (and other) processors will do so faster and better.
Wong: So what is in your future with regard to small form factor design?
Gray: I'm going even smaller. My current project is an RS-485 based monitoring and control network with Arduino-compatible nodes. These nodes have a standard size of 40x40mm (1.6x1.6") but test designs have been done down to ½" square using larger (SOIC, SOT23 etc) SMD components and even smaller should be possible with less human-friendly components.
In general the processing power available to us today makes the products I thought of in the 80s and 90s possible. To have real distributed processing, right down to the light switch level, is now both possible and practical.
This is a very exciting time to be involved in embedded microcontroller design.