The EP_READY signal is polled by the firmware. Basically, you should assert EP_READY when you have data available for the host/firmware to read. The host/firmware will then read out a full block when it polls next.
You can consider the EP_BLOCKSTROBE as an “acknowledge” to the EP_READY. EP_READY will not be polled again until after the full block has been transferred.
Most of the failure codes are not encountered in practice. They come from deeper within the USB stack and generally reveal an unrecoverable error. Timeout, is one certain exception that may be encountered in practice and during normal operation.
Can you tell me what platform and FrontPanel version you are using?
If you are on Linux and using 3.0.0, please upgrade to 3.0.1. We quickly released an update and some folks may have missed it. The Linux version had a timeout value set too low causing even smallish (30kB) BTPipe transfers to fail.
I am on an Intel Mac (macbook) running version 3.0.1 of the API and version 3.0 of the firmware. I first updated my old c++ app to use the new API, firmware, and FPGA code. All that worked. The big kink seems to be in transitioning to the new BTPipes…
[QUOTE=Opal Kelly Support;1365]
Most of the failure codes are not encountered in practice. They come from deeper within the USB stack and generally reveal an unrecoverable error. Timeout, is one certain exception that may be encountered in practice and during normal operation.[/QUOTE]
We are developing a Fiber optics to USB bridge for our acquisition system and we need to use BTPipes. There remain however a few shadow zones in the documentation related to these BTPipes.
What is the meaning/cause of the timeout error encountered using a BTPipe? If we need to be able to recover from it, since it may be encountered, we need to know what exact event is flagged by this error.
Perhaps related to the previous question : is there a maximum amount of time allowed before a block gets ready to be sent/received on the FPGA side ?
What is the usage of SetBTPipePollingInterval() ? I.E. could you detail : “At the completion of a BTPipeOut transfer, the host polls the hardware to confirm that all of the data has been consumed by the FPGA before returning from the function. The polling interval is set by this method.”
Also, I would find it interesting to implement in the BTPipe IP some method to abort the transfer from the FPGA side. This would be useful in long acquisition tasks where the data is essentially flowing constantly and the transfer length has no real meaning. Transfers could then be programmed for much longer length and efficiency than the available data/space in the FPGA buffer and stopped (at a block boundary) when the FPGA detects a rupture in the flux. A new BT transfer could then be called to flush the last bytes with a smaller block length until no data remains.
A timeout means that a particular amount of time has passed and that the call has not completed. For example, say your timeout was 5 seconds and the call did not complete in 5 seconds. The call would then be forced to return and return the error “timeout”.
Yes, the “timeout”.
This gets into the detail of the USB implementation but basically… Just because the PC has sent the data doesn’t mean that the FPGA has fully received the data. There are buffers in between. It is possible that the FPGA throttled-off reception after the data was sent to the USB device. Since a successful return from WriteToBTPipeIn implies that the data has been fully-consumed by the FPGA, a polling process is invoked to monitor for this event. (NOTE that this applied to BTPipeIn, NOT BTPipeOut as in the documentation at this point. This was a mistake in the documentation and has been fixed for the next release.)