Loading ...
Sorry, an error occurred while loading the content.

A Christmas Clock

Expand Messages
  • Lee Hart
    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
    Message 1 of 75 , Dec 2, 2012
    • 0 Attachment
      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".

      Software

      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
      power fails.

      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
      that way.

      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@...
    • Kevin
      ... I am loathe to label the positing of alternative ideas for consideration as a devolving debate. New ideas spark further and better ideas. ... Sometimes,
      Message 75 of 75 , Dec 7, 2012
      • 0 Attachment
        --- In cosmacelf@yahoogroups.com, Lee Hart <leeahart@...> wrote:
        >
        > 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.

        I am loathe to label the positing of alternative ideas for consideration as a 'devolving' debate. New ideas spark further and better ideas.


        > > Sometimes a kludge can be more than just a "dirty workaround",
        > > however. This is one of those times.
        >
        > Calling something a kludge is like calling something ugly.

        Sometimes, but frequently not. Which is why I specifically wrote this instance is 'more than just a "dirty workaround"'.

        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 allows
        > *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.

        THAT 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.

        * * *

        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.
      Your message has been successfully submitted and would be delivered to recipients shortly.