Communications

There are various protocols, each with their own strengths. Here we introduce some of the more common protocols, and consider some design tradeoffs of their application to creative embedded systems. We do not describe any technical information on the implementation of these protocols, as this is readily available online.

Software Protocols

Software protocols allow multiple software application to communicate with each other.

UDP/TCP

These protocols are the most commonly recognized due to their use as the backbone of the internet. In the context of creative embedded systems, we really only need to keep in mind that UDP is faster but less reliable, whereas TCP is slower and more reliable. In case you are transmitting a stream of sensor data (eg gyroscope), you are likely to prefer UDP. In this case, if the UDP protocol drops a packet, we do not suffer that much, since another packet is on the way. If you are transmitting event-based data (eg button presses), you are likely to prefer TCP.

Most software libraries we will use in this course provide easy API to interface with these protocols. One occasional difficultly to keep in mind is that, if you are manually constructing UDP or TCP packets, some network’s firewalls will prevent certain kinds of these packets from being transmitted. In this case, you will either need to figure out the network policy, or use a higher level communication protocol.

MIDI

MIDI is both a protocol, a message format, and a hardware interface. For the purposes of creative embedded systems, we again generally have useful APIs to handle constructing and passing MIDI messages between devices. While MIDI values are quite limited in the expressive power (sets of values 0-127), the high rate of adoption among musical interfaces makes it quite common in creative applications.

OSC

OpenSoundControl (OSC) is more of a message format than a protocol. From an implementation perspective, it probably best to of it as a version of json specialized for music and performance. We include it in the software protocols section as many creative software tools provide specialized communications APIs for OSC. These APIs can can sit a top any number of the other protocol listed in this section.

Hardware Protocols

All the above software protocols rely on some hardware transmission. When working on a single device, you can completely abstract from the hardware, but as we are working with embedded systems, we must also consider how to build connections on the hardware level. These connections will then allow us to communicate between devices on the software level.

Analog vs Digital

The pins on your Arduino will say both Analog and Digital. Analog input allows for the reading or writing of continuous values, whereas digital is discrete (zeros and ones). This is the simplest protocol you can use with embedded systems. The Arduino will allow you to read and write to these pins as you like via software.

Serial bus/SPI

Serial bus is the next easiest protocol to handle - all the above wired software protocols can run atop this connection. For our purposes, we mostly will be able to abstract the serial bus protocol as the thing that happens when you plug in a USB. That being said, there are times, particularly when interfacing with the Arduino IDE that we need to know a bit about how Serial Bus and serial ports work.

Bluetooth/BLE

Bluetooth, and more commonly, Bluetooth Low Energy (BLE) are standard protocols for communicating over Bluetooth devices.

i2C, UART, 1-wire, Morse code

There are a number of low level protocols for sending information over a small number of wires As an example, the i²C protocol handles sending data over a two-wire interface. We should not need to know anything about this for this class other than it exists and we might want to use it. The implementation of these protocols is well support by many libraries. More details can be found online.