Nexys Video DPTI transfer timeout

[robfinch]

Is there a way to increase the DPTI transfer timeout to more than 2 seconds? It's always timing out on my system which is quite slow as it's dumping received bytes to a display device (using software PIO) as it receives them. It can be hundreds of cycles between fifo reads. I tried setting the chunk size down to 32 bytes and that helped but things are still timing out.

[zygot]

7 hours ago, robfinch said:

s there a way to increase the DPTI transfer timeout to more than 2 seconds?

Yikes! Your post is  the first complaint about an interface being too fast that I've come across. By first thought would be that perhaps a UART or other low speed interface might be more appropriate for your application. The timing would be a lot more predictable and the interface is a lot easier to use as well. Trying to crack eggs for your breakfast using a sledge seems like a lot of necessary effort. 

[robfinch]

I would use the uart port except that I want that to connect to a gamepad. The transfer is so slow because of the PIO. An Intel hex downloader is being run and I didn't want to try that in hardware. I found where the transfer timeout could be set using Dmgr. I also shortened the file I was sending, so now the transfer completes. But I noticed that if DmgrDisable() / DmgrClose() is called too soon it truncates the transfer. It seems there is a success returned from DptiIO() before it’s actually finished the transfer and there is still data in the fifo which gets lost when the port is closed. I avoid this by having a message box appear in the transfer app, as long as okay isn’t hit on the message box the port remains open allowing the transfer to complete.

 

[zygot]

@robfinch,

This is just between you and me, so don't spread it around; but I much prefer the older CY68013A Adept interface. I can do transfers in asynchronous mode, which would seem to be good for your application, or synchronous mode for transferring large amounts of data quickly. The device is much more flexible and open to optimization for a particular need. This interface keeps my Genesis and Atlys boards working jobs that would be too  much trouble for the newer ones. I've even spent the time a number of year ago writing useful Adept compatible HDL interfaces that suit a large range of applications. So what I'm getting at is that I do use the Adept interface on the Genesys2 and Nexys Video but only for 'high speed' data transfers. For really high performance data transfers the FMC can support a USB 3.0 interface dev. board.  All this is to say that I don't have a good answer for you. I'm pretty sure that the purpose of the time out is to catch a stalled partial transfer if your HDL isn't terminating a packet properly and you don't want your software ( or the enumerated endpoiint ) to hang up.  There's no rule preventing you from using it to accomplish your needs but it sure is 'clunky'. I rarely use the UART ports on Digilent boards unless they are completely separate from the programming hardware. For a few bucks you can buy a nice TTL cable from Adafruit or a variety of TTL compatible modules from Adafruit or Sparkfun and connect them to 2 spare IO pins for a bullet-proof USB-UART PC connection. With a bit of luck perhaps someone else will have a good solution.

[zygot]

Have you considered buffering the data in a FIFO?

[robfinch]

That is with the data buffered in a (4k) fifo. I suppose a larger fifo might help. I wrote a fifo interface for the pti similar to the dptidemo control but with a WISHBONE bus wrapper so the cpu could access it as a peripheral. If I put the thing in loopback mode it works like a charm. The cpu apparently can't empty the fifo fast enough. I set the transfer chunksize to a small value (16) and timeout large 1 minute. But it still times out. I thought the timeout was supposed to be per chunk transmitted, but it seems to be working like a total timeout.

 

[zygot]

Well the good news is that your CPU is either in programmable logic or connected to it. Since you mention wishbone I assume that it's a soft processor. If you can't get data out of a FIFO quickly enough to support a full USB packet then you don't have a lot of options other than to make a larger FIFO. But 4KB should be plenty large enough for this job unless your software design needs a re-think. You can always DMA bursty data into a large DDR buffer... but eventually your CPU will have to process all of the data the the Adept interface is tossing its way... so my thought is that you're avoiding addressing the real bottleneckfor some reason. Most of the time when I figure that I can work around a thorny and complicated issue by being clever I end up doing exactly what I always knew had to be done but after expending a lot of time and energy proving to myself that I'm not usually as clever as I want to be; and that being lazy or avoiding things I'd rather not deal with never works out.