NI Linux Real-Time Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

NiFpga_WriteFifoU8

Solved!
Go to solution

Hi,

I'm currently implementing a c++ application on a LinuxRT cRIO. I want to exchange frame data with FPGA using uplink/downlink FIFO's. To transmit a frame to FPGA I've planed to use the "NiFpga_WriteFifoU8" API call.

The question is: in case of a timeout, how can I know the amout of data that were placed in the FIFO (to know the amount remaining to send) ? Or maybe my question has no sense because I'll get a timeout only when the FPGA has been stopped or crashed, and so timeout means only a critical failure and not only a busy condition ?

Thanks in advance & best regards

0 Kudos
Message 1 of 7
(4,354 Views)
Solution
Accepted by topic author thumble

A few pieces of clarification:

A note that you can use -1 for a timeout to not timeout.

If you do configure a positive timeout, the Write operation will wait until there is sufficient space in the RTOS's DMA buffer to fit all of the data requested for write. It's an all-or-nothing proposition.

An FPGA application can't "crash". You can configure the FPGA to misbehave, but that's a design problem.

A DMA buffer that fills up (the reason that you'd receive a timeout) would be the result of your FPGA application not reading from the DMA buffer (which frees space as it reads). If, for example, you have a design where you do heavy processing on the data received from the RTOS on the FPGA (it takes many FPGA clockcycles) it may be worthwhile to examine pipelining your design (breaking up the computation process to intermediate steps). This allows you to work through the received data in a more continual fashion.

Basically, if you have a sane FPGA design, you shouldn't see timeouts (but your code should be written to handle if there is a timeout)

0 Kudos
Message 2 of 7
(3,536 Views)

Thx a lot for your quick answer

0 Kudos
Message 3 of 7
(3,536 Views)

I've got a couple more things to add to BradM's answer.

- Timeouts are implemented differently on different targerts. On some targets, including the cRIO-906x family, the mechanism is a tight polling loop. This means that the FifoWrite method will consume 100% of available CPU and depending on the priority of the calling thread, could starve other processes. That's to say, an infinite timeout will wait forever, but be aware of the potential consequnces of that. The cRIO-903x controllers use a different progress checking mechanism so they aren't as impacted by this.

- Given the above point, if you need to take control of the polling rate, you can do a zero element write and check the value of emptyElementsRemaining. See http://zone.ni.com/reference/en-XX/help/372928G-01/capi/functions_fifo_write/ for the WriteFifo API documentation. We generally recommend this approach if your application can't ensure that there will be space in the FIFO.

- In any case, checking emptyElementsRemaining after a timeout may give you some insight it to the issue.

- Depending on the size and rates of your transfers it may be helpful to configure the size of the Host buffer using ConfigureFifo2. See http://zone.ni.com/reference/en-XX/help/372928G-01/capi/functions_fifo_method/ for the API doc.

Thanks,

Sebastian

Message 4 of 7
(3,536 Views)

I found a KB that explains DMA FIFO timeout behaviors. Take a look at http://digital.ni.com/public.nsf/allkb/583DDFF1829F51C1862575AA007AC792 for some more details.

Sebastian

0 Kudos
Message 5 of 7
(3,536 Views)

speleato wrote:

...

- Timeouts are implemented differently on different targerts. On some targets, including the cRIO-906x family, the mechanism is a tight polling loop. This means that the FifoWrite method will consume 100% of available CPU and depending on the priority of the calling thread, could starve other processes. That's to say, an infinite timeout will wait forever, but be aware of the potential consequnces of that. The cRIO-903x controllers use a different progress checking mechanism so they aren't as impacted by this.

...

Good to know. Suppose I just assumed that things would stay the way I knew them as implemented on desktop RIO/FPGA

0 Kudos
Message 6 of 7
(3,536 Views)

Thanks to all, to avoid any surprise I'm going to use a 0 timeout and manage it by myself using OS features. What was important to know is that the write will fail when there is not enough free space to accept the data.

0 Kudos
Message 7 of 7
(3,536 Views)