Lower hanging fruit: RTC on Adalogger

Code: [ firmware ] [ host PC ]

Well, SD cards are somewhat involved. So I’ve just been working on the easier problem of setting up the RTC: easier because there’s a library for it and all I need to do is setup a connection with Processing so I can configure the real time clock module on SAMD21!

Just so you know, I just learned about [ UNIX time ] and was quite excited to use it because of this [ post ]:

In the end, the only thing that really works for all situations,
is using a single epoch and then converting to timezone offsets
as needed. The unix guys really did get it right way back then.

Also, I should mention that it seems easier to store numbers in the logger’s memory, than to deal with strings like “12:00 AM 05/24/16”. And we could do a re-sync whenever the recorder is programmed so there’s aren’t any significant offsets. Besides, knowing an absolute number, we can always figure out what local times may have been!

But then I decided to not use epoch since the registers themselves are mapped to date/time:


[ Source, pdf p. 294 ]

And converting the epoch to these register values is being done in software in the RTCZero library:

void RTCZero::setEpoch(uint32_t ts)
if (ts < EPOCH_TIME_OFF) {

time_t t = ts;
struct tm* tmp = gmtime(&t);

RTC->MODE2.CLOCK.bit.MONTH = tmp->tm_mon + 1;
RTC->MODE2.CLOCK.bit.DAY = tmp->tm_mday;
RTC->MODE2.CLOCK.bit.HOUR = tmp->tm_hour;
RTC->MODE2.CLOCK.bit.MINUTE = tmp->tm_min;
RTC->MODE2.CLOCK.bit.SECOND = tmp->tm_sec;

while (RTCisSyncing())

So regular date/time it is.

Although SAMD21 supports both an AM/PM and a 24 hour format, using an AM/PM format requires me to monitor an hour bit to determine the actual time (” HOUR[4] represents AM (0) or PM (1).” from the datasheet). Even though the end user may prefer AM/PM, writing out recording names by time would require using conditionals either way. So, I’ll just skip having to re-configure the RTC for AM/PM, and go with the 24 hour format for the RTC itself. We’ll bring back the AM/PM for filenames and such. And if RTC is to be reconfigured, its probably just one line to write CTRL.CLKREP anyway!

This week’s update is late…oh my!…and it consists of broken code! But here’s what I did:

  1. Processing code for sending current time and possible alarm times to SAMD21 from a host PC (over Serial)
    Status: mostly working. Checked by transmitting the received times back. Error-checking can be improved.
  2. Firmware for initializing the Real-Time Clock and Alarm0 using received information
    Status: just RTCZero library calls => working. Alarm0 information is transmitted back to double-check the registers.
  3. Firmware for going into sleep mode until Alarm0 hits.
    Status: working
  4. Firmware for configuring the next Alarm0 from information received in 1.
    Status: nope, fails.

Here’s a short video demoing an LED going off when the first alarm hits:

================== update ==================

It turns out that putting the processor to sleep is causing the problem! There was a comment in the library about it that I ignored!

void RTCZero::standbyMode()
// Entering standby mode when connected
// via the native USB port causes issues.

But then I found a multiple alarm example for the same library, which wasn’t included in the actual release (see this) but is forked here. Thanks agdl! And this implementation uses a linked list to hold alarm info – a much cleaner implementation of what I was trying to do.

Multiple alarms appear to work without going to sleep. Now its to see if they are still timed right!


One thought on “Lower hanging fruit: RTC on Adalogger

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s