hi_busy signal


#1

Hi Jake,

is there a way to temporarily suspend the readings from the USB side? I explain better. In my application the PC reads every 5ms from the okBufferedPipeOut some data produced by a DSP. Once in a while, the reading is performed during the writing operation on the DSP side. In this situation, the PC receives only part of the data, and the message is corrupted.

At first, I was thinking to use the hi_busy signal on the controller (a clean solution :)), but I don’t really know anything about the signal and preliminary experiments didn’t work. The basic idea is to tell the USB controller to wait for few microseconds until the writing operation is complete. This should be done without generating further USB traffic from the PC to synchronize the operation. Any suggestion?

Thanks
Fabrizio


#2

Hi All,
The problem raised here is quite interesting :smiley: , i have to face a similar one, so i tell you how i proceed :

  • my design is not a dsp but it continuously ‘poll’ a cmos sensor and it intercepts all commands sent to the sensor (by another FPGA) and all the transfered pixels

My xp application continuously perform a pipeRead on 32K bytes (ReadFromPipeOut in a prioritary thread, data processing in // in the main app thread, both being synchronised) .

On the design side, to make it simple : when a readRequest is detected (ep_read = ‘1’) , it either provides actual if any available data OR provides a “NO DATA” word
=> use of a data Header for this purpose (bit 15 indicates data or no data)

(The actual design is more complicated , but the idea is the same. I also handles the symetric : data produced is buffered in a big (huge) fifo before being read by usb)


#3

Yes, at the moment, the HDL modules do not provide a “throttled pipe” that allows you to regulate the transfer of data. This must be done using another mechanism – such as the one suggested above.

Other options include using wires or triggers to indicate buffer status.


#4

Would it work to actually change the address of the okBufferedPipeOut? In this way the buffer would not respond to the USB controller during the “critical section”. The address would be set back to the normal value by the DSP once done. The protocol that I use for the data transmission is quite robust and it would handle the lack of data.

Fabrizio

PS: By the way… thanks Jerone and Jake!!