Timing measurements on windows

Hi
I am writing an application on Windows XP which send/receive data from an embedded device on a USB port.

When I receive data from the embedded device, it must arrive in set time limits. I realize that windows is not an RTOS, but still there must be some mechanism to measure timings e.g. after after I have sent a packet to my embedded device, some mechanism to count how many milliseconds have passed since I sent the packet.

Could anybody please give me directions on how can I achieve this? Basically I am interested in knowing what constructs/facilities Windows provides to measure "timer" type features.

Thanks
Samie

There are several functions of different levels of portability:
1. clock() - generic function that returns fairly precise timings.
2. QueryPerformanceCounter/QueryPerformanceCounterFrequency
3. RDTSC processor instruction.

--
Mats

There is also timeGetTime() which returns a very exact millisecond clock (I used it to create a loop that looped for exactlly 1s).

What sort of timer resolution were you looking for? (that determines what timer to use)

The thing to remember about MS OS's is the OS message queue can ignore timer msgs (and paint msgs are concatinated).

For this reason timers are not overly accurate.

Quote:

---

Originally Posted by Elysia

There is also timeGetTime() which returns a very exact millisecond clock (I used it to create a loop that looped for exactlly 1s).

---

Minimum resolution is >5ms.

I would use QueryPerformanceCounter/QueryPerformanceCounterFrequency (if available).

Quote:

---

I am writing an application on Windows XP which send/receive data from an embedded device on a USB port

---

You may want to check out USB Isochronous Transfer to send/receive data from your device on a USB port. If this is what you need, then download Windows DDK and check out the ISOUSB sample.

QueryPerformanceCounter() is the best solution here IMO. timeGetTime() is not accurate.

You can also set the resolution for timeGetTime; default resolution on Windows 95 is one ms!
Anyway, try which solution works best.

QueryPerformanceCounter is much more precise than 1ms, it's at the very least capable of milliseconds, and on modern machines it often uses better timers, such as PM timer, APIC timer or some other high-res timer.

--
Mats

> after after I have sent a packet to my embedded device, some mechanism
> to count how many milliseconds have passed since I sent the packet.
Are you attempting some kind of 'time-based' flow control to regulate how much data you send to the device?

I actually read (perhaps mistakenly) the original post to want to do some sort of performance measurement. But other options are of course possible - like so many posts here, the "purpose of the question" is not explained, and we have to guess what is the right solution to the question.

--
Mats

Thanks to all of you for your replies and suggestions.

>Are you attempting some kind of 'time-based' flow control to regulate how much data you send >to the device?


No. It is not time-based flow control that I am trying to attempt .

What I am trying to do is that my application thread on Windows expects 32 KB of data from the embedded device on USB link, every 250 milliseconds. If I dont get this much data in 250 milliseconds, I know there is something wrong and I take measures for it.

In an embedded environment, I could create a timer and let it generate an interrupt after 250 ms and in the ISR for this check if I have received the expected number of bytes. If not, take action. If yes, things are going ok.

However, to do this on Windows, I wasn't too sure what to do for this and hence the reason for the question. It looks like I may have to try TimerProc() type functionality.

Thanks
Samie

How do you do the "receive from USB" function? Are you using a file-read, or some other interface?

I'm thinking that you want to do a WaitForSingleObject() with a timeout of 250ms.


At the same time, I guess you would need to read the data no matter what - just that if it arrives late (or there isn't enough data there) you may want to discard the actual data. So perhaps you need to figure out what happens when/if data is late.

--
Mats

You could also use Sleep to sleep for 250ms. This will not take any cpu power, and it's also easier than WaitForSingleObject so it might be a better idea.

Quote:

---

Originally Posted by Elysia

You could also use Sleep to sleep for 250ms. This will not take any cpu power, and it's also easier than WaitForSingleObject so it might be a better idea.

---

But that means that the application CAN'T process any data that comes in during this time. And it's only "easier" because you have to type less. A Sleep() is actually implemented as a WaitForSingleObject() [or some varation of that], where it's waiting for a Timer Event.

--
Mats

That's why we usually have threads.
If it's a Window app, you need a thread anyway since the main thread needs to process messages.

Quote:

---

Originally Posted by Elysia

That's why we usually have threads.
If it's a Window app, you need a thread anyway since the main thread needs to process messages.

---

Yes, but you still have the problem of deciding if your sleeping thread woke up first, or if you received the data first. If you do it as one operation (a wait with a timeout factor), then you just have to check if the result is "data complete" or "timeout". This may well be in it's own thread, but having a second thread that just acts as a timeout generator seems a bit excessive.

Again, it would be much easier to recommend something if we understand how the application actually works.

--
Mats

Quote:

---

Originally Posted by matsp

Again, it would be much easier to recommend something if we understand how the application actually works.

--
Mats

---

I agree on that one.