The circuit is a standard,
half-duplex RS-485 interface that
defaults to RX mode by pulling
the /RE and DE lines low through
resistor R4. You may be wondering
why I went with a 5V device when
a 3.3V device is available. Cost.
There is a 5V supply on the
Propeller platform and the cost of
the 5V ST485BN plus resistor R3 is
about half of the 3.3V device. R3
limits the current into the RX2 pin
(DMX RX input) of the Propeller. R2
holds the line high (idle state) when
the ST485BN is set to transmit
mode and the RO output goes Hi-Z
(this resistor is required for projects that will do
bi-directional comms). Finally, we don’t have to worry
about direct control of the TXE line with the Propeller as
the minimum VIH level of the ST485BN is 2.0 volts.
Okay, let’s have a look at the code. The heart of the
object will, of course, run in its own cog, happily receiving
DMX data on the assigned pin and writing it to an array
that we can read from our top-level application. I’ve also
added an activity output LED; this lights when receiving
a frame byte so we know the line is active.
From the top, here’s the setup and code that monitors
the DMX RX line for the Break period.
■ FIGURE 2.
DMX I/O Circuit.
BREAK, phsa wc
for the next Break, we can get into sync with the
After we’ve detected a valid break, we set up to
receive up to 513 serial bytes. The first is the Start byte
and will usually be zero. Still, we shouldn’t ignore this
byte; we should make it available to the application
For review, a serial byte will have a start bit, eight data
bits, and one or more stop bits; in DMX512-A, each byte
has two stop bits. Figure 3 shows the signal going into the
DMX RX pin of the Propeller. The idle state of the line is
high, a start bit is low (0), the data bits arrive LSB first and
are read directly from the line. The stop bits are at the
line’s idle state (1). The value in the diagram is $CF.
Another task to deal with is handling a short packet,
that is, less than 512 frame bytes. A typical DMX controller will transmit the Start byte plus 512 frames, but it
doesn’t have to. For example, I have a mini, six-channel
controller that sends the Start byte plus six frames, at a
very low rate (every 100 ms). What I’m getting at is we’ll
have to smarten-up our serial receive code to detect a
new break, even when we don’t expect one.
On entry, we make the LED pin an output and off,
and then set up ctra to count (at the system clock rate)
whenever the DMX RX pin goes low (negative detect
mode). This is an easy way to use the counter for pulse
width timing; we simply check or reset the counter
whenever the RX pin is high.
At waitbreak, we begin by waiting for the RX line to
go high using waitpeq. When it does, we reset the ctra
accumulator (phsa) and then wait for the RX line to go
low. After it goes high again (so we’ve seen a high, low,
then high), we can compare (cmp) the value in the
counter’s accumulator with the minimum timing for a
break. If the pulse was short, i.e., not a valid break, the
program will loop back to waitbreak and try again. Why
would we have a short Break? We wouldn’t, but we could
power on in the middle of the Packet and we don’t want
to move unsynchronized values into our array. By waiting
rxmask, ina wc
November 2009 15
■ FIGURE 3. DMX512-A Byte Format.