jboyton:
By "one at a time" I meant that CS is asserted and then deasserted for each byte. In a burst read CS goes active low, multiple bytes are transferred, and then CS goes high. That section of the datasheet you quoted is the reason why this is desirable:"...the user buffers are synchronized
- to the internal registers on the falling edge of CS...*
When you assert/deassert CS for each byte you latch the time repeatedly. If there is a rollover while doing this you may get the wrong time/date. For example, suppose the time is 10:59:59. It's possible to read the seconds as "59", the time rolls over to 11:00:00, and then you read minutes and hours ending up with "11:00:59". The odds of seeing this happen aren't very high, but it is a possibility.
If you do a burst read the data is latched only once so you are guaranteed that it will not change.
http://pdfserv.maximintegrated.com/en/an/AN4005.pdf
Well, I see what you are saying, but I find it hard to believe that Dallas / Maxim would allow a possible read error like that to ever occur.
Yet, the way it's worded and the way you explain it, I see what you are saying and you might be right.
So, what I plan to do is setup a test where I set the time to something like 23:59:59 and then just keep reading it as fast as the Arduino can and see if a misread ever occurs.
Then, I'll run that same test with various small (microsecond sized) delays in between reads to remove the possibility that the Arduino read rate happens to match something in the RTC and mask the problem.
If it does, then I guess my driver will have to do a read, wait "some" amount of time (TBD) then read again and compare the two to prevent that problem from ever happening.
Thanks for pointing it out.