I²C smartControls Smart Device

This project is shared with the fischertechnik Corner website, as this device is intended for the fischertechnik Robo TX controller.

This part in more technical oriented.

Smart Device

How to call a device with its own embedded MCU? A smart device.

The MCU receives commands from the main controller and acts accordingly. It also manages local events, in this case the user interactions with the touch screen. 

This allows higher-level commands from the main controller and better response times.

smartControls

The device I'm working on is a touch screen with SD-card, called smartControls, to provide an interactive control panel to the fischertechnik models.

Based on the functional specifications, the main choices are about the screen and the MCU. 

The screen should provide at least QVGA or 320x240 definition or, better, a 400x240 definition to match with the fischertechnik box 10,5 x 6 cm form-factor. 

The MCU should provide an reliable I²C slave connection. The screen and touch controllers couldn't use the I²C bus, in order to prevent any collusion. The MCU should have as few pins as possible. 

Because I'm a hobbyist, I'd prefer to deal with DIP packages rather than SOIC or, even more difficult, SSOP. 

Finally, the whole firmware of the device is going to be developed in C++, with the Wiring-derived Arduino-like framework and the Xcode template embedXcode.

Selecting the Screen and MCU

After an extensive research, I came with two solutions. Each solutoin has two short-lists, one for screens and the other for MCUs.

The two solutions differ on how to manage the screen:
  • a basic screen requires a powerful MCU,
  • a smart screen allows a standard MCU.

Each solution has its pros and cons. Performance and total cost need to be arbitraged.

I²C Commands

Based on the functional specifications and after extensive tests with standard boards, I've defined three sets of commands: 
  • Build the interface, 
  • Run the interface,
  • Write and read files.

Learn more about the commands.

Building the Prototypes

For each solution, the prototypes were built in three steps.

On the first step, I'm using two boards connected through I²C bus: 
  • One board acts as master and simulates the commands. 
  • Another board acts as slave and manages the screen, touch and SD-card. 
Response times and responsiveness are measured. Data traffic is monitored by a logic analyser.

Three boards were selected as slave: an Arduino Mega2560, a Wiring S and a LaunchPad Stellaris. Two boards were used as master: an Arduino Uno and a LaunchPad MSP430.

On the second step, pictured on the right, the board acting as master is replaced by the RoboTX controller. 

All the commands are defined with RoboPro so they can run on the RoboTX controller. A protocol of tests is defined and run against each of the two solutions.

Data traffic is monitored by a logic analyser and same emphasis is given to responsiveness, with an additional criteria for capability.

On the third and last prototype step, the board acting as slave is replaced by a circuit on the prototype board. 

The winning solution is then implemented on a circuit board and finally integrated into the fischertechnik 10,5 cm x 6 cm box!
Second prototype step: RoboTX as master, standard board as slave

Finalised and Working Device

The final product is ready and working.

Discover it at the ft Convention 2013!