I too would love full access to the FPGA, but that may be impossible. Here are some ideas that may give us more freedom even with a locked down FPGA.
Quote:
|
Since the FPGA is not user-programmable, any novel ideas or sensors which would need interrupt support are not possible
|
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. If you want to handle the interrupt in C and write something like Kevin's utilities, my guess is you could register your ISR with some sort of Labview run time library that processes and dispatches the interrupts (I don't think these are real interrupts so you can't just
register ISRs with VxWorks). The WPI libraries could make this simple for us.
Quote:
|
By logical extension, as Kevin mentioned, this also means that the FGPA may have limits in the number of same type supported devices.
|
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.
I'm sure there's a more efficient way of doing it than the way I've described, but I was trying to keep it conceptually simple.
[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]
[Edit2]: Each pin that can be configured as an encoder will need to have its own state (count sum). The only thing they might be able to share is the combinational logic, but it takes basically no CL to count an encoder, so there's really no point.[/Edit2]