0
\$\begingroup\$

The RTC MCP7940N is used in the system. The microcontroller and RTC MCP7940N are connected through the I2C interface.

I would to know what is the better design to read the timer value from the RTC.

Method #1: Upon receiving the request from other high level modules, the I2C frames are prapared and sent it. The I2C data receive interrupt is used to read the I2C data and compute the time value. An event mechanism is used to inform the required modules about the availability of the new timer value

Method #2: Cyclic task is used to send the I2C frames every 5ms and the received I2C data is polled by the cyclic task to calculate the timer value. The high level modules can read the time value synchonously but the timer value will have the accuracy error of 5ms due to the fact that the RTC timer value is read every 5ms.

Please provide your views on this and the better approach to read the timer value without loading CPU much.

\$\endgroup\$
  • \$\begingroup\$ How accurately does the rest of the system need to know actual clock time? Often just within a second is plenty good enough. \$\endgroup\$ – Olin Lathrop Mar 12 '18 at 11:44
  • \$\begingroup\$ I like the first one better, CPU load is lesser, compared to 2nd approach. But I am not sure of the I2C clock frequency you are using and the interrupt latency that might come with it if high speed (ca 400kHz) transfer is involved. It would also be resistant to EMI problems. :) \$\endgroup\$ – Abel Tom Mar 12 '18 at 12:23
1
\$\begingroup\$

I have built many product applications where the RTC is read at ten times per second. This is plenty fast enough that is a user is reading the time on a screen display they do not notice any non-uniform seconds tick updates.

Periodic reading is important if asynchronous activities cannot live with the latency to access the RTC at their event time.

The RTC read rate is determined from a periodic interrupt that is a core part of the embedded dispatcher for multiple software activities. The actual interrupt rate is 1msec but runs various periodic tasks according to a state machine operating on a cyclic state sequence from 0 to 9 (each state occurs every 10msec). Some states use additional counter variables to throttle task rate such as the RTC reading which used an additional 0-to-9 divider.

The RTC interrupt can keep a counter that counts 0 to 99 and increments once each 1msec. This counter can be synced with the RTC read process (i.e reset) and then used as a higher resolution time component beyond the seconds value from the RTC.

You can extend this even further by just reading the HHMMSS from the RTC at the 10 times per second to make reading time typically be shorter. Then once per second you can read the additional YYMMDD / DAY values out.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.