Quote:
Originally Posted by Ether
My concern was along the following lines [not properly restoring interrupts] ... then you can't reliably use cli in your application code.
|
That may be a problem, but I couldn't figure out a way to test it. I/O interrupts in WPILib are partly handled by the FPGA. Reading the FPGA clock looks similar to reading a global variable from the FPGA, so if there are bugs with interrupts, it probably affects more than just the clock. Reading the PPC clock is so fast it probably doesn't mess with interrupts--I'm not even sure if it's a system call.
Quote:
|
What the overhead of accessing the FPGA, compared to reading the PPC clock?
|
FPGA clock access takes 50x the PPC clock.
Over 100,000 calls, mean clock access times were:
FPGA = 0.02320 msec
PPC = 0.00048 msec
vxWorks = 0.00172 msec
The max elapsed time between subsequent calls was around 0.002 msec for all of them so my test was getting time sliced and the reported numbers are a bit high.
The FPGA and PPC clocks have similar accuracy. I was wondering if the PPC clock wouldn't accurately track the FPGA clock, but elapsed times over short periods are within the error of my measurement.
We also experimented measuring system performance with an external clock by generating a digital signal and capturing it with a logic analyzer sampling at 8MHz. We captured good data watching our periodic teleop code, but ran out of daylight before digging into system clock stuff.