Using the Real Time Clock to display the date
Archiver
Posts: 46,084
On 24 Sep 01 at 5:10, rpsu279@y... wrote:
> I believe the 0's following hrs come from Bits 6 and 7 respectively
> from the hour register definition.
The program uses "burst mode", so it has to send/receive the register
values in the prescribed sequence: seconds, minutes, hours, date,
month, day (of week), year, control... The SetTime SHIFTOUT sends
the program's values for seconds, minutes and hours, then 0 for the
date, 0 for the month, the program's value for day, 0 for the
year and finally 0 for the control register. The 0s for date, month
and year are essentially place-holders since those registers aren't
used by the program.
> ...The GetTime subroutine doesn't seem as obvious. How come the
> last three variables are day? This question is baffling me.
The GetTime SHIFTIN loads the program's variables for seconds,
minutes, hours and day (of week). As with the SHIFTOUT routine, the
date, month and year are not of interest to this program, but the
DS1302 doesn't (can't) know that, so it sends those values anyway in
the burst mode data stream. Because SHIFTIN has to do something
with that incoming but unused data, the program's author used another
tool in the Stamp bag of tricks: put the value in a variable that
will be over-written shortly with desired data. In this case, the
author chose the "day" variable. So date gets stored in "day", then
month overwrites that, then finally day gets stored in "day". The
alternative is to use up (waste) some other variable space to dump
the unused data into.
> For the year (this is where I'm confused):
> 10's of year (00-99): Upper nibble?
> 1's of year (00-99):Lower nibble?
>
> Here's how the data sheet shows this:
>
> |
|
|
> 00-99 | 10 year | year |
> |
|
|
>
> Not sure how to interpet that. Only sense I could make is that the
> year is a 2-digit number and not a 4-digit but that would seem to
> contradict what the Stampworks book claims of "leap year
> compensation valid up to the year 2100"? It is not to clear to me
> the earliest year that is valid? Is it 2000,0, 1900, or some other
> year? If it is 2000, then it would make a little sense.
You are correct re the 2-digit value for year. The chip knows the
year within a century, but doesn't know the century. The high-order
nibble contains the number of tens in the year value (e.g. 7 if year
= 75). The low order nibble holds the number of ones in the year
value (e.g. 5 if year = 75). Since 2000 was a bit of an exception to
the normal leap year logic, I'm guessing Dallas simplified the leap
year compensation logic to make it right for 2000 at the expense of
making it wrong for 2100, 2200 and 2300 (which will not be leap
years). The chip can't know if you mean 2000 or 2100. In any case
the leap year compensation would be right for at least 1901 - 2099;
at worst, the chip gets it wrong once every 100 years.
Regards,
Steve
> I believe the 0's following hrs come from Bits 6 and 7 respectively
> from the hour register definition.
The program uses "burst mode", so it has to send/receive the register
values in the prescribed sequence: seconds, minutes, hours, date,
month, day (of week), year, control... The SetTime SHIFTOUT sends
the program's values for seconds, minutes and hours, then 0 for the
date, 0 for the month, the program's value for day, 0 for the
year and finally 0 for the control register. The 0s for date, month
and year are essentially place-holders since those registers aren't
used by the program.
> ...The GetTime subroutine doesn't seem as obvious. How come the
> last three variables are day? This question is baffling me.
The GetTime SHIFTIN loads the program's variables for seconds,
minutes, hours and day (of week). As with the SHIFTOUT routine, the
date, month and year are not of interest to this program, but the
DS1302 doesn't (can't) know that, so it sends those values anyway in
the burst mode data stream. Because SHIFTIN has to do something
with that incoming but unused data, the program's author used another
tool in the Stamp bag of tricks: put the value in a variable that
will be over-written shortly with desired data. In this case, the
author chose the "day" variable. So date gets stored in "day", then
month overwrites that, then finally day gets stored in "day". The
alternative is to use up (waste) some other variable space to dump
the unused data into.
> For the year (this is where I'm confused):
> 10's of year (00-99): Upper nibble?
> 1's of year (00-99):Lower nibble?
>
> Here's how the data sheet shows this:
>
> |
|
|
> 00-99 | 10 year | year |
> |
|
|
>
> Not sure how to interpet that. Only sense I could make is that the
> year is a 2-digit number and not a 4-digit but that would seem to
> contradict what the Stampworks book claims of "leap year
> compensation valid up to the year 2100"? It is not to clear to me
> the earliest year that is valid? Is it 2000,0, 1900, or some other
> year? If it is 2000, then it would make a little sense.
You are correct re the 2-digit value for year. The chip knows the
year within a century, but doesn't know the century. The high-order
nibble contains the number of tens in the year value (e.g. 7 if year
= 75). The low order nibble holds the number of ones in the year
value (e.g. 5 if year = 75). Since 2000 was a bit of an exception to
the normal leap year logic, I'm guessing Dallas simplified the leap
year compensation logic to make it right for 2000 at the expense of
making it wrong for 2100, 2200 and 2300 (which will not be leap
years). The chip can't know if you mean 2000 or 2100. In any case
the leap year compensation would be right for at least 1901 - 2099;
at worst, the chip gets it wrong once every 100 years.
Regards,
Steve