I've recently been contacted by a friend with a request to help design and implement the hardware for a race timing system for his local swim club. I jumped on the chance, it's a good opportunity to test the Clixx.IO system for real world prototyping and gives me a chance to document the entire prototype to production process on this site.
The majority of my work on Clixx has been using the Raspberry Pi as a host but this is overkill for this project - something a bit smaller is needed for the hardware components. An Arduino compatible system is perfect for the job - fast enough to handle the task and having access to the full Arduino IDE and supporting libraries will be a big plus when I hand the project over.
It also gives me the chance to pay some more attention to an older project I have neglected for some time - the Babyduino system. I first described this project back in Febuary and built it up to the stage where it had full integration with the Arduino IDE including bootloader compatibility and library support. I have built and used a few using the (unfortunately rather poorly designed) boards I had made but it's not something I have worked with recently.
I took the opportunity to build a few more from bare boards, load the bootloader and test them with some simple sketches. Everything works perfectly which is a nice feeling. I cringe every time I look at the PCB though so it's time to do a bit of a redesign. Apart from cleaning up (and shrinking) the PCB there are a few other goals I'd like to achieve as well:
- Make it easier to use with the Clixx system (and more specifically, the home-brew modular docking system I developed.
Ensure it will fit the requirements of the timing project so it will be easy to move from prototype to production without a lot of code or circuit changes.
The rest of this post will cover those issues in detail and then present the circuit and PCB for the Mk 2 Babyduino.
The Clixx.IO system is flexible enough that in essence any system can be considered compatible. That being said there are certainly things that can be done to simplify the use of Clixx with a particular controller board.
One thing I would like to avoid is the rats nest of wires that can grow out of connecting arbitrary pins on the controller to various Clixx Slots and Docks. Because I already have some nice reusable Docks with well defined pin mappings available I'd like to change the design so that these can be connected with simple flat ribbon cable. The goal is a nice one to one pin mapping that results in a neat looking prototype as well as minimising the chance of bugs appearing because wires are not connected to the right pins.
The new PCB will have two 11 pin connectors (one down each side), one will map to the connectors for the general dock, the other for the SPI dock. The general dock has a single I2C slot and support for extending the number of I2C slots using the I2C Extender dock.
The reasons for choosing an SPI dock over another general one are mainly personal - I tend to use far more smart peripherals than directly controlled IO pins, the lack of an SPI port on the general dock (see the post about the docks for the reason) means that the only way to provide SPI connectors is to use the dock dedicated to that purpose.
This isn't a real limitation, the general dock gives you access to two digital slots (or one digital and one analog depending on how you configure the pins on the Arduino side) which should be enough for most projects. If you need more you can use an IO expander in one of the I2C or SPI slots.
Race Timer Requirements
There are two requirements for the race timing system that need to be taken into consideration in the new design, neither are particularly onerous and both will be applicable to other projects as well.
Some of the components in the timing system are required to be portable and, ideally, be powered by 3 AAA batteries. This means we can't run the ATMega chip at the full 5V (the plan is to use a MCP1700 3.3V regulator). The ATMega will happily run at this voltage but not at 16MHz - the master clock should not be run any faster than 8MHz. The current Babyduino bootloaders are already configured for this setup so there will be no changes required there.
The internal oscillator on the ATMega chips can have up to 5% drift (that can be reduced to around 1% with calibration (PDF)). For most applications this isn't a problem, I use the internal oscillator for almost all of my projects - none of them have a requirement for high precision timing. The race timer project does have this requirement though - it's not intended to replace competition level systems but it does require consistent and accurate time measurement down to 1/100th of a second so a reliable oscillator (or some external timing source) is a necessity.
Although the original Babyduino system had support for an external ceramic resonator I have dropped support for this as a way to save some space on the PCB. The internal oscillator will be sufficient for prototyping, I'll add an external crystal to the swim timer when it's ready to go to it's own board.
The programming interface will still require an FTDI cable that plugs into a six pin header on the PCB - unlike the previous revision the TX and RX pins from the CPU will not be routed to the external dock headers but will only be available on the FTDI header. If you require serial communications to an external device you can use the SoftwareSerial library to convert one of the digital slots into a serial slot. The idea is to leave the primary serial interface available for debugging or remote control purposes.
A two pin header is available to provide external power (alternatively you can power the device directly from the FTDI cable - this will be the most common use case during development). You cannot connect both power sources at the same time though.
Reset functionality is also provided through a two pin header - connecting a button to this header will give you the same functionality as the on board reset button on a standard Arduino. Performing a reset via the FTDI connection is not supported - you will have to manually reset prior to loading sketches.
A final change is removing the status LED. On the Arduino this is on pin 13 by default (physical pin 19 or PB5 on the ATMega8). This pin is also the SPI clock pin for the ATMega hardware SPI controller and I'd like to dedicate it to that purpose. For simple debugging output the serial port will have to do.
Bootloaders and IDE Integration
The bootloaders will remain much the same apart from the status LED which will be disabled. Once again the system will support three variations of the main CPU - the ATMega8, ATMega88 and ATMega168. The fuse bits will be set to use the internal clock.
The boards.txt file will need to be updated to include the three different configurations - these will all appear as 'Babyduino Mk2' in the IDE board selection menu.
The Final Circuit
The final schematic can be seen in the image to the right. Pin mappings for the slots have been selected to simplify the board layout wherever possible while still routing special purpose pins to the appropriate locations on the docks.
The analog slot for example has a hardware PWM pin assigned to the 'input' pin and an ADC input assigned to the 'output' pin. On the ATMega side both of these pins can be configured as pure digital pins allowing you to use the slot as a digital slot instead if you need to. Using the SoftwareSerial library I mentioned above you could also configure it as a serial slot which gives you a lot of flexibility with a single slot.
The MISO, MOSI and SCK pins are routed to the SPI dock adaptor and should always be used with the AVR on-board SPI controller. The SDA and SCL pins are routed to the I2C slot on the generic dock which allows you to daisy chain I2C docks to get additional pins. If you are not using I2C in your project these can also be reconfigured to be generic digital pins which gives you an extra digital slot.
Pins that are not routed to external connectors include TX and RX (as mentioned above these are available on the FTDI interface only), the SS pin which is used for slave select when the AVR is running as an SPI slave, the XTAL1 and XTAL2 pins even if you are not using an external oscillator and the RESET pin (which is pulled out to it's own jumper for an external reset switch).
The pin mappings for the generic board adaptor are as follows:
Slot |Dock Pin|Slot Pin |AVR Pin|Arduino Pin -----------|--------|-----------|-------|----------- 0 (I2C) |3 |3 (Extra) |4 |2 0 (I2C) |4 |4 (SDA/In) |27 |A4 0 (I2C) |5 |5 (SCL/Out)|28 |A5 1 (General)|6 |3 (Extra) |26 |A3 1 (General)|7 |4 (In) |16 |10 1 (General)|8 |5 (Out) |25 |A2 2 (General)|9 |3 (Extra) |24 |A1 2 (General)|10 |4 (In) |15 |9 2 (General)|11 |5 (Out) |23 |A0
The I2C slot could also be used as a digital slot if I2C support is not required. The general slots can be used as either digital or analog (both of them have the slot output attached to an ADC on the ATmega).
For the SPI dock the pin mappings are as follows:
Slot|Dock Pin|Slot Pin |AVR Pin|Arduino Pin ----|--------|---------|-------|----------- 0 |3 |3 (SCK) |19 |13 0 |4 |4 (MOSI) |17 |11 0 |5 |5 (MISO) |18 |12 0 |6 |6 (CS) |14 |8 0 |7 |7 (Extra)|13 |7 1 |3 |3 (SCK) |19 |13 1 |4 |4 (MOSI) |17 |11 1 |5 |5 (MISO) |18 |12 1 |8 |6 (CS) |12 |6 1 |9 |7 (Extra)|11 |5 2 |3 |3 (SCK) |19 |13 2 |4 |4 (MOSI) |17 |11 2 |5 |5 (MISO) |18 |12 2 |10 |6 (CS) |6 |4 2 |11 |7 (Extra)|5 |3
Pins 1 and 2 on both slot connectors are GND and VCC respectively. This version of the Babyduino will run happily with either a 3.3V or a 5V supply voltage so you can pick the appropriate voltage to suit your requirements.
I've designed a PCB for the new design and sent it away for fabrication (you can see the PCB layout in the image to the right). It generally takes a few weeks for the boards to come back - I'll report on the success (or failure) of the design then. In the meantime I'll simply wire up the docks to my original Babyduino boards and use them for the initial prototyping.
I've updated the GitHub repository with the new bootloader code, board definitions and Fritzing projects for new board as well - you can get all the assets required to build your own version from there.
Apart from some simple tests to make sure it all works as expected the majority of the time I spend with it will be related to the race timing system prototypes - you'll see a number of posts about that as I progress (although it looks like a simple project there are some interesting technical challenges to overcome).
I'll also be using it as a basis for some of the future Clixx.IO related articles, although the Raspberry Pi is a great platform for quickly testing and prototyping hardware I'd like to show off the cross platform abilities of the Clixx system as well.