A Christmas Clock
- Hi gang!
I'm building an alarm clock for my son. As these things usually go, I'm
running out of time, and thought I'd ask if anyone in the group is
interested in helping. Here's the plan:
My son is a big fan of Minecraft. I got a "creeper" mask (really just a
cardboard box "head" printed to look like the "creeper" character in the
game). The "creeper" sneaks up on the player, and when it gets close
enough, it blows up!
I thought, "This is the perfect application for a Membership Card!" I
can use the 8-bit output port to drive four 7-segment LEDs for the
clock, and use the Q output to make a "tick tick tick" sound as it gets
closer to the alarm setting, then a "white noise" explosion type sound
at the end. Pushbuttons on flags EF1-4 to set the clock and alarm. Use
the interrupt input to sense 60 Hz for accurate timekeeping.
I started designing. To get it built quickly, I want to minimize the
number of parts (especially ones I don't have and would have to order).
I have a bunch of individual rectangular orange LEDs, so I built the
display using them. Two LEDs per segment, wired in series, form each
segment. They are efficient enough that the 74HC373 on the Membership
Card's output port can drive them directly.
I used a 74LS145 (already on hand) for the row driver. It can sink the
current from many segments all on at once with a low voltage drop (which
CMOS couldn't do).
After some scheming, I decided that the 8 output bits would be divided
into 3 bits to select 1-of-8 rows from the 74LS145, and the other 5 bits
will directly drive the columns. This controls up to a 5-by-8 matrix of
up to 40 LEDs. I only need 4 digits of 7 segments, so this does it with
plenty to spare. It actually leaves bit 7 of the output port free.
So, the only hardware needed is a Membership Card (the Front Panel card
isn't even needed), and a display board with nothing but the LEDs,
pushbuttons, the 74LS145, a transistor amp for the speaker, and a
rectifier and 7805 voltage regulator for power and 60hz from an AC
output "wall wart".
This is where I think you guy may be able to help. I'm worried that by
the time I get the hardware built, there may not be enough time to get
the program designed, written, and debugged. The limitations of the
hardware imposes some "interesting" software problems:
1. The program should be in ROM (like a 27C16 EPROM), so it won't
need to be toggled in, and then at risk of being lost if the
2. Since there is only one memory chip socket, that means NO RAM!
For a project like this, the registers provide enough storage
to run RAMless. The 1802 is perfectly capable of running without
RAM, but most programmers (including me) aren't used to thinking
3. The LEDs wind up needing to be scanned segment-by-segment, not
digit-by-digit. I.e. the software would ground all segment a's
with the 74LS145, and simultaneously select the digits (1-4)
whose "a" segment should be lit. Then ground all segment b's,
then all segment c's, etc, each time selecting the digits (1-4)
that needed that particular segment lit.
4. Handling the 60 Hz interrupt without RAM is interesting. It is
*possible* because the 1802 switches program counters on interrupt.
Thus you don't need a stack to save/restore the program counter.
My thought is that at each interrupt...
a. The interrupt saves X,P in T, and sets P=1.
b. The interrupt handler decrements the real time clock register.
c. If a minute has passed (3600 interrupts), reset the register
and add 1 to the time (in another register).
d. compute the LED bit pattern to display the time.
e. scan the LEDs, 1 segment at a time. There are 7 segments,
and it is 16 msec until the next interrupt, so maintain
each segment data about 2 msec.
f. When done scanning all 7 segments (14 msec), do other
housekeeping like checking for a button pressed to set the
time or alarm.
g. Wait for the next interrupt.
This is as far as I've gotten so far. Anyone see any problems? Anyone
want to help with the software? I'm better at hardware than software, so
I can build another display if someone can help.
A designer knows he has achieved perfection not when there is
nothing left to add, but when there is nothing left to take away.
-- Antoine de Saint Exupery
Lee A. Hart http://www.sunrise-ev.com/LeesEVs leeahart@...
- --- In firstname.lastname@example.org, Lee Hart <leeahart@...> wrote:
>I am loathe to label the positing of alternative ideas for consideration as a 'devolving' debate. New ideas spark further and better ideas.
> As soon as people start talking about a "best" solution, it usually
> devolves into arguments. People have different opinions about what
> "best" means, and what is fashionable at the moment.
> > Sometimes a kludge can be more than just a "dirty workaround",Sometimes, but frequently not. Which is why I specifically wrote this instance is 'more than just a "dirty workaround"'.
> > however. This is one of those times.
> Calling something a kludge is like calling something ugly.
Without entering a debate on the definition of 'kludge' (your views may vary), I point to Webster: "a system and especially a computer system made up of poorly matched components"
As the 1802 instruction set does not provide for math without RAM, I feel this definition is applicable. I do not feel 'poorly matched' implies 'ugly'. The lookup table is an innovative--in fact, MANDATED--solution, as is doing a 1-bit shift and compare. Both are kludges, in my view, necessitated by the 'poor match' of the 1802 and the RAM-less design.
> Henry Ford would have called our modern car engines "kludges"...I would dissent with Mr. Ford on that. Modern auto components are designed to match and perform together as a system. Traditionally, kludge is applied when pieces of disparate systems are assembled to build some system not contemplated by the designer (i.e., a vacuum turned into a leaf blower).
> [The lookup] table allowsTHAT I heartily agree with! If a design called for use of these multiple instructions I would definitely assert the lookup table is the *best* solution. If only one operation is necessary, not so much, as code space might be the more pressing requirement.
> *all* the 1802's M(R(X)) instructions to be used. It allows you to not
> only compare two numbers, but also do math, logical, and OUT
> instructions. The table is a better solution than individual workaround
> routines for each of them.
* * *
A "HYBRID" SOLUTION:
I can also imagine a solution using a 16 byte lookup table to compare one nibble at a time. This would be a hybrid between a 256 byte lookup table and the 1-bit shift and compare solution.