Posted on April 04, 2015 at 18:23Havent looked in here for a while.
Yes, that is a good example code.
Interresting, use stm32 ADC as composite video capture :)
As for the general understanding of the UVC isoc transfer, i have summed up the following: (feel free to correct)
USB UVC Device in isochronous mode:
The Host will read various parameters from the UVC device to prepare the transmission.
Finally, the Host will send a ''SetInterface'' Setup instruction to let the device know that it can start streaming on that specified interface.
That interface has a specific ''wMaxPacketSize'' that is the maximum allowed USB-payload-size per transfer. (for example: 512 Bytes)
The device now starts sending USB-payloads. The size of the payload can be between 0 and wMaxPacketSize.
The Host will know the received payload-size by its receive-byte-counter, so we must not send full payloads all the time ? !
StartUp:
After SetInterface is issued by the Host, the first thing the Device does is to start streaming cycle.
At the next SOF interrupt, it will place a 2-Byte UVC-header only packet in the Endpoint Transmit-Fifo.[2,0] (or even earlier after SetInterface ?)
Or it may even place the first full payload into the TX-Fifo. (We know, that payload-size can be flexible)
All this prior to the first IN-token from the Host.
When the Host issues its first IN token, it will read this first payload.
This first transaction causes an INcomplete interrupt at the device side.
The INcomplete handler on the UVC-Device is now responsible for filling up the Endpoint Transmit-Fifo with new data.
Typically this handler will use wMaxPacketSize amount of data [2-headerbytes + (wMaxPacketSize-2)databytes] during transmission of one videoframe.
It will need to transfer many USB-payloads this way as the videoframe is much bigger than the wMaxPacketSize.
On the last payload transfer it will set Bit1 of the header to indicate EndOfFrame and send the remaining databytes (which maybe less than wMaxPacketSize).
If the next videoframe is already available, it will start sending this one the same way, except it toggles Bit0 of the header to indicate that this is a different videoframe.
(clear EOF bit, toggle Bit0).
What happens if a new videoframe is not yet available, as the videocapture has not finished yet?
The Host will keep sending IN tokens to the device, expecting new data.
If the device does not respond by placing data to the Endpoint-fifo, an IsocIncomplete exception will occur, possibly aborting the transfer.
Should the device send just 2-byte headers in between (what type)? or use dummy data as 0xAA or so?
Or may it just send packets with zero-size?
(if we just send the 2-byte header with no data, we actually tell the host: this payload is for videoframe ''togglebit'', but we have no data.
So Host will add zero bytes to the current videoframe.
we could send as many of those as we wish....?)
