Using the DS87C530/DS5250 Real

文章摘要：A recurring alarm is enabled by disabling the compare enable bits associated with one or more alarm registers. In general, a recurring alarm is set using the next lower time increment. For example, if an alarm once an hour were desired, a compare on the RTAM Register would be performed, because the

Using the DS87C530/DS5250 Real,标签：计算机控制技术,工厂电气控制技术,http://www.88dzw.com
A recurring alarm is enabled by disabling the compare enable bits associated with one or more alarm registers. In general, a recurring alarm is set using the next lower time increment. For example, if an alarm once an hour were desired, a compare on the RTAM Register would be performed, because the RTCM register will match RTAM register only once an hour. For example, if an alarm once an hour on the half hour were desired, the following configuration would be used:

Alarm Subsecond (RTASS)	00 subseconds	= 00h
Alarm Second (RTAS)	00 seconds	= 00h
Alarm Minute (RTAM)	30 minutes	= 1Eh
Alarm Hour (RTAH)	11 hours	=00h
Clock Control (RTCC)	subsecond compare	= E1h
	second compare
	minute compare
	RTC enable

In the above example, the subsecond, second, and minute registers are programmed and the corresponding compare enable bits are set, even though only a match on the minute register is desired. This is because a don't care is always treated as a match for the purposes of evaluating alarms. If the SSCE and SCE bits were cleared to 0 (don't care) in the above example, then a match (and interrupt) would occur during every subsecond of the minute in which the RTAM register matched. This would cause 15,360 interrupts, which is most likely not the desired effect. In general, when specifying a recurring alarm, all the compare bits below the largest time increment should be enabled and the corresponding alarm registers loaded with 00h or a known value.

Alarms can occur synchronously when the clock rolls over to match the alarm condition or asynchronously if the alarm registers are set to a value that matches the current time. Note that only one alarm may occur per subsecond tick. This means that if a synchronous alarm has already occurred during the current subsecond, software cannot cause an asynchronous alarm in the same subsecond.

While this is a relatively minor point, it can have implications if software expects to use the asynchronous capabilities of the alarm. For example, assume an RTC interrupt occurs as when the alarm registers match the current time a 01:00:00:00 (1 hour, 0 minutes, 0 seconds, 0 subseconds). The RTC interrupt is relatively short, taking much less than one subsecond tick (< 4ms), and execution returns to the main program. Immediately upon exiting the RTC interrupt routine, an event occurs that requires software to cause an alarm on the hour by setting the alarm to match on 00 minutes, 00 seconds, 00 subseconds. Normally, setting this alarm condition with the time at 01:00:00:00 would immediately cause an RTC interrupt to occur; but because we have already had an alarm in this subsecond, the condition will not be recognized. The alarm will be missed because it will not be evaluated until the next subsecond tick, when the time will have changed to 01:00:00:01. The designer should guard against the possibility of using synchronous asynchronous alarms in the same subsecond.

Because an alarm condition can occur asynchronously, care must be exercised that a match is not accidentally enabled while writing to the alarm registers. For example, assume that the current time is 0B:00:00:00 and the current alarm conditions are 00:00:00:00. Suppose that software changes the alarm to 0B:01:00:00. If the hour, second, minute, and subsecond compare enables are enabled and the first instruction is MOV RTCH, #0B0H, an alarm will occur immediately instead of at the intended time. The best way to avoid this is to disable all compare enables before changing the RTC alarm registers.

上一页  [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]  下一页