Help with max BTPipeIn transfer size

I was using API’s function WriteToBlockPipeIn to transfer a file size of 100+ Mbytes with FrontPanel version 3.1.5. It seemed like this function only allowed a maximum transfer size of ~65MB, and therefore, I had to call this function twice to complete my file transfer. I measured the time between the end of 1st transfer and the start of 2nd transfer to be ~5ms. This transfer delay caused the problem since the hw consumed all the data in the buffer in ~2ms, and the 2nd transfer couldn’t take place early enough to keep up with the process.
Here are my questions:

  1. If I have to make 2 WriteToBlockPipeIn function calls, is there a way to reduce the function call latency? and how?
  2. Does the newer FrontPanel version allow larger size transfer per call? If not, can it be support in the future release?
  3. And what’s your suggestion? workaround?


– Jimmy

Do anyone have his questions’s answer? I also have met these problems.

I have some experience using ReadFromBlockPipeOut() in C++ and managing the ep_read and ep_ready signals in VHDL. Data transfers are 2K 16 bit.
I am using block ram instead of FIFO. I was not aware of any data transfer length limitations. It is important to manage handshaking between host and target as
transfers are controlled and sent in blocks. How are you implementing your design?


We suggest adding buffer space to your HDL. In a PC environment, it should be able to handle far more than a 2ms or 5ms interruption in data as this is a pretty common occurrence.

The limitation for transfer size is in the FrontPanel API documentation.