Hardware Reference
In-Depth Information
Software
The software for the Alcyone comes in two artifacts: the actual embedded code (the
code running on the Raspberry Pi) and an external client app (currently targeted for
Android).
The embedded platform runs a single application (called
alcyone
of all things), written
in C. C was chosen because the original test program was written on an Arduino Uno,
which tends to encourage the use of Arduino “sketches,” which are themselves a form
of C++ code (mostly with really odd library support).
C++ editing was largely done through Code::Blocks, easily installed for Fedora
through:
$ su -c 'yum install codeblocks'
Interaction with the physical hardware is provided by Gordon Prescott's wiringPi li-
brary, an excellent utility with various language implementations.
It uses three threads, provided via boost::thread, to execute. All three threads are
infinite loops. The Alcyone is a set of state machines, with the different machines able
to affect the others.
The simplest thread is a “flare” machine. It loops through the output LEDs. The loop
provides a timer value via an extern variable.
The second thread polls the digital inputs for changes in pedal state—in other words,
when the pedals are pressed down and lifted up. The routine keeps track of two states:
the “current state” based on a digital read, and the “previously read” state.
The current state is buffered to handle bounce.
Bounce
is the natural tendency of an electrical current to fluctuate during changes.
When a circuit is closed (or opened), electrons flow across it occasionally until the
circuit settles in; the circuit appears to “bounce” open and closed for a short period
of time. This makes consistent reads very difficult, unless you “debounce” the circuit.
There are two ways to debounce circuits. One hardware approach uses something
called a
Schmitt trigger buffer
. Jack Ganssle has an excellent
guide to debouncing
that
describes a few different ways to handle bounce in hardware and software (including
code).
Alcyone uses a similar approach with a class that examines the input and counts the
“open” and “closed” states. It's possible that the debouncing mechanism could be
fooled if the user plays quickly enough (pressing and releasing pedals much faster
than the human eye can blink), but the sample frequency is high enough that we ha-
ven't seen any incorrect results yet.
