I am currenlty trying to use the CYUSB3014 to send data synchronously from USB to GPIO. The application would be a 16-bit parallel digital data generator with a clock.
What I have done so far is to configure a DMA auto channel between UIB(producer) and PIB(consumer) usign GPIF II designer. The state with "DR_DATA" is triggered by "DMA_RDY_TH1" and exits when "!DMA_RDY_TH1". There are 4 DMA buffers and each is 16kB.
My problem is, there is a gap during buffer change. Please see the attached image.
I am thinking two ways to solve this, but need some guidance on implementation. If neither of them is possbile, is there anyway to do it with CYUSB3014? Thanks
Okay, here are two ideas;
(1) implement a circular buffer with two pointers: one for UIB, one for PIB. Since USB is faster that the GPIF, most of the time, the DMA buffer is full and it won't be necessary to switch buffers. So I can use a single large buffers. Therefore, there won't be buffer switching. However, I don't know how to do this on a low level or if this is possible.
(2) implement two sockets with GPIF and switch threads to avoid the delay. Just like reversing the configuration in AN75779 (UVC example). However, GPIF doesn't allow me to switch states when they have "DR_DATA" on different sockets. Maybe there is another way?
The delay you see is the buffer switching delay. It cannot be avoided even with a low level implementation since this is a hardware limitation.
Your best bet is to implement option 2.
You cannot use DMA_RDY_THx in the transition equation and then use a DR_DATA or IN_DATA action for a thread other than 'x' in the end state. This is again a limitation with the internal GPIFII architecture.
This is the reason we use a counter in the state machine of An75779.
You can try to do the same. Setup a counter such that it hits at the buffer boundary and switch to the next state when the counter hits. In the next state, you would drive data from another thread1 instead of thread0. And vice versa.
Of course, this implementation assumes that you always have data available in both threads all the time.
If it is absolutely neccesary that you check for data availability before performing DR_DATA, you would need to implement an intermediary dummy state between the two DR_DATA states for the two threads.
Thank you so much for the reply.
I am now trying to implement option 2 as you suggested (using two counters), but I have problem with GPIF when connecting two linked states with DR_DATA from different thread. Please see the attached image for the error message.
Can you please verify this is another limitation of the GPIF? Or do you think there is another way to achieve the transition other than using the "GPIF II Designer"? Thanks
I think by successfully doing this, I can avoid using another FPGA to regulate the output timing. Thanks again.
I have the same problem. I change the firmware and state machine. But now I couldn't send a large file.
have you solved this issue?