Although my initial design for an external dock for Clixx.IO has been very useful I've found I need a little bit more flexibility with a wider range of host devices. To that end I've come up with a new design which is a bit smaller but allows you to combine docks to get anywhere from 3 to 9 slots (depending on the hardware capabilities of your host) and as many I2C slots as you need.

Design Overview

The first major change is a reduction in the number of available slots per dock, it's gone from 6 to 3. I found that the original design with two columns of 3 slots was a little too large for most projects (and the horizontal spacing between the slots was not always large enough to accommodate Tabs side by side).

Bare Docks

This reduction in slots also reduces the size of the host connector (from 20 down to 11 pins), the size of the PCB (it now fits in a 5cm x 5cm board so you can get 10 of them made for $US 9.90 by the Seeed Fusion service) and the time it takes to print the plastic case.

For projects that need more available slots you can use multiple docks on the same host system - each dock includes separate power out headers so you can connect more than one dock to a system and share the power supply.

There are three variations of the dock - a generic version where each slot can be assigned whatever function you like (one slot is optimised for I2C - it routes the SCL and SDA signals to an external header to allow daisy chaining), an I2C only version that can be connected directly to the host micro or daisy chained from the generic dock and an SPI only version that provides the additional sidecar pins required for that interface (more on that issue below).

The Generic Dock


This dock provides 3 TwinTab slots with all pins available to the host. The slots can be used for any purpose (analog, digital, I2C, serial) but slot 0 (the one closest to the connection header) provides an external jumper to daisy chain additional I2C slots using the I2C dock (described below).

This will probably be the most often used version of the dock because of the range of slot types it provides. Although there are only 3 slots that should be enough for most small to medium sized projects.

The pin definitions are outlined in the following table:

Pin|Usage ---|------------------------ 1 |Ground 2 |VCC 3 |Slot 0 Extra Pin 4 |Slot 0 Input Pin (SDA) 5 |Slot 0 Output Pin (SCL) 6 |Slot 1 Extra Pin 7 |Slot 1 Input Pin 8 |Slot 1 Output Pin 9 |Slot 2 Extra Pin 10 |Slot 2 Input Pin 11 |Slot 2 Output Pin

An additional 4 pin jumper is provided on the edge of the dock to allow additional I2C docks to be daisy chained. The pins on this header are as follows:

Pin|Description ---|----------- 1 |SCL Pass-through 2 |SDA Pass-through 3 |VCC 4 |Ground

The I2C Dock


This dock provides 3 TwinTab boards with an I2C interface. The dock has been designed with maximum flexibility in mind - it can be used as a standalone dock (with a micro-controller in TwinTab format controlling as the I2C bus master), directly connected to a host in conjunction with one of the other dock types, as an extension to a generic dock or as an extension to another I2C dock.

This dock is optimised for projects that use a lot of smart peripherals or based around a CPU with a limited number of GPIO pins. There is no real limit to the number of these docks you can daisy chain - you may need to drop to lower communication speeds if you use more than one or two though.

The pin definitions are outlined in the following table:

Pin|Usage ---|---------------- 1 |Ground 2 |VCC 3 |SDA 4 |SCL 5 |Slot 2 Extra Pin 6 |Slot 1 Extra Pin 7 |Slot 0 Extra Pin

An additional 4 pin jumper is provided on the edge of the dock to allow additional I2C docks to be daisy chained. The pins on this header are as follows:

Pin|Description ---|----------- 1 |SCL Pass-through 2 |SDA Pass-through 3 |VCC 4 |Ground

The SPI Dock


The SPI dock provides 3 TwinTab format SPI slots. This design was a late addition - the format for TwinTab SPI tabs changed recently to allow for individual slave select lines and an additional data pin for each SPI peripheral. This was accomplished by adding an additional two pins in a 'sidecar' attachment to the normal 5 pins of a standard TwinTab. This new board format will be described on the Clixx.IO site soon.

The new layout does allow the use of standard TwinTabs in the slot (the additional two pins remain unconnected). This dock design does not support that however - the 3 main SPI connections (SCK, MISO and MOSI) are connected as a bus to the appropriate pins on each slot. This decision was made to keep the dock design consistent and relatively small.

The pin definitions are outlined in the following table:

Pin|Description ---|----------- 1 |Ground 2 |VCC 3 |SCK (SPI Clock) 4 |MOSI (Master Out/Slave In) 5 |MISO (Master In/Slave Out) 6 |Slot 0 Enable 7 |Slot 0 Extra 8 |Slot 1 Enable 9 |Slot 1 Extra 10 |Slot 2 Enable 11 |Slot 2 Extra

Unlike the other two docks this one does not have any additional headers. SPI cannot be chained in the same way that I2C can as it requires a unique SE (slave select) pin for each slot.


I'm working on some 3D printable cases for these docks but it is taking a little bit longer than I expected to get it right. I'll put up another post on the topic once it is completed. In the meantime the docks can be used by simply attaching some rubber feet to the bottom to help avoid accidental shorts.

Connecting the Docks

Connecting the docks to your device is simply a matter of using female to female DuPont cables to connect the pin headers together. There is no official pin mapping that you have to use, for compatibility with existing Clixx.IO products you should probably use the same pin mappings that they do.

I am working on an update to my Babyduino system that is optimised for use with these docks - I'll document that on this site when it's complete.


These docks deserve a better write up than the bare technical specifications I've given here and I'll follow up on them in future posts (preferably with real world projects using them). Unfortunately the PCB order took longer than normal to come through and included a number of other components that need to be built up and documented as well so time is a valuable commodity at the moment.

Once I've completed a set of usable cases I'll put up another post with some more details and examples - with a corresponding update to the GitHub repository. These really are handy little units to use, a big improvement on my earlier model.