You enable the timer, perform a number of communication tasks (like 100 or so) and then disable the timer. Take the timer value and divide by 100 and you have the average communication time.

Ok.. But how to "Take the timer value" ?

You read the value of the timer. The microsoft help pages on the function will show you how.

Sorry.. I still din't get what u are saying
I apologize for my foolish ~ Can u please say in more detail steps ?

For general C# help you should simply google the subject, there are plenty of dedicated C# tutorial sites on the web:

http://www.c-sharpcorner.com/UploadFile ... Sharp.aspx

/Simon

You could pulse a pin on the PIC each time something is recieved from the PC.
Then scope it to see how long it takes.

Hi all, this is my first post here, thanks for the hospitality.

On the subject, I am also starting a project with C18 (after many others) that requires a sustained throughput of 200 Kb/s.
I believe that the PIC18 can do it on its side,receiving 64B packages data in interrupt and storig it with DMA on a MC SPI RAM.
My concern is the windows side, since the whole thing is "polled" and I guess the latency is unknown.
Is it very difficult to expose a Mass Storage or a serial interface from the PIC USB library in order to use such ones on the windows side?
The alternatice is to use dedicated chips like the FTDI232, but that adds complication and costs. Some ideas?

Whichever way you decide to do it you are going to have the same issue that Windows is not a real-time OS and you can't guarantee the throughput. The answer is always buffering; usually with an interrupt on the PIC handling the real-time data collection and then the USB polling happening as and when the packets go in and out.

SD cards are ok depending on the speed you require. If the data sizes aren't too huge I would recommend you also look at chips like the 23K256 from Microchip. It's a 256K RAM chip with a high speed SPI and is small, cheap and easily daisy-chained.

Exposing a Mass Storage interface via USB is quite easy to do (and Microchip even supply a range of examples in the application libraries) however this means you need FAT support which is very resource hungry on small processors like the 18Fs. Using USB Generic HID to throw packets back and forth is far more efficient (but, of course, requires host-side programming) and provided you have the buffer-space it is quite effective.

/Simon