Correct. I changed every SEROUT reference from HEX2 to DEC2 and it behaved as I said. Maybe there's something in the way that the program writes it to the DS1302. Unfortunately, I am going to be away from my office this weekend, but I will try any suggestions when I get back. I think that I may just isolate the problem code and try to work on it separately. I have so many DO WHILE, LOOP latches in there, it is getting confusing. All to create a smooth UI though...
After leaving the system alone all weekend (to check for drift), I found that the seconds value had lost '3'. Over a 72-hour period, the timekeeping slowed by 3 seconds. This is more than acceptable, given the design specifications of +/- 30 seconds in 24 hours. It is also small enough that environmental factors could easily be the explanation.
I also was given the idea of implementing my debouncing "latch" in a subroutine, so as to make the code simpler. Credit is given in the code.
I think you need to solder the crystal's leads to the IC's pins.
It's finicky, not really amenable to stray capacitance inherent in breadboards; the leads of the crystal (tuning-fork) are fine and make poor contact in the breadboard.
The only reason that I've yet to solder the leads is that the entire circuit is going to be put on a solder-through board soon. Trust me - it is driving me mad.
Good news- the clock is ticking again. I just had to set the time. The biggest problem remains the U.I.
Thanks to one of my advisers, I have written a latch subroutine which seems to catch the bounce. My current problem (in the U.I.) is, besides the HEX display issues, I had to apostrophe-out my conditions for resetting minutes over 60, and hours over 12 or 24. I can't help but feel that this is related, because, when incrementing hours in 24-hour mode, it would go to 17, then reset.
I wish I had a better understanding of HEX vs. DEC.
UPDATE Just fixed a funny little glitch where the clock would display only the seconds at [00:00:01]. I found that the display suppresses the leading zeroes. Fixed it with a couple of letter O's when hrs < 1.
Now that I have to put it inside the display housing, I still need to DEBUG and connect to my PC. Ideally, I would just use a 1/8" TRS plug, but I wonder if this (3) is enough pins for communication with the BS2.
You only "need" to lead out 2,3,4,5 to the Stamp if you jumper 6 and 7 (the loopback check, the IDE figures it's connected when it sees that) on the PC side.
There is a project I posted that uses the DS1302 and normally displays the time on a MAX7219 display driver, but it also shifts the binary data out to shift registers for binary mode. Perhaps there's some code in there that would be helpful to you for handling the DS1302 data. You can find the Binary Digital Clock here. You can also find a Digital Alarm Clock project here. I hope these help.
When bread-boarding with those chips, the best way to attach the crystal is to gently bend the chip leads up away from the board and solder the crystal directly to the chip. However, inserting both the chip and the crystal's leads into the same holes works okay. It's a tight fit, but I've done it on a variety of boards, including the Board of Education and the Professional development board.
I understand the difference now, but I'm still working on how to modify the program. For now, I am focusing on installing the hardware inside my display. It really comes down to either buying a Parallax board, or building one of my own.
Comments
After leaving the system alone all weekend (to check for drift), I found that the seconds value had lost '3'. Over a 72-hour period, the timekeeping slowed by 3 seconds. This is more than acceptable, given the design specifications of +/- 30 seconds in 24 hours. It is also small enough that environmental factors could easily be the explanation.
I also was given the idea of implementing my debouncing "latch" in a subroutine, so as to make the code simpler. Credit is given in the code.
Test sequence runs fine, setting time is ok, but in run mode, it just shows 80 as the seconds, and doesn't tick. It's the damndest thing...
It's finicky, not really amenable to stray capacitance inherent in breadboards; the leads of the crystal (tuning-fork) are fine and make poor contact in the breadboard.
Good news- the clock is ticking again. I just had to set the time. The biggest problem remains the U.I.
I wish I had a better understanding of HEX vs. DEC.
VI77-708 Firmware.bs2
(1 x 16) + (7 x 1) = 23
117 HEX is DEC 279
(1 x 256) + (1 x 16) + (7 x 1) = 279
(But, hey - it works)
IF hrs > 23 THEN
hrs = 0
ELSE
hrs = hrs + 1
ENDIF
Maybe I will try to change the HEX to DEC again.
Next...
PJ's DEFINITELY the real deal!
Attachment not found.
DEC 59 is HEX 3b (3 16s and 11 1s).