exists long-running os (kernel) clock? handling os clock wrap.

lloyd konneker

Other Parts Discussed in Thread: CC2650, SYSBIOS

I am reading the TI-RTOS Kernel v6.46 User's Guide. The default OS clock (on which you can schedule tasks, or get kernel time using kernel.Clock_getTicks()) seems to wrap (counter rolls over to 0) every 5 days (since it is 32-bit with a resolution of say 1mSec). Is there a longer running os clock with the same resolution that wraps less often? Say hundreds of years, for all practical purposes, never.

Is there a callback from the OS when the kernel clock wraps?

This example in the User's Guide seems flawed:

UInt32 time1, time2;
. . .
System_printf("task going to sleep for 10 ticks... \n");
time1 = Clock_getTicks();
Task_sleep(10);
time2 = Clock_getTicks();
System_printf("...awake! Delta time is: %lu\n", (ULong) (time2 - time1));

If the os clock wraps between time1 and time2, the difference is wrong: very large instead of small.

It seems simple enough to do. It should be similar to an example in TI literature that implements a long-running (64-bit?) wall-clock using a 32khz xtal timer. So my question is not HOW to do it, but whether it exists already. Or, whether there is a correct example for differencing os times that are asserted near in sidereal time, handling possible os clock wrap. Or using a combination of the seconds clock and the os clock?

over 10 years ago

0 lloyd konneker over 10 years ago

Expert 1790 points

I see the example bigTime in the CC2650 examples. But its much more than I want. Also, it seems it is not low-power and still have mSec resolution, since it seems to depend on a running PRD (peripheral device?) Clock.

But now I think the solution is easy. The RTOS os clock (based on a hw xtal timer) provides the least significant 32-bits of resolution. Whenever you access BigClock, you first check whether the os clock has rolled over since the last time you accessed it. If so, you increment the most significant 32-bit int. Concatenate the least and most significant bits into 64 bits and return it.

Or again, is a long-running clock already in the RTOS?

0 Aldabreu over 10 years ago

TI__Intellectual 2890 points

Hi Lloyd,

Currently the SYSBIOS Clock module has a maximum 32-bit count associated with it. In order to get around this, you can create your own Clock object with a period of 0xFFFFFFFF such that you'll be notified when the 32 bit count is about to overflow. In this way you can keep track of how long your clock has been running for(using Clock_getTicks, in conjunction with your own count).

Best,
Alexander

0 lloyd konneker over 10 years ago in reply to Aldabreu

Expert 1790 points

Thanks, yes, that is one way to do it.

Do you think the example is flawed? (which is not the main question.)

If you have time, please look for my separate post "Scheduler in RTOS?" which asks a related question, can you schedule a thread for future execution?

0 Aldabreu over 10 years ago in reply to lloyd konneker

TI__Intellectual 2890 points

Hi LLoyd,

There's a trade off between power and precision. In this case you can either have the high power high precision timer running, or the low power RTC. As far as the example being flawed, they're meant to serve as a simple starting point and we attempt to keep them as simple as possible while demonstrating a few key features of the Kernel.

Best,
Alexander

0 lloyd konneker over 10 years ago in reply to Aldabreu

Expert 1790 points

I don't want a clock more precise (more LSB), I want it to wrap less often (more significant bits.) You can get MSB clock in software w/o using more power (just a few more cpu cycles, especially if it is lazy evaluated.)

After studying it, I think the example IS correct. Subtracting two unsigned ints is modulo arithmetic, so subtracting an earlier OSClock tick from a later tick gives you the correct result (an unsigned delta time, or duration), even if the clock has wrapped between the earlier and later ticks. Except if the clock has wrapped more than once (in this case of a 32khz clock of 32-bits, if more than a few days has elapsed.)

So I don't even NEED a longer running clock, as long as I am not recording times (and differencing them) more than a few days apart. Which I suppose is what the provided seconds clock is useful for.

0 lloyd konneker over 10 years ago in reply to lloyd konneker

Expert 1790 points

But now I find that if the earlier time is not actually earlier than the later time (for example if the later time is calculated, a time at which you want to schedule some event but is actually in the past, and the earlier time is now, naive math will give you an incorrect answer for the delta/timeout (and using a long running clock might help.)

Processors

Processors forum

exists long-running os (kernel) clock? handling os clock wrap.