An Ironclad Premise

I've been busy lately with the library that I'm hoping will form the foundation of my work with Arduino. It is titled 'Iron', and offers various interfaces for physical computing tasks. The library is based around the concept of devices, encouraging the designer to build code in a fashion that mirrors the physical unit they are creating.

There is a strong theme of performance to the code and, where possible, the lowest-level interfaces are used. For example, direct port manipulation is accomplished with template meta-programming, allowing comfortable labels to be used in place of bit shifts:

// Set pin mode as output. Equivalent to: 'DDRB |= ( 1 << 5 );'
//
setMode< 13, OUTPUT >();

// Set pin 13 high. Equivalent to: 'PORTB |= ( 1 << 5 );'
//
setDigital< 13, HIGH >();

The notion of a device is a cornerstone of the library, gathering variables, communication and inputs & outputs in one place. For example, a camera device might be defined as:

// Define device
//
EN_DEFINE_DEVICE(
    (( Camera, "Example camera device", 0xB0, 0x7B, 0xA6, 0x43 )
    (( Input,    shutter, digital_t, Low,     2 ))
    (( Input,    zoom,    analog_t,  512,     A0 ))
    (( Internal, model,   uint32_t,  2389221, None ))
    (( Internal, flash,   bool,      true,    None ))
    (( Output,   led,     digital_t, Low,     13 ))
)


Devices are designed to be interacted with from either the CPU or the MCU. Following is an example of how a camera's shutter might be expressed with Arduino:

// Create device, with MCU view
//
Camera< MCU > g_cam;

void setup()
{
    // Set up pin modes for any mapped attributes
    //
    g_cam.setup()
}

void loop()
{
    // If shutter button is 'HIGH', begin read of image data
    //
    if ( g_cam.is< 0, HIGH >() )
    {
        g_cam.read< Image >( buffer );
    }
}


From the CPU side it is possible to scan a bus for devices, establishing connections where required:

std::vector< Camera< CPU > > devices = scan< Camera >();

for ( auto it = devices.begin(); it != devices.end(); ++it )
{
    select( *it );   // Select a device. Ready for signals, etc.
    deselect( *it ); // Deselect a device.
}


There are many more facets yet to explore in the library, but it felt right to release it now. It is licensed under the GPL: you are free to use it as-is, or hack it to pieces as you see fit :) Enjoy!

https://github.com/engine-develop/iron

The Iron Handshake

After a brief reprieve from the world of circuits (and their bending) I decided to begin work on the codebase for the S1 sensor. The first forays have been into bus communication, with a simple templated foundation in the works. Often the pattern of bus operations is fixed, with variation in the data layout and signals. The library, called Iron, exposes only the essential components, hiding the details (read: gory) of bus management from the user.

For the S1 project the main role of the bus will be the transfer of image buffers. The library scans all serial ports, signalling to any devices that satisfy a signature. A device matching the protocol is connected to, enabling the start of bus operations.

EN_DEFINE_BUS_PROTOCOL( IR, 16, 0xB0, 0x7B, 0xA6 )
std::vector< Device > devs = Bus< IR, CPU >::listDevices( All );
Bus< IR, CPU >::connect( devs[0], baudRate );
Bus< IR, MCU >::write( image);

The video below shows a simple handshake between a PC application with an Arduino using the Bluetooth Serial Port Protocol. The LED blinks once to indicate a successful handshake. The next step is to send some image data from the Arduino, maybe using sensor values... or I bin it ;)

Teeth, Blue

While waiting for some outstanding camera components I decided to push ahead on another front: communication. I'm intending to interface with the S1 via mobile phone, leveraging it's fast processor for image processing. After some searching I decided to go with the HC-05 Bluetooth tranceiver, a cheap and available break-out board.

At first the pinout looked to require six wires, however after some experimenting only three will be required: VCC, GND & TX. The main hurdle for the sensor will be throughput, with 8 lines of image data needing to be sent over the wire. There are projects that have pushed the MCU as far as 2Mbit/s, which is close to the rates I'll need to support stereo image sensors at high resolution.

The next step will be a minimal mobile application to display the transmitted data, a simple test pattern at first. Qt should come in handy here, allowing a single app that will serve as the hub for many sensors. Onward and upward!