firmware, which then lead me to the usual story of the
code growing too big for the Atmega8’s ROM space. To
fix this one, I have changed to the AVR Atmega168 chip
with its 16K ROM and identical pin-out.
A light show timer problem that got through the cracks
(but didn’t create any email) involved running the program
past midnight. Let’s say you start at dusk — 5: 30 pm locally
— and you shut down at 10: 30 pm, for a five hour show.
The data is easy to enter through the push switch and
rotary encoder, and could be changed again once your
light show is installed out on the lawn. What if you run it
past midnight? Technically this is the “next day” and one
o’clock in the morning is actually numerically smaller than
5: 30 in the evening, causing a firmware math error.
The clock display and math are in a 24 hour format,
so that am and pm are never confused. Funny story ...
once I accidently set an alarm clock to wake me up at
dinner time instead of breakfast! The two BCD encoded
data strings (hh:mm) are saved to the EEPROM in the RTC
chip: one for start and one for stop. These are converted
to minutes and compared to the RTC’s clock time (also
converted to minutes from its native BCD hh:mm format).
When the RTC sum is greater than the start sum, the show
runs, and when the RTC sum is greater than the stop sum,
the show is idle. If the stop time goes past midnight,
I set a flag, telling the firmware to continue to the next
day once the show is running. It’s now possible to have
any length show from just one minute duration up to
11 hours, 59 minutes starting at any minute through the
24 hour day (both examples being rather silly).
My prototype controller PCB used the standard 10
pin header to connect an Atmel AVRISP for programming
the AVR chip. Shortly after this project, I damaged my
AVRISP and discovered the replacement (an AVRISP mark
II) only uses the six pin header. So, my next AVR project
used the six pin style header and I made a ribbon
cable adapter to service the older 10 pin style projects.
The AVRISP mkII also has a USB (instead of serial com)
connector on the PC side, and has revised circuitry in
the pod.
I found that the new AVRISP would reset the target
AVR at random and I traced this to noise from my
project’s 5V rail getting back into the pod. I added a 10K
resistor and a 10 µF capacitor as decoupling, and that did
the trick. Unfortunately, those values didn’t make it to the
published controller BOM, which has the correct six pin
header. I got quite a few emails wondering why there was
an undocumented C4 and R25 on those new PCBs!
■ FIGURE 3. MkII schematic, logic.
"
*- . //"0
,*$
& '
& '
& '
& !'
& %' !
& '
& '
& '
& +' )
& " ( ' )
& " ( ' )
& ( ' )
&* )' )!
&$ )+' )
&, ' )
&,*$ +' )
*-
*-
! *- !
*-
*-
" *-
# *-
*- "
"
,
,*$
,*$ 1$
. // 0
"
"
!
%
-
*-
*- !
*-
*-
*-
*-
- "
"
!
$
$
,*
, $
$
$
!
$
$
, $*1,*$ 1 1$
$
"
!
November 2008 55