Design Issues

From Firmata

Revision as of 15:06, 7 March 2013 by Firmata (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

There was a lot of discussion on the Arduino developers list about this protocol:

(link not working, please fix it)

You can see the data format in the "message formats" section of the comments. Basically, the data communication format uses MIDI messages. There was big changes between protocol version 0.0 and 1.0, mostly around making it use MIDI messages. It is not necessarily a MIDI device, first it uses a faster serial speed, and second, the messages don't always map the same.


Latency and Jitter Concerns

It turns out that the USB-serial drivers are optimized for fast bulk data transfer, and those optimizations actually wreak havoc with the timing of the messages over the USB-serial. This forum thread covers the topic:

Protocol Design

The intention of this protocol is allow as much of the Arduino to be controlled as possible from the host computer. Also, efficiency was a primary concern since Arduino is limited to the 115,000 bits/seconds of a serial port. This protocol then was designed only for the direct communication between Arduino and an software object on the host computer. The host software object should then provide an interface that makes sense in that environment.

Other Related Protocols

A number of protocols were considered during the design and implementation of the Firmata firmware for Arduino. Here's an overview:


Transfers are byte-sized. 7-bit data resolution, 7-bit command space, 8th bit specifies a command. The original Firmata protocol was quite similar to MIDI, so Firmata was changed to use a MIDI compatible message format.

MIDI messages range from 1 to 3 bytes.

Here's a decent breakdown of MIDI: Essentials of the MIDI Protocol

MIDI Documentation

MIDI SysEx messages can be of any length. They must start with the SysEx header byte 0xF0 and end with the EOX (end-of-exclusive) byte 0xF7. The data bytes in between must only use the least significant 7-bits in each byte, since a 1 in the most significant bit makes that byte be interpreted as a command.


Arduino could not be a proper USB HID device because it uses USB-serial. But it still could use the HID protocol. I opted not to use it because it is a very complicated and obfuscated protocol. In the long run, it would probably be best to use it though, since it is a broad standard for this kind of thing (phidgets, MultIO, and CREATE CUI use it).


OSC would be very nice to have but was designed with much faster connections in mind, like network connections. The minimum size of an OSC "bundle" is 24 bytes, and that just sends one value.

OpenSound Control Specification

The OSC serial package is a lot smaller, 11 bytes minimum (1 byte header, 1 byte for packet size, data in 4-byte chunks, type tag in 4 bytes, 1-byte checksum).

OSC Implementation for Atmel


Call and response protocol, the host sends a request, the Gainer replies. The message size varies from 1 byte to 6 bytes. It has got terminators only on the messsages coming from the microcontroller.


Phidgets use a USB HID protocol.


Uses an ASCII-based protocol similar to Simple Message System:

ASCII-based protocols

There are a number of simple, ASCII-based protocols out there which are generally pretty easy to implement and understand. The problem is that they are very verbose, and the Arduino is limited to serial rates, so a maximum of 115,200 bits/second. One example is the Simple Message System for Arduino. It is easy to read and implement. But it needs 4 bytes to set one digital pin, 56 bytes to set all digital pins. Firmata needs 3 bytes to set one digital pin or all digital pins.

Baud Rate Details

For most of Firmata's life, it has run at 57600 bits/s. This works well, but for certain applications, higher speed would be beneficial. Plus in other applications, other baud rates work better.

  • Bluetooth Arduino wants to communicate at 115200 bits/s
  • The XBee radios want to communicate at 111111 bits/s
  • The 16 MHz clock naturally leads to communication speed of 125000 bits/s
  • Arduino can communicate to a DMX protocol at 250000 bits/s


Personal tools