Hardware Reference
In-Depth Information
Physical Communication
How your open source hardware communicates is just as important as what it's made of.
There are many standards—for example, USB, I2C, RS-232, UART, 1-Wire, Ethernet,
Bluetooth, Zigbee, and RS-485—that you can employ to easily communicate with and
between your hardware (also known as Device-to-device communication). While each of
these standards serves roughly the same purpose, not all are created equal when it comes to
making open source hardware accessible. When choosing the communication technologies
you will use, it is important to continue to weigh the burden you are imposing on future
developers who wish to extend or modify your designs. Considerations include whether the
communication protocol requires any expensive or otherwise Difficult-to-acquire extern-
al hardware. Are there any regulatory or IP implications in place if users wish to alter the
hardware? How portable is the code required to communicate with the given technology
if your end users want to move to different processors? Is the communication technology
Peer-to-peer or does it require a “master” node to coordinate communication with other
devices?
Of course, how many existing devices you can communicate with is also an important
consideration. For example, choosing to use USB in a design might mean it is easier to
connect to personal computers, but might actually make it more difficult to interface with
other open source hardware. This situation arises because USB generally requires special-
ized microcontrollers, introduces fees and bureaucratic oversight by the USB imple-
menters' forum, and requires a master node (host) to control the bus. In cases where you
must use USB, it may be advisable to add a secondary interface by simply exposing an
unused UART from your hardware's microcontroller to lower the threshold for future
communication. Remember to choose what your hardware says carefully and how it com-
municates just as wisely!
Hardware Interfaces
We covered software interfaces earlier as a mechanism that allows different implementa-
tions of the same interface to be swapped out, allowing much greater code reuse when only
the code “hidden” behind the interface needs to be changed. We gave an example where a
system could be designed with a simple push button and could be swapped out with a large
floor pad simply by implementing the interface in software to communicate with the new
floor switch. With hardware interfaces, we can extend this concept to allow new hardware
implementations to be incorporated without writing a single line of code.
For instance, a MIDI-enabled keyboard can communicate with an external synthesizer
through a standard cable and a standard protocol. The MIDI keyboard sends notes to the
synthesizer, and the synthesizer responds by playing the notes through an amplifier con-
