Windows jitter

[Ether]

Originally Posted by Hugh Meyer

Ether,

Now you are starting to see what I was talking about!

I hope to get your code and test it on a classmate in a FRC driver station. There is no serial port, so I was planning to use an output pin on the cypress board that we use for driver station IO. It may be a few weeks before I get this done.

Can you describe how you are collecting and plotting this data. As I recall, in a previous thread, you said you didn't have a scope? I do have a scope and will see the jitter as a vertical line smeared on the horizontal scale.

-Hugh

Hugh,

Keep in mind that the data I generated was from a small app I wrote in which I made no attempt to optimize the realtime behavior. I don't know what steps were taken in the Driver Station app to make its realtime behavior more stable and accurate.

To collect the data shown in my previous two posts, I wrote a simple 32-bit Windows console app (different from this) which allowed me to run a test and grab the data all on one machine. It basically does this (pseudo-code):

first collect the samples:

samples=10000;

for(i=0,i<=samples,i++){
sleep(20);
// grab RDTSC1 here
}

then write them to a file:

for(i=1,i<=samples,i++){
// write i and (sample[i]-sample[i-1]) to the output file
}

So basically, I am sampling the time at each start of a 20ms periodic task. The difference in start times between consecutive periods is what I plotted.


To plot the data:

- import the data into Excel

- plot the data and locate the "quiescent" value

- go back and multiply each data point by 20/quiescent

- re-plot the data

Then I realized I have an old DOS machine in the basement which could easily be used to make a poor-man's scope of sorts. Old DOS machines are great for data acquisition and other time-critical tasks because DOS is not multitasking, and it lets you work directly with the hardware. The MC146818 realtime clock chip can be programmed to generate interrupts up to 8092Hz. I use this interrupt to increment a 32-bit counter, and that gives me a counter that increments every 123.5 microseconds that I can use for timing measurements. I wrote a small program that basically does this:

while (1) if(CTS_has_changed_state) readCounter;

That will capture the timing of the rising and falling edges of the changes at the CTS pin (pin8 of the RS232 port). No logic is necessary to detect CTS_has_changed_state; it can be read directly from bit0 of the Modem Status Register.

I haven't had a chance to do this yet, but my plan is to make an RS232 cable to connect the DOS machine's COM1 port CTS pin to the RTS pin of my machine-under-test (XP) which is running the RTS toggler I posted here.


Since you want to run a test on the Driver Station on a machine that does not have an RS232 port, there's really nothing in the RTS toggler app that would be of any use to you (all it does is toggle the RTS pin). Is the source code available for the Driver Station? If so, I suppose what you could do is edit and re-compile the Driver Station to toggle the output pin of the Cypress board like you said. Raise the pin at the start of the task and lower it at the end, then either measure the waveform with an oscilloscope or use some other test equipment (like my DOS machine discussed above) to capture the timings of the transitions of the pin.




¹the RDTSC is a screaming fast read-only 64-bit hardware counter that can be latched and read "bare metal" with only 1 assembly instruction (Windows allows you to read it directly from the hardware; no API required). On the XP machine I ran it on, it ticks at about 3GHz. Note: there are some issues with RDTSC on newer machines so YMMV.