This documentation is a work in progress, please visit often for changes. You can use the history tab right above to look for changes.

Introduction

The Freeduino Cube is a rapid hardware prototyping system. The concept is to provide a stackable platform for building many different microcontroller based sensor and actuator applications. The software is also to be modular and reusable between each application. PC boards are expensive to manufacturer in small quantities (esp. qty=1). Since the hardware is reusable prototype boards can be reused and it will be likely that most of the boards will be needed in larger quantities driving down the overall cost. The same can be said for software reuse if the software modules are generic enough to be reused.

Hardware Architecture

The hardware is split into 4 major board types, compute modules, power modules, automation bus modules, and application modules. Each module will have a standardized role to play in both hardware and software design.

Physical Size

The footprint of the Cube is similar to that of the Arduino (NOTE: this is the goal, I’ll update this section when I’m done with board layout)

Board Interconnect Bus

The boards are stacked by a series of headers and sockets using "nearly" the exact same configuration as the Arduino Diecimila product so that Arduino shields and software are compatible with the Cube. The very simplest application can be assembled with just two boards using standard headers and sockets. However, most applications will require a third board. To accommodate multiple levels of stacking the self stacking sockets from Samtec can be used. The Samtec sockets used are similar to the ones used in PC/104 except that these have many fewer pins and only one row.

Compute Module (CCM)

This module currently has one flavor, CCM or Common Compute Module. This module is based on the Arduino project with a few changes. The primary changes are in the power supply and board interconnect bus; while the USB host interface and the ICSP header have been eliminated. The CCM does not have a USB host interface. That interface has been moved to the automation bus module to accommodate more power supply options on the CCM. Likewise the ICSP header has been removed. All of the ICSP pins are available on the board interconnect bus so that a simple adaptor cable can be used if an ICSP based tool is used to program or debug the Cube. The CCM board interconnect bus has exactly the same pins in the same physical locations as the original Arduino. There are a few new pins that allow the use of 8-pin headers on the entire board. This was so that only a single header and socket part needs to be purchased; lowering the cost quite a bit when using the Samtec self stacking sockets. The Cube can be populated exactly the same as the Arduino if both 6 and 8 pin headers are used. The power supply is really the major change in functionality of the Cube vs. the Arduino boards. Because the boards are designed to be easily used in many applications, the Cube has several power supply options. The board has foot prints for a linear, adjustable regulator as well as a switching, adjustable regulator. The various power options can then be chosen with programming headers (or populated with jumpers). These regulators can be left unpopulated all together if using an external, regulated supply. They can be populated individually if only one voltage is needed or they can both be populated if two voltages are needed (e.g. 12V & 5V; 5V & 3.3V, etc.). The built in switching regulator has an input voltage range of 7V - 40V @ 1A; output voltage range of 1.2V – 37V. The linear regulator has an input voltage range of 6.5V – 15V @ 800mA; output voltage range of 1.25V – 14V. Both can be configured (with resistors) for varying output voltages. Surface mount packages were selected with large thermal area so that large heat sinks should not be necessary, however achieving the full 1A output may require a heat sink.

Power Supply Modules

• Adds power input options by stacking under the CCM.
• Comes in multiple flavors:
  • OLPM – Off-line Power Module
  • ABPM – Alkaline Power Module
  • LiPM – Lithium Power Module w/ charger
  • TPM – Telecom Power Module

Note that power can also come from an automation bus module. For example the RS-485/232 SBM can back feed power to the CCM from the same cable as the serial signal.

Automation Bus Modules

• Provides connectivity to various automation buses (e.g. RS-485, Zigbee, etc.)
• Design includes the protocol stack, not just hardware
• Comes in multiple flavors:
  • UBM - USB Bus Module
  • SBM – RS-232 / RS-485 Bus Module
  • EBM – Ethernet Bus Module
  • ZBM – Zigbee Bus Module
  • WBM – Z-Wave Bus Module (Z-Wave is so “closed” that this will likely never get built; need device profiles)
  • CBM – CAN Bus Module

Application Modules

• Provides application specific interfaces to the microcontroller
• Multiple application modules can be stacked together
• Comes in multiple flavors:
  • EAM – Energy Application Module – Measures energy usage of major appliances; also monitors temperature w/ 1-Wire
  • SAM - Sensor Application Module - Options for temperature, humidity, pulse counters, analog transducers, etc.
  • HAM - Heater Application Module - Precise control of an electric heater using cycle skipping. Primary application will be a reflow oven controller.

Note that multiple application modules can be stacked together.


===Add picture here===

Software Environment

The software modules are the key to the whole project. From my work in embedded systems and now working for a manufacturer who develops both hardware and software components, I can attest that software development is 80+% of the overall development time. Therefore software reuse is absolutely key. If the software is application specific then the overall concept of this project will fail. There is a price to be paid; reusable code only comes about by spending extra hours in upfront design and through code reviews. Anyone developing code for the project should understand this up front. Software reuse (and hardware reuse for that matter) is the number one priority of the project. Software will not be accepted to the repository unless the architecture team feels that the overall structure of the newly developed code is built to be modular and reusable. This tenant also implies that developers must reuse code, possibly extending the existing modules, where functionality already exists.

There are plenty of other embedded microcontroller projects that do not encourage such strong architectural control. It is precisely this strong architectural influence and strong reuse requirement that makes this project unique.

Base Software Platform

This decision is still TBD. There are many reasons to choose some type of "OS" with multitasking capabilities so the project may end up there. The environments below do not directly provide support for multitasking. Some contenders are FreeRTOS and Contiki.

The software environment could be based on processing/wiring. I'm considering using the Arduino IDE as is however I first want to make sure that Processing is not a better fit. Since Arduino is based on Processing it is hard for me to tell which one is best. I'm inclined to pick the one with the best open-source community. Being able to contribute changes back into the project is highly important to me and not all open-source projects are as "open" when it comes to contributions. The jury is still out.

• Arduino - Based on a platform with the closest hardware design (ATmega168)
• Processing - One option for IDE and libraries (ATmega128)
• Wiring - Reference only (ATmega128)

Installing

Arduino IDE

Loaded compiled binaries (arduino-0010-win) from Arduino site

Arduino Source

Under cygwin::
svn checkout svn://svn.berlios.de/arduino/trunk

Arduino Bootloader

• Arduino,:::::.cc/cgi-bin/yabb2/YaBB.pl?num=1183647052;start=all" rel="external">Bootloader on ATMEGA168 - Great post on using programmers to load the bootloader

Processing Source

• Build Processing

Wiring Source

Under cygwin:
svn co svn://wiring.uniandes.edu.co/trunk/wiring