Timeout behavior

The frontpanel API provides a timeout command but it is not clear to me, what API calls are affected by this setting. The description in the documentation is quite vague!
If a do a call to the ReadFromBlockPipeOut() i’m blocked forever if not data is sent from the FPGA and i never got a timeout.
Is there a way to interrupt a pending ReadFromBlockPipeOut()?

Timeout behavior is not very consistent across platform implementations. We do not recommend reliance on the timeout. It really should only be an error response.

So generally, only start a transfer when you know it will complete.

Thanks for your reply!

But if this is the case i feel that there is something missing in the API with respect to BTPipes.

On one hand you describe that BTPipes can reduce the overhead since you can negotiate on lower level (and therefore improve the throughput).
On the other hand i still need to know when i’m allowed to start a transfer. So i cannot avoid the negotiation on higher layer. In the end i will even be less efficient since there are negotiations on higher and on lower layer!?

To my point of view one could solve this either by providing a timeout for the BlockPipeRead or by allowing further transfers while a thread is waiting on the BlockPipeRead to terminate.

From what i’ve seen both options do not work ?

Thanks for your comments

-Rolf

Both of these things are true – BTPipes can help reduce overhead and you need to know when to start a transfer.

For example, consider a case where you have a transfer rate of 20 MB/s and want to transfer 20 MB. This is well below the transfer rate supported by our implementation. Therefore, if you do not use BTPipes, you would need to perform transfers that are the size of your buffering. To be reliable, you would need a 20 MB buffer and transfer it it all in one go.

With BTPipes, you can start your transfer immediately and use the throttling to adjust the transfer duration. Your buffering can be much smaller. You would request 20 MB and it would take 1 second. When that transfer completes, you would be able to initiate another one immediately with very little latency in between.

BTPipes help a lot for these streaming cases. But you need to know that the entire transfer will complete. You cannot simply initiate a transfer and let the timeout indicate when things have finished.

A timeout is considered an exception and data may be lost.

Hi,

I’m not very convinced with your answer. Unfortunately i live in a world where errors happen! So the scenario that i can transmit 20Mb data without the possibility of interruption is not applicable!
If i would do as you suggest, my error handling would require to manually power off the device and restart. There is no way to continue once the SW is waiting on a BT-Pipe!

Actually i think everything would be available in the lower layers to provide a better interface!

Hello Rolf–

Errors certainly do happen. And if that’s the case, then the lower levels should be considered the wires and triggers. They can be used to negotiate further in the presence of errors. But they will cut into transfer time.

This is all very dependent on application. In many applications, the data is available without error. These applications can take advantage of that condition and get excellent transfer rates around 35MB/s or more.

If smaller transfers must be used with continual error checking, transfer rates will be reduced. In the extreme case, you would only be able to transfer a couple bytes at a time before checking on availability of the next pair. I expect your specific application lies somewhere in between these two conditions.