26.02.2014 Views

Getting Started with QNX Neutrino - QNX Software Systems

Getting Started with QNX Neutrino - QNX Software Systems

Getting Started with QNX Neutrino - QNX Software Systems

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Clocks and timers<br />

© 2009, <strong>QNX</strong> <strong>Software</strong> <strong>Systems</strong> GmbH & Co. KG.<br />

Base timing resolution<br />

<strong>Getting</strong> more precision<br />

The point of this story is that regardless of the nice round value shown, the real value<br />

is selected to be the next faster value.<br />

Let’s say that the timer tick is operating at just slightly faster than 10 ms. Can I<br />

reliably sleep for 3 milliseconds?<br />

Nope.<br />

Consider what happens in the kernel. You issue the C-library delay() call to go to sleep<br />

for 3 milliseconds. The kernel has to set the variable in the ISR to some value. If it<br />

sets it to the current time, this means the timer has already expired and that you should<br />

wake up immediately. If it sets it to one tick more than the current time, this means<br />

that you should wake up on the next tick (up to 10 milliseconds away).<br />

The moral of this story is: “Don’t expect timing resolution any better than the input<br />

timer tick rate.”<br />

Under <strong>Neutrino</strong>, a program can adjust the value of the hardware divisor component in<br />

conjunction <strong>with</strong> the kernel (so that the kernel knows what rate the timer tick ISR is<br />

being called at). We’ll look at this below in the “<strong>Getting</strong> and setting the realtime<br />

clock” section.<br />

Timing jitter<br />

There’s one more thing you have to worry about. Let’s say the timing resolution is<br />

10 ms and you want a 20 ms timeout.<br />

Are you always going to get exactly 20 milliseconds worth of delay from the time that<br />

you issue the delay() call to the time that the function call returns?<br />

Absolutely not.<br />

There are two good reasons why. The first is fairly simple: when you block, you’re<br />

taken off the running queue. This means that another thread at your priority may now<br />

be using the CPU. When your 20 milliseconds have expired, you’ll be placed at the<br />

end of the READY queue for that priority so you’ll be at the mercy of whatever thread<br />

happens to be running. This also applies to interrupt handlers running or<br />

higher-priority threads running — just because you are READY doesn’t mean that<br />

you’re consuming the CPU.<br />

The second reason is a bit more subtle. The following diagram will help explain why:<br />

140 Chapter 3 • Clocks, Timers, and <strong>Getting</strong> a Kick Every So Often April 30, 2009

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!