嵌入式系统时钟

Question

I'm developing a project, where I need to support a calender + clock with ms granularity. I managed to configure the RTC of the chip to aid me with time keeping, but I'm having difficulty finding the correct data type to present the time.

I always worked with time_t (The Unix epoch), however it is seconds based, so it's not going to work. What about struct timeval ? it appears that this structure is not supported as the struct tm in the context of presentation (asctime).

What is the preferred way to represent the time in an embedded system ?

note: This system interfaces a java based back-end server and needs to synchronize the time with it, so I'm looking for a structure that could be used out of the box in several languages.

Answer 1

Your need for millisecond granularity and to interact with something Java based both suggest that 64-bit time since epoch would be a suitable, and straightforward, choice.

Most compilers today have 64-bit types; if not you can handle it as a struct of two 32-bit types in local endian appropriate order and put in code to handle the carry.

Answer 2

There's milliseconds and milliseconds, one is easy, the other is hard.

We run a 1ms hardware timer interrupt loop that handles stuff (motor control for example) which has to operate on a solid raster. We increment a global 32-bit "ticks" value from within this routine which can then be used to time stuff that needs to happen at sub-second intervals (EG polling something every 50ms).

That's not the same as using a the micro's hardware timer as a timekeeping reference, there are issues with the accuracy of anything in a system like this - from the accuracy of your clock crystal to all the various prescalers, interrupt latency, etc. Now, we don't care if our motor control routine runs 999 times per second or 1001 times a second, or if we poll the state of a pin every 49.5ms rather than 50, because it's close enough, and what's important is that it happens in a timely manner. Over the course of 24 hours we may well end up with a load more "ticks" than there are milliseconds in the day, which would make for a terrible watch.

For example - does the clock prescaler count to N and then reset, or n-1 and reset? Does it reset instantly or does it take one clock cycle? This sort of detail makes for timing headaches in micros.

I would use the RTC as the time-of-day reference and then perhaps synchronise the ms counter to the ticking of the seconds (reset "ticks" to 0 every 1Hz RTC interrupt) which would mean your ms-value would only ever be very slightly out relative to the RTC. You may even be able to read the input-clock register of the RTC directly to extract the much faster clock that runs the RTC (typically a 32.768kHz clock). We do this to get microsecond values from our 1kHz timer's prescaler clock register. It's not perfect, we don't use it to keep time, only to catch sub-ms events.

Alternatively, look at if you really need ms at all for the application, or if you could just make up a number that's within 100ms and report that, it's not like JS is atomic-clock grade timing wise - it's not even mickey-mouse-watch-grade. If you really do need that accuracy, you're doing it wrong.