Quote:
Originally Posted by billbo911
How does the FPGA derive the "period" value? Is it just the time between rising, or falling, edges of a signal?
|
The FPGA has an oscillator running at 40MHz. This is divided by 40 to produce a 1 microsecond timer for time-stamping events (like the detection of rising and/or falling edges).
Additionally, the 40MHz clock is divided down by 261 to create a 153257 Hz (6.515 microsecond) polling frequency. The FPGA polls all the DIO inputs synchronously at this frequency.
Whether the FPGA counts and timestamps rising edge only, or both rising and falling edges, or both rising and falling edges on both channels, is determined by how the user sets up the counter (or encoder) object.
In encoder 4X mode, I believe FPGA counts both rising and falling edges on both channels, and by default computes the period using the 5 most-recent counts (i.e 4 periods). Then in WPILib, the period returned is divided by 4 to give the actual period between consecutive edges, which is the value returned to the caller.
Quote:
|
Will the duty cycle of the signal influence the "period" value?
|
For a simple 1-channel counter (either a one-per-rev or an encoder with only one channel connected), an object can be created which counts only rising edges.
So for a single piece of tape, the width of the tape doesn't matter, as long as it is wide enough for the sensor (and the FPGA) to detect it. The WPILib default for this type of counter is to use the 2 most recent counts to compute the period. This works well for a one-per-rev sensor, because there's only one rising edge per revolution, so there's no error due to tape placement (since it's always the same edge which is being detected).