Author Topic: SAM7X RTC support (based on RTT)  (Read 7183 times)

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3224
    • View Profile
    • uTasker
SAM7X RTC support (based on RTT)
« on: October 28, 2011, 09:41:30 PM »
Hi All

In the uTaskerV1.4-5 version for the SAM7X the RTT has been used as a RTC (real time clock) -

I don't know whether this will be of any real practical use but it allows the RTT to be used as a 1s interrupt source to implement a RTC with support for generating various user interrupt callbacks; second interrupt, minute interrupt, hour interrupt, date/time alarm, stop watch (based on the RTC model in the Coldfire V2 parts -

This is integrated into the uTaskerV1.4 demo project (activated with
Code: [Select]
SUPPPORT_RTC) and allows the time to be displayed in the command line menu and on the administrator web page. The time and date can be set in the command line menu. The operation is then based on conversions between seconds and date/time (Gregorian calendar).

What makes this less useful on the SAM7X is that the RTT doesn't have battery backup and so the counter starts at 0 every time the board is powered up or reset; the actual time and date would have to be primed each time from another source.
The second problem is that the source for the RTT is the slow clock, which is an internal RC oscillator with a range from 22kHz to 42kHz, which is not very accurate as clock source. The RTT prescaler does however allow its value to be manipulated to match the actual frequency that the slow clock is oscillating at in the particular device, although probably additional temperature compensation would be required to keep it accuate (if that is what it can be described as ;-) over longer periods of time.

One interesting effect when programming the RTT is the fact that it is clocked by the slow clock, which is usually much slower than the speed that the CPU is acually operating at. When the RTT interrupt occurs it needs to be reset, which takes some time before the slow clock actually does this. During this time the interrupt would keep repeating until the slow clock has finished the internal register operation, thus making it necessary to also disable the interrupt for some time before re-enabling it again later once the interrupt flag has actually been reset. This is performed in the implementation by letting the TICK interrupt from the PIT (which also shares the same interrupt vector as the RTT and soem other possible sources) re-enable the RTT interrupt later.

In summary, the project includes example support for doing all this but whether the RTT is actually useable is another question.... (generally it would be simpler and more accurate to use the TICK to do the 1s interrupt stuff itself...).