Quote:
Originally Posted by Jay Lundy
It's definitely possible to send interrupts from the FPGA to the RTOS, at least in Labview. Presumably the FPGA could be hard-programmed to send every digital input to a different IRQ and if the signal processing on the FPGA doesn't work for you, you can do it in the RTOS. The help file on interrupts makes me worried about the interrupt latency using this method: "The Interrupt VI is a shared resource, so multiple uses of it induce additional delay and jitter due to arbitration," but it may be a possible solution. |
This is more or less what I was thinking, except I have some refinements. First, it's not at all clear in the FPGA documentation (there I go again) if the arbitration issues arise for every call of the Interrupt VI, or only for calls of the Interrupt VI addressing the same IRQ number. Ex: Flagging IRQ16 someplace and IRQ28 somewhere else might not have arbitration issues complicating the latency. Of course, issues of interrupt priority and concurrent interrupts might still affect things. Which also isn't well documented. If you can have multiple interrupts with different flags with no issues, they your idea would work. Else, I think it'd be smartest to just implement an interrupt-on-change feature across the entire range of digital inputs so a single interrupt tripped when any digital input changed state. You could run the inputs or the edge detection outputs through a simple and relatively cheap bitmask to enable and disable interrupts on a particular IO pin, even. It'd still be a little complicated, as you'd probably need to latch the edge detector and digital IO states when you flagged an interrupt, but I think this would be a workable solution for giving us access to interrupts. I still don't want to have to interface with quadrature encoders using interrupts but I imagine our only other option for general purpose high speed IO of digital inputs would be to set up a DAQmx task to constantly sample the inputs at some acceptably high rate, and then process this backlog of data either in our main loop or a parallel loop running at a rate between the sampling rate and the loop rate. The accuracy and dependability of this would of course depend on our digital IO sampling rate, but a higher sampling rate would give us that much more data to process, when the majority of it is largely useless.
Quote:
Originally Posted by Jay Lundy
Just because we can't change the physical logic on the FPGA, doesn't mean we can't change the way it behaves. We can still modify the registers that control the logic (right?).
For example, assume you have a black box that performs the signal processing on one encoder input. Now, stick a mux in front of it and feed every digital input into the mux. Then, use the RTOS to fill an array of registers with the inputs you want processed and one final register with the number of entries in the array. Then just start a counter to iterate through the array and feed that into the select pin on the mux to process each input one-by-one. Oh and you'll probably want a demux on the other side so the encoder count sum goes to the right place.
[Edit]: Come to think of it... this won't work too well, but I think the idea may be feasible. Can anyone fix it?[/Edit]
Anyway, you can do this with every type of sensor. Just have one black box that you share between the inputs. Obviously it takes longer this way, but at 40 MHz the FPGA should have plenty of time to spare. If time is a problem then add more black boxes in parallel.
Does anyone see any problems with this?
|
I was also pondering something like this, but the problem with your second idea is that function blocks on the FPGA represent actual physical silicon. Counting through all the different inputs/etc. in a single cycle loop on the FPGA isn't going to be possible. You could get away with it in a less strictly timed loop, but then you have to worry about jitter and problems if your loop runs over schedule, and FPGA code outside a single cycle loop takes up a good bit more space on the FPGA. If you just said the 2N first inputs on the IO represent N encoders, then I think you could loop through the set of inputs, old states, and count registers for N encoders, processing one encoder per FPGA cycle. This obviously slows down your overall capture rate, but if they get the FPGA running at 20-40MHz as it should, then it shouldn't matter. Then you let the programmer define N to pick how many encoders she wants.
The other solution is to hard code in X encoder counters, and Y GTS counters and Q other devices, spread across the digital input lines as widely as possible, but each dedicated to a particular port, much like the different peripherals on the PIC. Then have various enable/disable lines to select which ones you want to use as GPIO and which to use as peripherals. Maybe you could even have various bits to twiddle on and off to select slightly different functions for the various modules or otherwise modify their operation. You could even have a few registers here and there to further tweak the function of the various peripheral modules. I bet if the NI/WPI guys work hard enough they could come up with the equivalent of, ooohh, three PIC18F2431 chips (only $3.07 per!).
Which is to say that if we wanted a large amount of flexible hardware based IO that we could simply turn on and off with the flick of a switch, a controller based on a local net of microprocessors might have been a better move. The whole point of an FPGA is that you only have to implement what you need and it can be whatever the heck it is you want. So I hope the various people involved in the control system understand our frustration with paying more for a new controller that we don't have yet and will quite likely lock us out of the single most useful feature it has.