Wednesday, 21 November 2018

A clock, for my desk, revisited…

So, back when I was a wee kid, I wanted to make the obligatory LED clock — back then, it wasn't ųC's, it was decade counters and 7400 series logic gates.  Never did actually make it, though…  So when I got my first Arduino, the desk clock (with a few extras) was the first thing I made after the obligatory learn-to-Arduino style Blinky.  But as I mentioned in an earlier post, it died a sad, sad, death.

I've done my non-Arduino Blinky, too, nice little (7)555 on a board, got me a taste of KiCad and SMT.  Now it's time to resurrect my DeskClock project; this time, I'm planning to make it an Arduino shield, much the same as before, but with an actual real time clock module thrown in for bonus points.  (Next version, I think, will be an all-in-one, maybe I'll add a buzzer there for an alarm option, maybe the external temperature sensor I was considering adding also, so many things…)

Now, onto the project.  So I've got me that nice blue 4-digit 7-segment clock display, and a simple MAX7219 display driver.  The driver's not really what I want, I want (at least) per-digit brightness, the 7219 only does global brightness, but it's what I've got, so I'm going to see if I can make it do what I want, see if I can flip the digits on and off quick enough to pretend.  Though from an initial poke, I gotta say I'm a little dubious…  Still, current step is to get the display running, then try it and see.  But there appears to be a small problem, it seems my common-cathode display, mayhaps isn't.  Started with a simple library and demo program on the Arduino, with just the MAX7219 and the display wired up, and nada.  Well, not exactly nada, all the digits were on, all the time.  Seems kind of obvious now, but after poking at it for a bit, and verifying that the program is spitting out the data it's supposed to be, I think my common-cathode display might actually be a common-anode one, or if I'm lucky, perhaps the documentation I found just has the anodes and cathodes backwards — I would have noticed that when I was building my clock the first time around, but I was just experimenting and playing with it at the time, and wasn't particularly keeping notes.  (This is why project diaries are good — they save you from wasting time later on.)

(… later …)

Well, it turns out the display is indeed common-anode.  Still, that wasn't going to stop me.  A little confusing wiring, and some tricky coding to transpose the bits, and it's displaying digits just fine — little annoying I can't use the display trim to render just the four digits, but it works just fine.  Added an RTC module (so it doesn't slip a minute a day like it used to), and stepped it up to two buttons this time, and it's been running quite happily on my shelf for the past couple months.

(… much later …)

Its RTC module is still holding time just fine, though it's hard to read the digits through the tangle of breadboard wires, so it's been sitting there running, but mostly neglected — the interface connected to those buttons is still mostly undone.  Well, I've finally decided to push it along again.  I've got a spare EtherTen board, and that clock has a temperature sensor stranded on the device and not available to my growing room automation system … I'm sure you know where that's leading.

However, that does change the plan a bit.  I'm not quite to the point of designing PCB's with Ethernet just yet, so I've designed a PCB version of the circuit as an Arduino shield, parts and board (finally) ordered, just waiting for it all to arrive.  It also raises a fresh problem; my prior little project, very quickly exhausted the ATmega328P's (the chip at the heard of the Arduino Uno) rather meagre code and data resources — so I'm not at all confident that after dropping in the Ethernet library, there'll be enough room left for everything else, and I'm certain it won't fit an NTP client on top.  I'm fully expecting it'll fit the basic clock and temperature functions, but I may need to off-load the menu's with their settings — on the upside, since I never designed a buzzer into the PCB, I'll just have to implement the alarm by having a Raspberry Pi play an audio clip.

(… to be continued …)

No comments:

Post a Comment