This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

RTC with 1ms resolution - YYYY-MM-DD HH:MM:SS.mmm

Hi!

I would like to create a RTC for stamping log messages, with 1ms resolution and including time from year to millisecond, like: YYYY-MM-DD HH:MM:SS.mmm.

What would be the best solution?

The 32kHz clock is not divisible by 1000, which means that some special handling is needed for accurate results.

regards, Elm

Parents
  • A colleauge suggested this: Set up a continually running application timer, using the 32kHz clock, and make it fire every 32 clocks. This results in a clock that ticks 1024 ticks per second. Let the handler be tick_1024(). let tick_ms() be a function to be called every ms, on average. Then:

    void tick_1024() {
        static uint16_t a;
        a += 1000;
        if( a>= 1024) {
            a -= 1024;
            tick_ms();
        }
    }
    

    Essentially, it multiples the tick frequency of 1024 Hz with 1000/1024.

    What do you think? //Elm

Reply
  • A colleauge suggested this: Set up a continually running application timer, using the 32kHz clock, and make it fire every 32 clocks. This results in a clock that ticks 1024 ticks per second. Let the handler be tick_1024(). let tick_ms() be a function to be called every ms, on average. Then:

    void tick_1024() {
        static uint16_t a;
        a += 1000;
        if( a>= 1024) {
            a -= 1024;
            tick_ms();
        }
    }
    

    Essentially, it multiples the tick frequency of 1024 Hz with 1000/1024.

    What do you think? //Elm

Children
  • Probably not a good idea to run a millisecond process on interrupts with a 64MHz processor. Depending on how much other activity is going on this could create backlogs of interrupts to be serviced. And, since you are looking to do a quasi RTOS process it would be better to run seconds and milliseconds as counters set to restart at the correct interval. All of this can be done in hardware on PPI. In this manner you only need to capture the register values to get the fine resolution part of the timestamp. The rest of the timestamp can just be kept in software registers.

    You didn't say what type of event was being logged. If by chance it is a hardware event like a comparator or external gpio input, etc. then the entire process is hardware driven with only a minor reporting function occurring in code.

Related