jboyton:
I don't need to test it.
I believe you when you say it exhibits the same problem.
Actually, I'm not sure the test is working properly. We should be seeing either 00:00 or 1:59 if the glitch is present (correct)?
Let's see... if we set to 00:59 and then check it as fast as possible, any "problem" would be either:
- 00 becomes 01 before 59 updates to 00, resulting in an error "01:59"
- 59 becomes 00 before 00 updates to 01, resulting in an error "00:00"
Your test code checks for (seconds == 00 OR minutes == 01) which will result in a match (i.e. "glitch detected") when the time increments from the test setting 00:59 to 01:00 (which is indeed what I saw... 01:00).
Your ORIGINAL test code displayed "glitches" with these two possible values:
01:59
01:00
"01:00" is not a glitch, but the fact that your code spews out a LOT of "01:59" shows that there is indeed a glitch.
So, I need to modify the test code a bit because if there is NO glitch, the while(1) look will encounter 01:00 after one second and print it. So, I'm going to change it to look specificially for either 01:59 or 00:00 but not 01:00 (which matches your test after one second).
(edit to add): Here's the change I made to the glitch detect:
// if rollover, display it. Note: OK to check for decimal 59 'cause we did bcd->dec already
if (((secs == 0) && (mins == 0)) || ((secs == 1) && (mins == 59))) {
displayMMSS (mins, secs);
break;
}
Stay tuned. Once I'm confident that I am properly detecting glitches, then I plan to try something like this in the library driver:
// read 7 bytes of raw clock data to buffer
void DS3234::_read_raw (void)
{
uint8_t x;
for (x = 0; x < 7; x++) {
*(_buffer + x) = _command ((0x00 + x), 0x00);
}
while (x--) { // x is already set so no need!
if (_command ((0x00 + x), 0x00) != *(_buffer + x)) {
_read_raw (); // got a rollover glitch, re-read chip
}
}
}
Question is... it it "legal" to re-enter the function from inside itself? Will that leak memory, or does C handle stuff like that?
I'm picturing the entry into _read_raw() using stack space (for the uint8_t at least) then if I re-enter it, another uint8_t will be allocated. When the function ends, it will only clean up it's first instance and leave the second as a leak. That's what I picture. Is this true or no?