Connecting Multiple AVR/Arduinos via I2C/TWI

Since my RF receivers require a full hardware-based UART to function reliably, I decided to opt for adding a simple attiny2313 as a controller connected to an Arduino. Ready to build a simple protocol, I decided to do a little more research into I2C — the inter-integrated-circuit protocol which puts multiple digital micro-controllers on a low-speed bus. As it turns out, the attiny controllers actually implement the full protocol, even if Atmel calls it TWI (two-wire-interface). The protocol defines a master device as well as up to 127 slave devices (7-bit addressing).

The hardware is very easy to hook up and it simply requires two wires (TWI is not just a clever name) – one called SDA, to transmit the data, and one called SCL, to transmit a clock signal. On an Arduino Duemilanove SDA is analog pin 4 and SCL is analog pin 5. On the attiny2313 controller, SDA is pin B5 (pin 17, also MOSI), and SCL is on pin B7 (pin 19) — also refer to Alex’s cheat sheet for the pins. Just connect SDA to SDA and SCL to SCL.

Arduinos have the Wire library built straight into them, and after some hunting I found a small library for atttiny adapted from the original Atmel code by a Donald Blake (can be found on avrfreaks.net or my subversion repository). The Arduino is quickly configured as a master and set up to send and receive characters typed into the serial console to and from the slave controller:

// Arduino Code
void
  setup()   {
  Serial.begin(57600);
  // initialize as i2c master
  Wire.begin();
  Serial.println("OK>");
}
// loop forever..
void loop()
{
  // data available from computer?
  if (Serial.available()) {
    // read the incoming byte from the serial port
    sByte = Serial.read();
    // begin transmission to device 1    
    Wire.beginTransmission(1);
    // send
    Wire.send(sByte);
    // done
    Wire.endTransmission();

    // request data from device 1
    Wire.requestFrom(1,1);
    // echo out whatever we get back
    while(Wire.available()) {
      Serial.print(Wire.receive());
      Serial.print("-");
    }
  }
  delay(100);
}

On the slave, simply link the Donald Blake’s library into the code and this then does all the magic:

// attiny2313 code
int main(void)
{
  // initialize as slave with id 1
  usiTwiSlaveInit(1);

  // enable interrupts (must be there, i2c needs them!)
  sei();

  // handle commands
  while (1)
  {
    // check if data is in the i2c receive buffer
    if(usiTwiDataInReceiveBuffer())
    {
      // get it
      uint8_t b = usiTwiReceiveByte();
      // echo it back
      usiTwiTransmitByte(b);
    }
    // Do something else while waiting for the TWI transceiver to complete.

    asm volatile ("NOP" ::);
  }
  return 0;
}

Works like a charm!

Atmega/Arduino (Soft-) Serial Ports

In the implementation of the “reverse” channel of my home automation system, the RF receiver will transmit radio data back to the master controller which in return sends it to the computer. Since the atmega168/328′s processors used in the standard Arduino only have one hardware-based serial port (UART), I tried for the software-based serial that ships with the Arduino IDEs. Transmitting data out works like a charm (as seen previously), but receiving it is quite a challenge, mostly due to timing problems. The software serial port doesn’t work unless all the sketch does is gather data — there’s no time for processing or it will start losing data.

My next attempt was to use an interrupt-based version of the software serial port. I briefly thought about writing one, but then I found this great libary, the New SoftSerial. It is as simple to use as the original library, but unfortunately once I connect the RF receiver, the processor is too busy handling interrupts and nothing really works. The noise picked up by the RF module must simply overwhelm it. That’s too bad, this works beautifully on my attiny2313-based receiver when using the hardware UART.

A software-based solution is clearly not the answer, some hardware is required. I can think of a few options

1. Abandon the Arduino altogether and use an AVR controller with multiple UARTs — not ideal, I like the idea of basing the master on Arduino for the hackability factor
2. Use a logic gate and an external clock generator to sample/filter the signal exactly at the right timing required for 1200 bps (the maximum reliable speed I could get to work for the RF modules) – this could still lead to timing issues
3. Create an attiny2313-based “daughter-board” which handles all the nitty gritty of the RF communication using the hardware-UART and then communicates to the Arduino via a few of the regular digital ports (I’m thinking asynchronously via about 4 pins)

Clearly this requires a little more thinking, but I’m leaning towards the third option — it encapsulates all the protocol logic on the attiny’s and the Arduino library that would need to be written to communicate with it would be very light-weight. And let’s not forget the attiny’s are only about two bucks.

iPhone Garage Door Opener

You keep forgetting your keys but would never let your precious iPhone out of sight? Then nothing should seem more obvious than the need to open your garage door with your iPhone. An Arduino and a few microcontrollers, relays, rf link transmitters and receivers and some firmware later, it’s now reality. Check out the prototype (and excuse the slightly shaky video, it was bitter cold outside):

Read more about the setup and software here.

Talking to an Arduino from Ruby/Rails

As I’m in the process of building a full home-automation suite so I can finally open my garage door with my iPhone (stay tuned, more on that soon), I wanted to quickly post this since it actually wasn’t really easily found online and I spent a few minutes (ok, more like an hour) fiddling with this before I got it to work.

The code below takes data (you should pass in numeric 8-bit values, i.e. between 0×0 and 0xFF) and then read them out on the Arduino as usual. As a general note, working in dynamically typed language like Ruby is a major pain in the a** when you’re trying to fiddle with every bit and work with an 8-bit microcontroller on the other side of the wire. On a positive note,  Ruby has bit manipulation capabilities and it’s just so easy to build webapps with it…

The gist of the code below: Put the data into an array, pack it as unsigned characters, and then pump it into the serial port. The code below requires the ruby-serial gem.

class SerialGateway

  def initialize()
    puts "Starting serial gateway"
    begin
      # 9600, 8N1 on USB0
      @sp = SerialPort.new "/dev/ttyUSB0", 9600, 8, 1, SerialPort::NONE
      # release port on shutdown
      at_exit { do_at_exit() }
    rescue => e
      # sophisticated error handling
      puts "Cannot initialize usb device"
    end
    # only one serial access per time
    @send_mutex = Mutex.new
  end

  #
  # Send a command to the master device.
  #
  def sendCommand(command, targetAddress, data=[])

    if(data.length >4)
      raise "Sorry, maximum command data length is 4."
    end    

    # first one ASCII R (remote, 0x52)
    cmd = [ 0x52, command, targetAddress, data.size()]
    # add data array
    data.each { |d| cmd << d}
    # pack it into unsigned chars
    cmd = cmd.pack("C*")

    @send_mutex.synchronize do
     cmd.each_byte { |c| @sp.putc c }
    end

  end

end

Oh, and flipping back and forth between Ruby and C is a little weird :-)

What’s powering Web apps: Google waving goodbye to Gears, hello to HTML5

What’s powering Web apps: Google waving goodbye to Gears, hello to HTML5 [Updated] | Technology | Los Angeles Times