Just want to confirm something I can’t find in the docs. Since okPipeOut generates its own request signal (ep_read), my logic has to be able to generate data within 1 clock (@ 48 Mhz TI_CLK) of ep_read going high. I’m using okPipeOut + a DP block ram as a FIFO.
Looking at the C API code for ReadFromPipeOut(), there’s a length parameter. (In python, I assume the length is implicit – i.e. len(buffer) as passed in. Is this right?) What does this length parameter do in terms of the host interface logic? I’m guessing that it holds ep_read high for N clocks of TI_CLK, where N is the length parameter? Is this data being directly DMAed over the USB each TI_CLK?
I assume I need to pass in a variable-length buffer to ReadFromPipeOut() in python if I want to read a partially full FIFO, for example, where the size of the buffer is 16-bits * number of entries in the FIFO. For example, to read a FIFO that has 100 entries filled out of 1000 total:
buf = (2 * 100) * '\0'
ReadFromPipeOut(0xa0, buf)
In my logic for the FIFO, can I just do fifoCount -= 1 each time ep_read is high @posedge(ti_clk)?
I hope you can take a break from helping students with their homework to answer. (Yes, I know that’s you video buffering types!
Thanks,
Nate