|
Pin
Names and functions
Registers
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Address = | 1 | 0 | 1 | 0 | 0 | 0 | 1 | r/!w |
When I first fired up this device, and reading the raw data, some of the bytes were changing values unexpectedly. The seconds and minutes seemed fine though.
After clearing everything to zero, I noticed that the hours register was 40 (BCD) whenever the seconds register was >= 40. Bit(s) from one register are appearing in others! That explains why the mystery bits changed consistently, instead of randomly as you would expect signal noise to be. Looking at the data sheet, the hour is BCD coded in D5-D0, while D7 and D6 are undefined. They are not legally bound to be anything at all!
So although puzzling at first, this behaviour is not a bug or noise.
The device does not handle leap years correctly. The data sheet states that:
"The PCF8563 compensates for leap years by adding a 29th day to February if the year counter contains a value which is exactly divisible by 4, including the year ‘00’."
Jean Meeus' book Astronomical Algorithms states (on page 62) that:
"...centurial years that are not divisible by 400, such as 1700,1800,1900 and 2100, are common years.
The other century years which are divisible by 400, are leap years, for instance 1600,2000, and 2400."
Therefore this chip behaves correctly for years 1901 to 2099, but will mistake 2100 for a leap year! You heard the Y2K1 bug warning here first, but I won't be around by that time! :-)