Keith's Electronics Blog

After the huge psychological reward of getting the LED digit working, I haven’t felt much like getting back to the real-time chip, knowing any successes there would feel insignificant compared to the bright blue glow of the LEDs. However, that’s the recipe for shelving a project indefinitely; so tonight [last night, by the time I finished writing this up] I went back and gave it a go.

Backup Battery

I had got some PC motherboard backup batteries (3V lithium button cells) from my friend’s son Phill as he emptied his “warehouse” in preparation for leaving to college. He had stuck all the cells together between two strips of masking tape, and they’re all covered with goo. I cleaned a couple of them with Goo Gone a while back, and was astounded at how shiny they are–they look newer than anything I’ve ever noticed inside a PC. [Need to remember to add a photo.]

I had also desoldered a couple of holders from dead motherboards. The first thing I did tonight, as a warmup, was plug the backup cell into the circuit and wire it into the RTC and the external crystal. It works–more on that later.

Ground

Made a mistake I’m pretty sure I’ve made before–forgot to connect the ground between the LogoChip and the RTC breadboard, so it was floating again. (That’s not the same floating ground I wrote about earlier, though–that was an off-by-one error when I meant to connect the ground pin on the chip and connected nothing instead.)

I/O Clock Timing

I was getting random data again, though, which was really frustrating. Finally I went to set up a debug mode to take the I/O clock down to 5Hz (yes, 5 Hz, to make it slow enough to watch with a logic probe, since I don’t have a working logic analyzer), and I started getting correct data.

That told me my problem was clocking the data too fast; and as it turns out, increasing the delay after toggling the clock line from one no-op to two is enough to get completely reliable data (at least as far as I’ve been able to determine). Furthermore, this eliminated the weird bit-7-is-always-on problem I’d been experiencing previously in the seconds register.

Real Time

With those problems solved, I’m actually able to get realtime out of this chip! I had previously written code to batch-read all of the time registers, cache the result, and pick it apart into separate values; and I now wrote a routine to use that and print out the individual digits of the time to the LogoChip console. I called it from the console prompt like this:

loop [ ds1302-print-hhmmss wait 10 ]

And was able to get a real-time display like this:

2
0
5
1
0
5

2
0
5
1
0
6

2
0
5
1
0
7

I guess that didn’t turn out to be as much of a let-down as I thought it would! Also, the backup battery is connected properly, because I was able to power off the circuit, bring it back up, and still have correct time.

Next Steps

The times are getting printed vertically because LogoChip Logo always sends a newline terminating each print statement. I’ll update the code to send ASCII values instead, so I can print the time horizontally in a normal format.

For now, I’ve just been playing with HH:MM:SS. Eventually I’ll need to add date processing, to handle DST changes.

There’s also some code cleanup to do, plus some refactoring (rearranging the code to work the same but be in a significantly different [and hopefully better] format). I’m used to being able to use code libraries, but LogoChip Logo doesn’t support them, so I’m hacking my own method using the m4 macro preprocessor and make to glom source files together. I’ve already refactored my 6276 LED driver code that way, and part of the process is carefully defining separate namespaces (since LogoChip Logo also doesn’t have local variables). I’ll want to do the same with this.

And it looks like it must be PC board time . . . Tom McGuire volunteered to help me make the large boards for the full displays; and I need to make a small carrier board to breakout the DS1340 from SOIC to DIP for prototyping. That also means some more refactoring of the 1302 code–I need to be sure to separate the interface code that talks to the chip from the timekeeping code that delivers numbers to the clock, so the timekeeping code can operate independently of which RTC chip I select.

This entry was posted on Thursday, July 20th, 2006 at 06:19 am by Keith Neufeld and is filed under LED Clock, LogoChip. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.