Re: specific timing
On Thu, 19 Aug 2010 13:52:05 -0700 (PDT), mfc <mfcprog@googlemail.com>
wrote:
Hi,
is it a good solution to start a timer in the OnTimer method? This
timer Timer2 should be called only once -> after that the Timer2 will
be killed and restarted after the next Timer1 event.
Some words to the specific timing: every 25ms a new frame will be sent
by the serial interface. Each frame starts with a start condition
(100?s low impulse without the stoppbits etc.) after that some
"normal" data will be tx by the serial interface (e.g. with two
stoppbits and so on).
Therefore I have to set/clear some GPIO pins to get this required
timing. Unfortunately Sleep() only works for ms delays; How is it
possible to maintain the timings - only with additional timers?
void OnTimer( UINT_PTR nIDEvent )
{
if(nIDEvent == Timer1)
{ //will be called every 25ms
//do some stuff
ClearGPIO(Pin5);
//wait 100?s - how is that possible - only with an additional
timer???
SetGPIO(Pin5);
ClearGPIO(Pin7)
SetTimer(Timer2, interval2, NULL);
//WM_FILL_TX_BUFFER will be txd
} else if(nIDEvent == Timer2)
{ //will be called if fired every 22ms
SetGPIO(Pin7)
KillTimer(Timer2);
//send message to another thread
PostThreadMessage(WM_FILL_TX_BUFFER, 0); //do some stuff until
Timer1 will be called again
}
}
The PostThreadMessage() will send a message to another thread, which
has to fill all tx buffers. These buffers will be send during the
OnTimer. How could I satisfy that all buffers will be filled with new
datas, when the next timer interrupt occured?
best regards
Hans
You can't get there from here. Windows timers are not precision and
certainly not at uS accuracies. WM_TIMER messages can be preempted,
skewed, queued and are completely unreliable for mS accuracies. Even
though the documentation says units of mS apply, the timers are only
good for 10mS or 15mS depending on the OS version. Sleep() has the
same problems. Windows is not a RTOS for this purpose.
You might be able to get mS resolution from Windows media timers but
certainly not uS resolution. See timeGetDevCaps for determining what
your target platform is capable of. Speculative execution and
pipelining means you can't even loop your way through a time delay of
100 uS reliably on the x86 platform.
The minimum resolution in user-space apps is 1mS. AFAIK that is the
minimum resolution on all systems.