Maxim实时时钟芯片设计指南5413-二进制编码十进制（BCD）格式实时时钟中的状态机逻辑

Each counter register has defined minimum and maximum values, and most are preset to their appropriate minimums on initial power application. As a natural function of timekeeping, when the Seconds count reaches the maximum value, the next increment causes a carry to the Minutes register and the Seconds rolls over to the minimum value. A Minutes rollover carries to the Hours; the Hours rollover carries to both the Date and arbitrary Day-of-Week registers; the Date rollover carries to the Month register; the Month rollover carries to the Year register; and if applicable, the Year rollover carries to the Century register. Table 1 lists the registers and associated range of legal values.

 

Some variations on the counter implementation may include a ‘Hundredths of a Second‘ register (precedes Seconds), and a Century bit to flag the Year register rollover.

For each register, the normal state machine logic is to increment the BCD count from the minimum to the defined maximum, and then roll back over to the minimum while applying the carry to the next register. For an example, the Date register BCD count sequence for a 30-day month would be 01h...09h, 10h...19h, 20h...29h, 30h, and then roll back to 01h.

Maxim does not critique the values a user might install during operation, so the ramifications of loading improper values are based upon the specific component and which register(s) was actually involved. Illogical time and date entries may result in unexpected operation.

The Hundredths of a Second register (if applicable) counts from 00h to 99h. The next increment causes the counter to roll over to 00h and the carry is applied to the Seconds register. All 8 bits in this register are read/write capable. Devices containing this register are internally clocked from the 4kHz time base (32.768kHz/8).

The Seconds register counts from 00h to 59h. The next increment causes the counter to roll over to 00h and the carry is applied to the Minutes register. Only the least significant 7 bits in this register are usually read/write capable. Most devices not containing a Hundredths of a Second register are internally clocked from the 1Hz time base.

The Minutes register also counts from 00h to 59h. The next increment causes the counter to roll over to 00h and the carry is applied to the Hours register. Only the least significant 7 bits in this register are read/write capable.

The Hours register accommodates either a 12-hour format (with an AM/PM designator) or a 24-hour clock. A control bit (usually bit6 = 12/%-overbar_pre%24%-overbar_post%) is used to identify the clock operating mode. Only the least significant 7 bits in the Hours register are read/write capable. In the 24hour Mode (bit6 = 0), the Hours register counts from 00h to 23h. The next increment causes the counter to roll-over to 00h and the carry is applied to both the Date and Day registers.

In the 12-hour mode (bit6 = 1), the Hours register count sequence, starting at "12AM", counts 52h, 41h...49h, 50h, and then 51h. The next increment causes the counter to roll over to 72h with the carry applied to the %-overbar_pre%AM%-overbar_post%/PM bit (PM = 1). The register then counts 72h, 61h...69h, 70h, 71h and the next increment causes the counter to roll over to 52h as PM is cleared, with the carry applied to both the Date and Day registers. For clarification, 12 midnight is 12:00:00 AM and 12 noon is 12:00:00 PM.

The Day (Day-of-Week) register is the most simplistic counter, with an intended content of 01h to 07h. The next increment causes the counter to roll over to 01h with no carry. Should a user accidentally deposit a 00h content into this register, there is no adverse effect upon the other timekeeping registers, but the first week of clock operation will have 8 days (0 7). The Day register only has three functioning bits, so even though it initially seems impossible for the user to load a value greater than 7, any hex value > 7 written would store the bad value logic-ORd with the three functioning bits (07h) (e.g., writing 1Fh would store a 07h, or writing F5h would store a 05h). Normal calendar convention is to define Sunday= 1, but that definition is arbitrary and fully under the user‘s control.

The Date register counts from 01h to the defined end of the present Month. The end of the month is dependent upon the present Month and Year content (in the case of February). Only the least-significant 6 bits in the Date register are read/write capable. Table 2 lists the three options.

 

The Month register counts from 01h to 12h. The next increment causes the counter to roll over to 01h and the carry is applied to the Year register. To address Y2K issues in the late 20th Century, a Century bit was included in the MSB of the Month register on components that did not include a full 8-bit Century register. This Century bit facilitated easy detection of the century change, as the bit changes state upon a Year register rollover from 99h to 00h. Care should be taken when loading new calendar values to avoid corrupting the Century bit logic condition. Please refer to the register map for the specific component in question; conventional register placement leaves bits 7 and 4:0 as read/write capable.

The Year register counts from 00h to 99h. The next increment causes the counter to roll over to 00h and the carry is applied to either the Century register or the Century bit, whichever is applicable to the component in question. All 8 bits in this register are read/write capable.

Leap Year compensation is based upon the era of the specific chip design, and applicability is normally annotated on the cover page of that data sheet. For most chip designs that do not include a Century register, the Leap Year compensation functions properly through 2099 and is assumed to be the result of this expression:

If MODULO (CALENDAR_YEAR/4) == 0

Due to the era of existing chip designs, many of today‘s RTC components containing a Century register apply the same algorithm solely upon on content of the Year register, and therefore will incorrectly designate 2100 as a leap year.

The DS1347 RTC utilizes the full Gregorian algorithm to determine Leap Year adjustments for February:

Leap_Year = 0                            ; default to No
    If MODULO (CALENDAR_YEAR/4) == 0                ; divisible by 4?
        If MODULO (CALENDAR_YEAR/100) == 0            ; divisible by 100?
            If MODULO (CALENDAR_YEAR/400) == 0        ; divisible by 400?
                Leap_Year = 1
            end            ; if
        else
                Leap_Year = 1
        end                ; if
    end                    ; if