How to access the internal RTC in a Teensy 4.0?

I had trouble compiling my code (in the Arduino environment) when I had placed the definition of getTeensy3Time() in a separate file. After some head scratching, I realized I had to explicitly #include "core_pins.h" for the compiler to recognize the Teensy3Clock object. This was not necessary when I instead put the definition in the .ino file.

So this is the relevant code in the separate cpp file:

...
Maybe this can help someone else solve a similar issue.

Only the .INO gets any default provided inclusions - primarily ARDUINO.h

Adding just that should work and is less obscure.
 
Thanks defragster for that piece of information. Good to know.
I am more used to an ordinary C/C++ environment where there is perhaps more to learn to get started, but also less of the "helpful" Arduino magic that can let one down in unexpected ways when one goes beyond the simplest projects.
 
The INO is treated special to help use c/cpp without knowing ALL the details and make the build "work" without sweat - a very cool idea for beginners - or even quick lazy examples :)

But underlying that is a real full featured gcc based c/cpp build environment that acts the same. And that Arduino.h is the connective piece for getting to the MCU layer like core_pins.h and the rest of the library linkage details to build.

But having Arduino IDE as the common denominator makes getting started easy and forum code sharing easy, and yet is easily customizable to other build systems or ways. I use github.com/Defragster/Tset to do IDE Command line builds on my Windows system from my chosen editor and is much better for the process I use - but still fully IDE compatible in usage and in the binaries.
 
Yes, I mostly appreciate the simplicity of the Arduino IDE and the minimal configuration and setup necessary to get up and running. But sometimes some of the things that are hidden and make simple cases work effortlessly causes problems when the project grows and knowledge of what is intentionally hidden is required. I might take a look at your way of doing things at some point.

My RTC is working fine (also with battery backup), but it drifts by a few seconds or so per day. I went looking for some kind of trim functionality, but found it neither in the Time library nor in the datasheet for the IMXRT1060, so I suppose there is no support for trimming. Maybe I could implement something by storing a time stamp in the non-volatile memory when I set the time and check it at power on and apply a correction based on how long the unit has been turned off. I can of course also correct regularly while powered on, but the use case is normally to be on for less than three hours, so a correction during that time is not particularly important.
 
Is it possible to update the secure RTC via NTP or download, to today's date and then recall that in future boot ups without a battery connected so all my data logging dates are not Jan 1, 2019?

Do I need a battery? What happens when the battery dies?

It seems like the secure RTC, which can never be programmed to go backwards, should keep a forward moving time, which may be wrong in the absence of battery or NTP time, but won't be Jan 1, 2019 after every bootup. Or am I thinking this wrong?
 
Last edited:
I'm kind of confused. Is there not a simple way to read the "Time" from whatever clock keeps the real time? Is that not the point of a RTC to have the time available without connecting to a source or updating from a computer connection/GPS clock/wireless source.

There are hooks in the system like F_CPU_ACTUAL which has the set CPU clock speed, and ARM_DWT_CYCCNT which counts the cycles since startup.

Is there not a simple register that will pass along the RTC without a bunch of programming?
When I stick this teensy 4.1 into a device that does not get connected, so the RTC does not get updated for months/years can I not count on the RTC to have some sort of time?

I look forward to enlightenment.
 
I'm kind of confused. Is there not a simple way to read the "Time" from whatever clock keeps the real time? Is that not the point of a RTC to have the time available without connecting to a source or updating from a computer connection/GPS clock/wireless source.

There are hooks in the system like F_CPU_ACTUAL which has the set CPU clock speed, and ARM_DWT_CYCCNT which counts the cycles since startup.

Is there not a simple register that will pass along the RTC without a bunch of programming?
When I stick this teensy 4.1 into a device that does not get connected, so the RTC does not get updated for months/years can I not count on the RTC to have some sort of time?

I look forward to enlightenment.

The RTC needs a separate power source to keep it running when the main power is off. Without that, the internal memory is lost and the time is reset. If the RTC power source doesn't recharge itself when the main power is on (or the device simply isn't powered on in a long time), it will eventually go flat.
This is basically the same as a PC - there's a CR2032 battery on the motherboard that keeps the internal clock running when AC power isn't connected.

Retrieving the current time from the RTC is pretty trivial, it's two registers (due to the number of bits in the time value) so you have to read the high register, the low register, then the high register again to make sure it didn't tick over between the reads.
 
I have a battery connected, and in a PC a battery can last for years so I don't see that as an issue.

Is there a reference to the RTC registers and how to read and interoperate them?
 
Here a minimal example:
C++:
void setup(){
}

void loop(){
    time_t time = rtc_get();    // read the current time from the RTC
    Serial.print(ctime(&time)); // convert time_t to readable string and print out
    delay(1000);
}

which prints:
Code:
Sat Jan  6 12:42:43 2024
Sat Jan  6 12:42:44 2024
Sat Jan  6 12:42:45 2024
Sat Jan  6 12:42:46 2024
Sat Jan  6 12:42:47 2024
Sat Jan  6 12:42:48 2024
Sat Jan  6 12:42:49 2024
Sat Jan  6 12:42:50 2024
Sat Jan  6 12:42:51 2024
Sat Jan  6 12:42:52 2024
Sat Jan  6 12:42:53 2024
Sat Jan  6 12:42:54 2024
Sat Jan  6 12:42:55 2024
Sat Jan  6 12:42:56 2024
Sat Jan  6 12:42:57 2024
Sat Jan  6 12:42:58 2024
 
Last edited:
Back
Top