Datasheet 155
Functional Description
5.11 Real Time Clock (D31:F0)
The Real Time Clock (RTC) module provides a battery backed-up date and time keeping
device with two banks of static RAM with 128 bytes each, although the first bank has
114 bytes for general purpose usage. Three interrupt features are available: time of
day alarm with once a second to once a month range, periodic rates of 122 µs to
500 ms, and end of update cycle notification. Seconds, minutes, hours, days, day of
week, month, and year are counted. Daylight savings compensation is no longer
supported. The hour is represented in twelve or twenty-four hour format, and data can
be represented in BCD or binary format. The design is functionally compatible with the
Motorola MS146818B. The time keeping comes from a 32.768 kHz oscillating source,
which is divided to achieve an update every second. The lower 14 bytes on the lower
RAM block has very specific functions. The first ten are for time and date information.
The next four (0Ah to 0Dh) are registers, which configure and report RTC functions.
The time and calendar data should match the data mode (BCD or binary) and hour
mode (12 or 24 hour) as selected in register B. It is up to the programmer to make
sure that data stored in these locations is within the reasonable values ranges and
represents a possible date and time. The exception to these ranges is to store a value
of C0–FFh in the Alarm bytes to indicate a don’t care situation. All Alarm conditions
must match to trigger an Alarm Flag, which could trigger an Alarm Interrupt if enabled.
The SET bit must be 1 while programming these locations to avoid clashes with an
update cycle. Access to time and date information is done through the RAM locations. If
a RAM read from the ten time and date bytes is attempted during an update cycle, the
value read do not necessarily represent the true contents of those locations. Any RAM
writes under the same conditions are ignored.
Note: The leap year determination for adding a 29th day to February does not take into
account the end-of-the-century exceptions. The logic simply assumes that all years
divisible by 4 are leap years. According to the Royal Observatory Greenwich, years that
are divisible by 100 are typically not leap years. In every fourth century (years divisible
by 400, like 2000), the 100-year-exception is over-ridden and a leap-year occurs. Note
that the year 2100 will be the first time in which the current RTC implementation would
incorrectly calculate the leap-year.
The PCH does not implement month/year alarms.
5.11.1 Update Cycles
An update cycle occurs once a second, if the SET bit of register B is not asserted and
the divide chain is properly configured. During this procedure, the stored time and date
are incremented, overflow is checked, a matching alarm condition is checked, and the
time and date are rewritten to the RAM locations. The update cycle will start at least
488 µs after the UIP bit of register A is asserted, and the entire cycle does not take
more than 1984 µs to complete. The time and date RAM locations (0–9) are
disconnected from the external bus during this time.
To avoid update and data corruption conditions, external RAM access to these locations
can safely occur at two times. When a updated-ended interrupt is detected, almost
999 ms is available to read and write the valid time and date data. If the UIP bit of
Register A is detected to be low, there is at least 488 µs before the update cycle begins.
Warning: The overflow conditions for leap years adjustments are based on more than one date or
time item. To ensure proper operation when adjusting the time, the new time and data
values should be set at least two seconds before leap year occurs.
To Next Page
Loading...
Need help?
General
