|
Using BCD in internal timekeeping is inefficient and no modern operating system with which I am familiar does such a thing. Computing into the future (or into the past) while maintaining time in hours-minutes-seconds format produces slow code, as the passage of time is no longer a linear progression and edge cases must be considered. Even in a linear counter, BCD will be slower than binary, as you can no longer use simple increments to step the counter.
Consider also that the 65C02's ADC and SBC instructions are one cycle slower in BCD mode than in binary mode. This characteristic results in a cumulative effect in repetitive code and is to be avoided in interrupt service routines (ISR). Using one or more binary counters in contiguous memory produces much faster-executing and more succinct code. This gain becomes especially important in a system with multiple interrupt sources coming from multiple devices (for example, my POC V1.2 unit has a total of 10 possible IRQ sources in three devices).
In my POC units, there are two counters that are maintained by the jiffy IRQ (which is generated by a DUART timer). One counter is 32 bits and represents system uptime in seconds. The other counter (the TOD counter) is 40 bits and represents the date and time of day as a count of the number of seconds that have elapsed since the "epoch," which is midnight October 1, 1752 UTC. There is also the jiffy counter, as described above. The uptime and TOD counters are zeroed at reset, and the jiffy counter is initialized to the jiffy IRQ rate, which is 100. BIOS API calls exist to read both uptime and TOD, as well as write TOD to set the time of day.
As the TOD counter starts at $0000000000 following reset, it will initially represent the epoch. In the current firmware, there is no provision for setting TOD to the current date and time (something which I will soon address, since POC V1.2 now has enough ROM space for the additional code). To set TOD I use an external function to read the RTC's registers and convert the resulting multiple BCD values to the single binary value needed to set the TOD counter. This is the only time the RTC is accessed.
I absolutely do not want to access the RTC in an interrupt service routine because such accesses must be wait-stated and thus will noticeably drag down interrupt performance. The only hardware access that has to be performed to keep time is to the DUART generating the jiffy IRQ, which is a simple register read and mask to check if the timer has interrupted. That is many times faster than progressively reading RTC registers and manipulating multiple BCD values that are non-contiguous in nature.
If an application needs to use the date and time-of-day in broken-down (human-readable) format it calls a library function that makes the conversion. The conversion between internal time and broken-down format is done with four-function arithmetic, which is readily implemented on the 65C02 or 65C816.
_________________ x86? We ain't got no x86. We don't NEED no stinking x86!
|
Login
Register
FAQ
Search
