On interrupts and analog sampling

[adciv]

We're starting to look at some of the more advanced functions in lab view and we have some questions.

What is the sampling rate of the analog inputs?

How many interrupts can we have per analog/digital input?

Are the interrupts triggered off the fpga or the processor?

What is the delay between the time an input changes and the interrupt is exerted?

How many interrupts can we have total?

Are there any other limitations concerning interupts?

The goal of this would be to eliminate polling inputs in the code.

Thank you for any help you can give us.

[Ether]

Originally Posted by adciv

The goal of this would be to eliminate polling inputs in the code.

Why? What is the problem you are trying to solve?

[adciv]

I want to eliminate the processor time used by needles polling of inputs that have not changed. If this operates similarly to the hardware interupts I've used in microprocessors then I should also be able to improve system response without consuming additional resources.

[Mark McLeod]

What is your understanding of how the FPGA works?

The FPGA processes all the robot inputs.
The processor where your code runs just asks the FPGA for the current values.

[Ether]

Originally Posted by adciv

I want to eliminate the processor time used by needles polling of inputs that have not changed.

The only polling that should be going on in your code is in a control loop when your controller needs the feedback. As Mark mentioned in his post, the FPGA receives and processes the inputs independently of the CPU, and makes the results available on-demand from the CPU.

If you are considering running your controller code in an Interrupt Service Routine that is almost always a very bad idea.

[adciv]

My understanding is the fpga acts as a pass through. For all inputs and outputs and it is also how the system watchdog is controlled. The fpga is also where the Gyro analog value is integrated/processed, encoders are counted and possibly a few other things.

There is an explicit labview vi provided in the frc wpi VIs called interupt which is what I am trying to find out about. It pauses the code loop it is in until the condition is met. It appears to also use the fpga based on some of the calls I see when I examine it.

I am interested in using this over polling the sensors inputs on the robot. We have to pool these continuously in order to have some of the automation functions we use. Our poll rates have varied over the years from 100 ms to 20ms. If we could eliminate this in favor of interrupts based on when our sensor inputs change we could reduce our processor utilization.

[Ether]

Originally Posted by adciv

Our poll rates have varied over the years from 100 ms to 20ms. If we could eliminate this in favor of interrupts based on when our sensor inputs change we could reduce our processor utilization.

The amount of CPU it takes to retrieve updated inputs from FPGA every 20ms is miniscule. If you are running out of throughput margin, interrupts will not solve your problem.

[adciv]

Agreed, The processor time to retrieve it at 20ms is minimal. But if I'd like to get better performance, equal to 1ms for instance, along with the requisite processing of those inputs, that is not minimal. As to why I may want 1ms performance? Because I'm interested in the limits of the capabilities of the system.

Now, is it possible to get any of my questions answered at all? I asked this so I could to further my understanding of how the system works, not so I could justify why I'm asking the question in the first place.

[Greg McKaskle]

I marked the direct answers with ***s. My advice is at the bottom.

-------------------------------------
What is the sampling rate of the analog inputs?
*** The number is dependent on the I/O module. It is printed on the case of each module, but may need some explanation. I believe you will find that it is 500kS/s aggregate. It can run slower, can throw away values, and WPILib implements a scan list which can read interleaved channels and doesn't have to read them sequentially. This allows some channels to effectively read higher rates and others lower.

How many interrupts can we have per analog/digital input?
*** Eight total, any mix.

Are the interrupts triggered off the fpga or the processor?
*** The fpga raises the interrupt on the cpu. The cpu executes a low level handler, and for LV, it runs a form of deferred procedure.

What is the delay between the time an input changes and the interrupt is exerted?
*** I don't have numbers for the latency between I/O and the scheduling of your code, but it should be quite small.

How many interrupts can we have total?
*** Eight.

Are there any other limitations concerning interrupts?
*** The limits are the I/O conditions that are programmed into the fpga. With the fpga tools, you could have alternate conditions and you could synthesize more.

The goal of this would be to eliminate polling inputs in the code.
*** Advice
As Ether pointed out, the code to grab a raw analog voltage is quick. The scaling calculations add a bit of overhead, but for most FRC mechanisms it is reasonable to use the simple polling loop to monitor and control your device. The interrupts are available and fair game, but they are a bit more advanced and you shouldn't overuse them.

For any given device that you are trying to control or respond to, I'd first calculate how quickly you need to respond. Use the distance and rate of travel, or whatever your phenomena is to calculate your response time. Can you afford to check once a second, ten times, one hundred times, or do you need to read even faster. As this number gets higher, the overhead of doing it in the CPU gets in the way, but this is dependent on how efficient you are at doing it. The interrupt mechanism essentially moves the poll into the fpga. It adds it to the latching code that moves the value from the bus into the buffer or register, accumulates, calculates a level trigger, etc. This is still polled, but it is now in someone else's loop.

I didn't find an FRC example for interrupts, and the one in Find Examples assumes you have the FPGA tools in order to compile for different cRIOs. So be sure to start with something simple and make sure that your assumptions are correct.

Greg McKaskle

[Greg McKaskle]

Sorry I couldn't get to your post yesterday, I was at the MI state champs. It was far more exciting than reading CD.

I did find just a bit of documentation on FRC interrupts, like this http://first.wpi.edu/Images/CMS/Firs...UsersGuide.pdf page sixteen. It still isn't that in-depth.

Please post additional questions or findings as you get them.

Greg McKaskle

[adciv]

Thank you. We've been adjusting the polling rate for optimization, but sometimes we've had to slow down the system. In some years, we've had a large number of sensors and all the polling and processing starts to push us up higher than we'd prefer.

[tcjinaz]

Originally Posted by Greg McKaskle

Sorry I couldn't get to your post yesterday, I was at the MI state champs. It was far more exciting than reading CD.

I did find just a bit of documentation on FRC interrupts, like this http://first.wpi.edu/Images/CMS/Firs...UsersGuide.pdf page sixteen. It still isn't that in-depth.

Please post additional questions or findings as you get them.

Greg McKaskle

Is the RTL for the FPGA is available? I know it will probably force me into VHDL, but I'll survive.
(just heading for really dangerous

Tim
I love acronyms; this post had a TLA, a FLA, and a nested FLA with an underlying five letter acronym...