■ FIGURE 5. Serial input.
RTCC register which is what controls periodic interrupts.
Remember that the SX/B compiler is very smart, so what it
does is set the RTCC prescaler to 1: 2; this has the effect of
clocking the RTCC every 40 nanoseconds ( 25 MHz); now
the rollover value is 162.7 (which gets rounded to 163).
No problem, right? Well, no, but then what happens
is that the dividing up of the AC half-cycle is just a tiny bit
out of whack. It doesn’t hurt anything, but what we’ll see
is a very dim control LED when the channel is, in fact,
supposed to be off; this bothered me enough to fix it.
Here’s what I did: I took the RTCC clock of 40
nanoseconds and multiplied it by 163 (cycles for each
interrupt) to get 6. 52 µs. Into this value I divided 6. 51 µs
(ideal timing) to get 1.001472 and multiplied that by the
initial ISR setting of 153,600 — the final result is 153,826.
This eliminates the ghosting on the control output LEDs
(off is now off) and does not impact the receive UART as
the change is only about 0.14 percent.
The important lesson is that “ideals” are sometimes
less than ideal in practical application, and that we
shouldn’t be afraid of tweaking to get the best
performance from a piece of code.
Each accumulator is incremented and if it rolls over to
zero, the corresponding triac gate is enabled. So you see,
the higher the channel value, the sooner it will roll over to
zero and allow the triac to be gated. And as we saw
previously, the earlier we gate the triac relative to the
zero-cross, the brighter the lamp will be.
Pretty neat, huh? Yeah, I think so, too.
INTERRUPT FINE TUNING
Being a math wizard, you’ve probably figured out that
with 4x sampling of 38.4K serial bits we should run the ISR
at a rate of 153,600 times per second. You’re right. Why,
then, does the program use the oddball value of 153,826?
Here’s the deal ... we’re running the SX at 50 MHz which
means that each instruction takes just 20 nanoseconds. If we
divide 6. 51 microseconds by 20 nanoseconds we get 325.5 —
whoops, this value is bigger than a byte so it won’t fit into the
16 November 2007
This board is designed to be a slave of another
device; that device could be a BASIC Stamp on a Board
of Education or the PC program Vixen using an RS-485
multi-drop link. The reason for the RS-485 link is to allow
significant distance between the PC and the actual dimmer board. We could, for example, use a PC in the back
of the house to control one or more of these boards
installed in the family room near the Christmas tree.
Figure 5 shows the associated serial connections for the
board. For local control (LTC485 chip removed) with a BASIC
Stamp, we can use X2 and X3 (for daisy-chaining) and Open-True mode communications. For long distance control, we can
use RS-485 (LTC485 installed) serial over standard CAT5
networking cable. I’d love to convince you that I’m very smart
and came up with this idea, but I didn’t; I “liberated” this idea
from my good friend, Peter (who also maintains the SX-Key IDE
for Parallax), after seeing it in use in his modular animatronics
control system (see www.socalhalloween.com). CAT5 cable
works well because it uses twisted pairs and is designed for
much higher data rates. In Peter’s system, he actually carries
DC power ( 12 volts) to his boards through the cable, as well.
The RS-485 interface is standard, and is set up for
receive only. A jumper on the board allows for a 120 ohm
terminating resistor as this is required on the final node in an
RS-485 chain. Note that the 100 ohm resistor to ground is
optional, and only needed if you decide to have common
ground between all boards. For more details on this, I recommend Jan Axelson’s excellent book, Serial Port Complete.
DECODING THE SERIAL STREAM
Like the animatronics controller from May, this project
uses a break between streams to synchronize the slaves to