how to write fireware to implement UVC( USB video class) using 68013a?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hi :

   

       I want to implemented a UVC( USB video class) board using 68013a, so I can use the USBvideo.sys driver by Windows XP; 

   

      According to UVC hardware spec, several changes needed to be done with the device and configure descriptors,

   

My  change is done with a reference of the  below code:

   

         /* Standard High Speed Configuration Descriptor */
 const uint8_t CyFxUSBHSConfigDscr[] =
{
    /* Configuration descriptor */
    0x09,                           /* Descriptor size */
    CY_U3P_USB_CONFIG_DESCR,        /* Configuration descriptor type */
    0xBD,0x00,                      /* Length of this descriptor and all sub descriptors */
    0x02,                           /* Number of interfaces */
    0x01,                           /* Configuration number */
    0x00,                           /* COnfiguration string index */
    0x80,                           /* Config characteristics - bus powered */
    0xFA,                           /* Max power consumption of device (in 2mA unit) : 500mA */

   

    /* Interface association descriptor */
    0x08,                           /* Descriptor size */
    CY_FX_INTF_ASSN_DSCR_TYPE,      /* Interface association descr type */
    0x00,                           /* I/f number of first video control i/f */
    0x02,                           /* Number of video streaming i/f */
    0x0E,                           /* CC_VIDEO : Video i/f class code */
    0x03,                           /* SC_VIDEO_INTERFACE_COLLECTION : subclass code */
    0x00,                           /* Protocol : not used */
    0x00,                           /* String desc index for interface */

   

    /* Standard video control interface descriptor */
    0x09,                           /* Descriptor size */
    CY_U3P_USB_INTRFC_DESCR,        /* Interface descriptor type */
    0x00,                           /* Interface number */
    0x00,                           /* Alternate setting number */
    0x01,                           /* Number of end points */
    0x0E,                           /* CC_VIDEO : Interface class */
    0x01,                           /* CC_VIDEOCONTROL : Interface sub class */
    0x00,                           /* Interface protocol code */
    0x00,                           /* Interface descriptor string index */

   

    /* Class specific VC interface header descriptor */
    0x0D,                           /* Descriptor size */
    0x24,                           /* Class Specific I/f header descriptor type */
    0x01,                           /* Descriptor sub type : VC_HEADER */
    0x00,0x01,                      /* Revision of class spec : 1.0 */
    0x50,0x00,                      /* Total size of class specific descriptors (till output terminal) */
    0x00,0x6C,0xDC,0x02,            /* Clock frequency : 48MHz */
    0x01,                           /* Number of streaming interfaces */
    0x01,                           /* Video streaming I/f 1 belongs to VC i/f */

   

    /* Input (camera) terminal descriptor */
    0x12,                           /* Descriptor size */
    0x24,                           /* Class specific interface desc type */
    0x02,                           /* Input Terminal Descriptor type */
    0x01,                           /* ID of this terminal */
    0x01,0x02,                      /* Camera terminal type */
    0x00,                           /* No association terminal */
    0x00,                           /* String desc index : not used */
    0x00,0x00,                      /* No optical zoom supported */
    0x00,0x00,                      /* No optical zoom supported */
    0x00,0x00,                      /* No optical zoom supported */
    0x03,                           /* Size of controls field for this terminal : 3 bytes */
    0x00,0x00,0x00,                 /* No controls supported */

   

    /* Processing unit descriptor */
    0x0C,                           /* Descriptor size */
    0x24,                           /* Class specific interface desc type */
    0x05,                           /* Processing unit descriptor type */
    0x02,                           /* ID of this terminal */
    0x01,                           /* Source ID : 1 : conencted to input terminal */
    0x00,0x40,                      /* Digital multiplier */
    0x03,                           /* Size of controls field for this terminal : 3 bytes */
    0x00,0x00,0x00,                 /* No controls supported */
    0x00,                           /* String desc index : not used */

   

    /* Extension unit descriptor */
    0x1C,                           /* Descriptor size */
    0x24,                           /* Class specific interface desc type */
    0x06,                           /* Extension unit descriptor type */
    0x03,                           /* ID of this terminal */
    0xFF,0xFF,0xFF,0xFF,            /* 16 byte GUID */
    0xFF,0xFF,0xFF,0xFF,
    0xFF,0xFF,0xFF,0xFF,
    0xFF,0xFF,0xFF,0xFF,
    0x00,                           /* Number of controls in this terminal */
    0x01,                           /* Number of input pins in this terminal */
    0x02,                           /* Source ID : 2 : connected to proc unit */
    0x03,                           /* Size of controls field for this terminal : 3 bytes */
    0x00,0x00,0x00,                 /* No controls supported */
    0x00,                           /* String desc index : not used */

   

    /* Output terminal descriptor */
    0x09,                           /* Descriptor size */
    0x24,                           /* Class specific interface desc type */
    0x03,                           /* Output terminal descriptor type */
    0x04,                           /* ID of this terminal */
    0x01,0x01,                      /* USB Streaming terminal type */
    0x00,                           /* No association terminal */
    0x03,                           /* Source ID : 3 : connected to extn unit */
    0x00,                           /* String desc index : not used */

   

    /* Video control status interrupt endpoint descriptor */
    0x07,                           /* Descriptor size */
    CY_U3P_USB_ENDPNT_DESCR,        /* Endpoint descriptor type */
    CY_FX_EP_CONTROL_STATUS,        /* Endpoint address and description */
    CY_U3P_USB_EP_INTR,             /* Interrupt end point type */
    0x40,0x00,                      /* Max packet size = 64 bytes */
    0x08,                           /* Servicing interval : 8ms */

   

    /* Class specific interrupt endpoint descriptor */
    0x05,                           /* Descriptor size */
    0x25,                           /* Class specific endpoint descriptor type */
    CY_U3P_USB_EP_INTR,             /* End point sub type */
    0x40,0x00,                      /* Max packet size = 64 bytes */

   

    /* Standard video streaming interface descriptor (alternate setting 0) */
    0x09,                           /* Descriptor size */
    CY_U3P_USB_INTRFC_DESCR,        /* Interface descriptor type */
    0x01,                           /* Interface number */
    0x00,                           /* Alternate setting number */
    0x01,                           /* Number of end points : zero bandwidth */
    0x0E,                           /* Interface class : CC_VIDEO */
    0x02,                           /* Interface sub class : CC_VIDEOSTREAMING */
    0x00,                           /* Interface protocol code : undefined */
    0x00,                           /* Interface descriptor string index */

   

    /* Endpoint descriptor for streaming video data */
    0x07,                           /* Descriptor size */
    CY_U3P_USB_ENDPNT_DESCR,        /* Endpoint descriptor type */
    CY_FX_EP_BULK_VIDEO,            /* Endpoint address and description */
    CY_U3P_USB_EP_BULK,             /* Bulk Endpoint */
    0x00, 0x02,                     /* 512 Bytes Maximum Packet Size. */
    0x00,                           /* Servicing interval for data transfers */

   

    /* Class-specific video streaming input header descriptor */
    0x0E,                           /* Descriptor size */
    0x24,                           /* Class-specific VS i/f type */
    0x01,                           /* Descriptotor subtype : input header */
    0x01,                           /* 1 format desciptor follows */
    0x19,0x00,                      /* Total size of class specific VS descr */
    CY_FX_EP_BULK_VIDEO,            /* EP address for BULK video data */
    0x00,                           /* No dynamic format change supported */
    0x04,                           /* Output terminal ID : 4 */
    0x01,                           /* Still image capture method 1 supported */
    0x01,                           /* Hardware trigger supported for still image */
    0x00,                           /* Hardware to initiate still image capture */
    0x01,                           /* Size of controls field : 1 byte */
    0x00,                           /* D2 : Compression quality supported */

   

    /* Class specific VS format descriptor */
    0x0B,                           /* Descriptor size */
    0x24,                           /* Class-specific VS i/f type */
    0x06,                           /* Descriptotor subtype : VS_FORMAT_MJPEG */
    0x01,                           /* Format desciptor index */
    0x01,                           /* 1 Frame desciptor follows */
    0x01,                           /* Uses fixed size samples */
    0x01,                           /* Default frame index is 1 */
    0x00,                           /* Non interlaced stream not reqd. */
    0x00,                           /* Non interlaced stream not reqd. */
    0x00,                           /* Non interlaced stream */
    0x00,                           /* CopyProtect: duplication unrestricted */

   

    /* Class specific VS frame descriptor */
    0x1E,                           /* Descriptor size */
    0x24,                           /* Class-specific VS I/f Type */
    0x07,                           /* Descriptotor subtype : VS_FRAME_MJPEG */
    0x01,                           /* Frame desciptor index */
    0x00,                           /* Still image capture method not supported */
    0xB0,0x00,                      /* Width of the frame : 176 */
    0x90,0x00,                      /* Height of the frame : 144 */
    0x00,0xC0,0x5D,0x00,            /* Min bit rate bits/s */
    0x00,0xC0,0x5D,0x00,            /* Min bit rate bits/s */
    0x00,0x58,0x02,0x00,            /* Maximum video or still frame size in bytes */
    0x2A,0x2C,0x0A,0x00,            /* Default frame interval */
    0x01,                           /* Frame interval type : No of discrete intervals */
    0x2A,0x2C,0x0A,0x00            /* Frame interval 3 */
};
 

   

The results shows that the driver is not correctly setup at WIndows, it shows" USB composite device" in the device manager with yellow "!";

   

 

   

my question is :

   

how to correctly change the configure descriptors and other codes in the fireware so that Windows can recognize the device as UVC ;  Thanks 

0 Likes
1 Solution
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

 Try with the Descriptors present in the attached text file.

View solution in original post

0 Likes
29 Replies
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

 Try with the Descriptors present in the attached text file.

0 Likes
Anonymous
Not applicable

Thanks, the descriptor works and Windows XP can find the device as an UVC now.

   

there is others problems:

   

(1) if  the size of compiled fireware exceeds 13K , when download to 68013 using  cyconsole,  the fireware does not work,  so  I have to comment out code in order to keep the compiled code below 13K, but I don't why this happened?

   

(2) When using the UVC device by directshow Graphedit or AMCAP.exe, it shows a dialog say" this graph cannot preview";

   

I  implemented Get_CUR  request by return 26 bytes  referred to the following:

   

const uint8_t glProbeCtrl[CY_FX_UVC_MAX_PROBE_SETTING] = {
    0x00,0x00,                       /* bmHint : No fixed parameters */
    0x01,                            /* Use 1st Video format index */
    0x01,                            /* Use 1st Video frame index */
    0x2A,0x2C,0x0A,0x00,             /* Desired frame interval in 100ns */
    0x00,0x00,                       /* Key frame rate in key frame/video frame units */
    0x00,0x00,                       /* PFrame rate in PFrame / key frame units */
    0x00,0x00,                       /* Compression quality control */
    0x00,0x00,                       /* Window size for average bit rate */
    0x00,0x00,                       /* Internal video streaming i/f latency in ms */
    0x00,0x90,0x01,0x00,             /* Max video frame size in bytes (100KB) */
    0x00,0x10,0x00,0x00              /* No. of bytes device can rx in single payload */
};

   

and Set_CUR request with only return true;

   

So is there any problem with these implementation of  Get_CUR  and Set_CUR? and Is there other UVC requests that should be implemented ?

   

Thanks.

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Hi :

   

     I use the busbound to capture the usb request, it shows in the below picture.when Get_Cur request , the fireware returns back 26byte information, but when in SET_CUR request, it is an USTS error, my fireware is as below( changed the SC_CLEAR_FEATURE in fw.c) :

   

      case SC_CLEAR_FEATURE:                  // *** Clear Feature 0x01
         if(DR_ClearFeature())
            switch(SETUPDAT[0])
            {
               case 0x21:      ///////SET_CUR request
                     UVC_SetCur();
                     break;
                 
            }

   


////read the 26 byte data into glCommitCtrl

   

BOOL UVC_SetCur(void)
{
   WORD i;
   //EP0CS |= bmHSNAK;// Acknowledge handshake phase of device request
   for (i=0;i<26;i++)
     glCommitCtrl=EP0BUF;
  
   return(TRUE);
}

   

 

   

so is the fireware not right or other problems? thanks

0 Likes
Anonymous
Not applicable

 Hi,

   

 

   

With respect to the issue related with firmware exceeding 13k size: Please check out the settings made in the Keil compiler (in Project -> Options for Target1 -> BL51 Locate tab/ Target tab).    

   

 

   

Regards,

   

Gayathri

0 Likes
Anonymous
Not applicable

 Hi,

   

 

   

USTS error (0xC0010000) stands for USB_STATUS_Cancelled error. The USB stack reports this error whenever it completed a transfer because of an AbortPipe request from the client driver. Abort pipe request is given following some error in the transfer. We need to know what is the error that occured. Is it possible for  you to capture the traffic using analyzer like CATC/ Ellysis, which will provide more detailing?

   

For the question: what other UVC requests need to be implemented. UVC spec clearly mentions what are the mandatory requests needed depending on the specific controls. Please refer UVC spec.

   

 

   

Regards,

   

Gayathri

0 Likes
Anonymous
Not applicable

Thanks for your quick response!

   

(1) The SET_CUR request code is 0x01, the same as SC_CLEAR_feature, So I changed the SC_CLEAR_feature code. So is there anything that should be done after moving the data ,such as change the endpiont status , set stall bit ,and etc in order to make the SET_CUR request work?  

   

    Does the analyser need some hardware? currently we do not have that things.

   

(2) As to the 13k code size, so Is that what i need to do is change the code size in the settings? 

0 Likes
Anonymous
Not applicable

 Hi,

   

 

   

I don't see anything else that needs to be done specially for SET_CUR request. It is to be serivced like any other request, with IN data transfer phase. I believe you are doing the EP0CS |= bmHSNAK; statement common to all the requests. Can you please check and see whether all the 8 bytes of setup data that you have received in EP0BUF is intact? What I read in some of the specs is that the Xact error (which ay cause Abort pipe) might be due to CRC/ PId error etc. I am exactly not sure how we can find out the roor cause, if you do not have better analyzers. 

   

Can you just try replacing the USB cable with a certfied one, since I have heard of such issues due to improper cables as well. Just wanted to be sure.

   

In FX2LP, code size can go upto 16k. since yours is only 13k, I think the Keil settings should fix the issue related to firmware size.

   

I think, you are modifying the vend_ax firmware file to incorporate the SET_CUR and other UVC related requests. If so, can you please try any other vendor command with IN data transfer phase, if that is working? If so, can you please compare the difference between the way that and SET_CUR are implemented?

   

Regards,

   

Gayathri

0 Likes
Anonymous
Not applicable

Hi:

   

(1) As to the SET_CUR USTS C0000011 error, I put

   

        EP0BCH = 0;
        EP0BCL = 0;
        while(EP0CS & bmEPBUSY);

   

        before moving data , and it is OK;  but I can't explain why?

   

       

   

 

   

(2) Another question, I put  EP6 as an IN bulk endpoint ,  and after SET_CUR and GET_CUR , an XACT error happened as your said before

   

Device  Length    Phase  Data                                                Description       Cmd.Phase.Ofs(rep)
------  --------  -----  --------------------------------------------------  ----------------  ------------------
  25           0  IN                                                                                                          9.1.0(6233) 
  25.6            USTS   c0000011                                                  xact error            6242.1.0       
  25.6            RESET                                                                                                  6243.1.0       
  25           0  IN                                                                                                           6244.1.0(45K)  
  25.6            USTS   c0000011                                                   xact error           51685.1.0       
  25.6            RESET                                                                                                  51686.1.0   

   

no data is send to PC, it seems that it try many times before the error happened, the EP6 setting is as following:

   

    EP6CFG = 0xE0;                //valid,IN,bullk,double   

   

    SYNCDELAY; 

   

   EP6AUTOINLENH = 02;  // EP6 auto in length: 512 //512:02  64:00
   SYNCDELAY;
   EP6AUTOINLENL = 00;        //512:00   64:64
   SYNCDELAY;

   

   EP6FIFOCFG = 0x09;

   

   SYNCDELAY;

   

 

   

 

   

If I put EP6 as ISO IN with the following setting:

   

    EP6CFG = 0xD0;                //valid,IN,ISO,double   

   

  25           0  ISOC                                                                                                9.1.0(2403) 
  25.1            USTS   c0000011                                            xact error            2412.1.0       
  25           0  ISOC                                                                                               2413.1.0(749)

   

   would you please give me some advice on this problem? thanks

0 Likes
Anonymous
Not applicable
0 Likes
Anonymous
Not applicable

Thanks, it is for the ISO transfer , and I tried bulk transfer mode , the XACT error is still there.

   

Is there something that maybe not right is the configuration of EP6 in the fireware?   Hope to get your advice. Thanks.

0 Likes
Anonymous
Not applicable

May I ask if you successfully managed to get UVC implemented?

   

 

   

Also interested in developing a UVC camera but was mindful of another Cypress comment that I found a while ago:-

   

 

   

"Cypress recommends using a custom driver to implement video products using the EZ-USB FX2LP family ofdevices. Certain
requirements of the Video device class specification make it difficult to support the class specification using the FX2LP product. In particular, manual insertion of the payload header into the video data stream is difficult to achieve. Related Categories: USB High-Speed Peripherals"

   

 

   

Be interested to know if it is possible.

0 Likes
Anonymous
Not applicable

Hi Logicland,

   

 

   

If you use FX2LP to insert the payload headers, it will introduce huge amount of delay, since 8051 comes in the data path. It won't be possible. But you can achieve the same if you think of FPGA on the data path, which will insert the payload headers and pass the data to FX2LP. If you donot want to think of FPGA, you may think of some custom filter driver sitting on top of UVC driver, which will insert the payload headers.

   

 

   

Regards,

   

Gayathri

0 Likes
Anonymous
Not applicable

Hi:

   

Yes, I had an FPGA in the data chain. but I had been stopped by the Xact error now.

   

AS to payload header,  I think it is possible to add it by FPGA, but I do not try .

0 Likes
Anonymous
Not applicable

XACT_ERROR means there is a transaction error. FX2LP handles the data toggle PID by default so I don't see a reason for transaction error getting triggered. Have you had a chance to hook up a CATC analyzer to see what is happening on the bus?

   

Regards,

   

Anand

0 Likes
Anonymous
Not applicable

Hi :

   

The previous Xact error is because hardware error, the crysital does not work well. thanks very much.

   

and I am trying to add UVC header into the data stream by fpga, and I have two questions :

   

(1) the first is  the problem about ISO transfer 

   

I write a FPGA program, by writing known test data into 68013 , the mode is slave fifo ,FPGA as master;

   

when 68013  EP6 is configured as bulk in , auto in, autoin length is 512 or 1024,  and cyconsole can get the right test data;

   

but when EP6 is configures as ISO in , auto in ,1024 autoin length,  by cyconsole , when the length is 1024 or 2048, 4096, the transfer failed.  only when in 8192, I can get the test data.

   

SO would you please tell the difference between  ISO mode  and bulk mode ,and how to  configure ISO mode ,is there anything need to be configured specially such as SOF interrupt?

   

(2) The second question is about the Pktend pin in slavefifo mode 

   

The 12bytes UVC header needed to be added into the video streams, so I split the frame  data into several packet, each packet size is 1024, and the first 12 bytes are header.  the last packet size in a frame is smaller than 1024, so I use the Pktend signal to tell 68013 to send the last packet , and i found in the TRM that it should check fifo fullflag before pktend signal is placed , is my understanding right? 

   

is there any difference between UVC payload size and endpoint autoin packet size ?   

0 Likes
Anonymous
Not applicable

 Hi,

   

 

   

The limitation that you saw with CyConsole is due to the following reason:

   

   

For ISOC transfers on a device operating at High speed, the following constraints apply to this command:

   

  1) The endpoint transfer size must be a multiple of the endpoint's MaxPacketSize * 8. 

   

   2)  The buffer length parameter (bufLen in the below examples) must also be a multiple of the endpoint's MaxPacketSize *8. 

   

   

The above 2 constraints apply to all ISOC transfers, regardless of speed, if using a version of CyUSB.sys older than 1.7.0.0.

   

So, only when you are using CyUSB.sys, this will apply. Thus, for ISOC transfers, the buffer length and the endpoint's transfers size must be a multiple of 8 times the endpoint's MaxPktSize.

   

 

   

Now, about PKTEND pin:

   

External master (in your case FPGA) checks for Full flag as to understand it has space for moving data from external master, i.e. ti ensure the biffer is available before sending the data. Once the external master sends the short packet, external master should pulse the PKTEND pin, as to commit the packet to the host domain.

   

 

   

Regards,

   

Gayathri 

0 Likes
Anonymous
Not applicable

thanks!

   

As the PKTend signal, do I need to check the endpoint FIFO_full flag before I make a Pktend pulse.

   

another question,    before a new frame start,  what can I do in order to tell 68013 to send all previous frame data in the endpoint buffer datas to host . currently I pulsed the PKTend signal, but it seems not work. 

0 Likes
Anonymous
Not applicable

 Hi,

   

 

   

1) No need to check for Fifo full flag before asserting PKTEND signal. But ypu need to monitor the full flag status from the external master (FPGA) before sending the data.

   

2) I did not understand your concern about sending the previous frame data to host. You may achieve the data transfer as follows:

   

Whenever a Microframe starts,(which will be intiated by SOF interrupt inside FX2LP firmware), use some GPIO to intimate this to the FPGA. Whnever microframe starts, send the following:

   

- first packet = 12Bytes + video frame data (1012 bytes)  = total 1024 bytes

   

- second packet (1024bytes of video frame data)

   

- third packet = (1024bytes of video frame data)

   

Whenever the video frame is ending or due tp some reason, when FPGA is sending a packet shorter than 1024, you can pulse PKTEND. In all other cases, packet will get AUTO committed as FX2LP will be in Slave AUTO mode. As soon as the FX2LP buffer fills with 1024 bytes of data, it gets auto committed to the host. The host has to keep reading the IN data in time.

   

You can use IN endpoint as quad buffered, if you do not want EP for any other purpose.

   

 

   

Regards,

   

Gayathri

Anonymous
Not applicable

Small typo in previous post..

   

2)

   

......Whenever a Microframe starts,(which will be "INDICATED" by SOF interrupt inside FX2LP firmware), use some GPIO to intimate this to the FPGA.

   

Also, the three packets in a microframe, that I was talking about in the previous post, is with the assumption that the isc transfers is high speed high bandwidth transfers, with 3 packets every microframe. 

   

Regards,

   

Gayathri

0 Likes
Anonymous
Not applicable

 Thanks.

   

an Usts C0000b00 , ISO req failed happened when using busing busbound, what does this mean, the polling interval is 125us , 3frames;  

0 Likes
Anonymous
Not applicable

 Hi   Gayathri,

   

      

   

         Thanks for your response. and i have some further questions here , hope to get your advice.

   

       The UVC defines the video data should be transferred with 12 byte header and then followed by video data per ISO transfer, what i have done is to make sure this happened 

   

      The input video frame is 720x480 16bits with an clk of 27Mhz.  so  one line contains 1440 bytes data and the line time is about 62.9us.  so in 125 us ISO interrupt time ,there are two lines.   So I think in this 125us period , the 1440*2 bytes data should be transferred to PC, and I configured EP2ISOINPKTS=3, and auto in length is 1024;

   

       I  used an GPIO to to tell  FPGA  every SOF interrupt happened. then FPGA write data into slavefifo with 12 bytes header first , followed by video data , I used the Pktend before the next SOF interrupt  to commit the video data that is shorter than 1024bytes. and repeat it again next SOF happen.

   

       but i  did not get the right data  at the PC side , by using busbound, the first 12data is not the header I inserted, but video data instead.

   

      I thougt it again,  After the SOF interrupt told to FPGA by GPIO , FPGA start to write data into slavefifo, but these data is not transferred after 1024 bytes in filled, transfer 1024 bytes needs about 30us ;   so there is only 125-30=95us left for data transfer, maybe the time is not enough to transfer 3 packets in 1024 bytes length. but I do not know how to change it.

   

     I configured EP2 as 1024X4 buffered, and ISO 3x1024 per micro frame.

   

      Thanks in advance.

   

 

   

        

   

       

0 Likes
Anonymous
Not applicable

 Hi,

   

 

   

I did not get why the 12bytes header was not being transmitted over USB if FPGA is sending that before the first 1k byte packet. For FX2LP it is just data whether it be 12 byte header/video data. Please check the implementation in FPGA and also hook up a bus analyzer to view the bus traffic between FPGA and FX2LP.

   

 

   

Also, what you meant by "After the SOF interrupt told to FPGA by GPIO , FPGA start to write data into slavefifo, but these data is not transferred after 1024 bytes in filled". If you set AUTOINLEN of the endpoint as 1024, with EP in Auto mode, it should Auto commit after every 1k bytes. 

   

 

   

Regards,

   

Gayathri

0 Likes
Anonymous
Not applicable

             The data process I think is as following:

   

            when SOF interrupt happened( suppose  it is at 0us),   FPGA start to write data into slavefifo (which is 1k*4 buffered and with an autoin length of 1024) , Suppose the slavefifo is empty when the SOF interrupt happened,  and I think the IN transfer started after FPGA write 1024 bytes into slavefifo(and in my system , with a data clk of 27Mhz,  it takes about 30us time for FPGA to write these 1024 bytes data) .  In other word , at time 30us ,  FPGA write done 1024 bytes,  and USB in transfer begins.   so in the first 30us, USB transfer did not happen.

   

           The next SOF interrupt is at 125us, and  ISO packet is 3,  so I think 3 ISO packets should be transferred from time 30us to 125us,   and  the time is not enough. but I really do not familiar with  how the usb ISO transfer did . would you please give some explanation on ISO transfer of 68013;   

   

           As to the FPGA side ,  everytime SOF starts ,  12 bytes header is wrote first by FPGA , and then video data is wrote.

   

          what I want to implement is UVC spec tells   SOF packet with following DATA2,  DATA 1, DATA 0;   Is there other possible  ways to implement this by 68013 ? I though about using autoin=0,  FPGA write data before SOF interrupt so when SOF interrupt happened, data in ready in the endpoint buffer and by setting Fireware( but I do not know how) , transfer immediately  happen.   In this way the synchronizaiton control seems not easy. 

0 Likes
Anonymous
Not applicable

Hi  Gayathri,

   

       The UVC spec defines that every ISO transfer should be start with 12 bytes header  and then video data following.

   

so what I want to implement is what the UVC spec defined.

   

        currently I use two ways to implement this:

   

       (1) I  insert 12bytes header into the video stream to form a packet size of 1024 bytes.

   

            the stream after inserting is like this:

   

           12 bytes header+ 1012 video data;

   

           12 bytes header+ 1012 video data;

   

          the length of the last packet in the frame may be less than 1012, then I use PKtend to send the last packet;

   

        and the slavefifo is configured as 1K*4 bufferd , and autoin;

   

        the busbound results shows that in most case, an ISO transfer is start with 12 bytes header I inserted, but sometime not . but Idid not find the root cause

   

    (2)  I referred to the advice you give.   In the fireware , I set an GPIO very SOF interrupt,   when FPGA get that  the status of the GPIO changed , it begin to write data into slavefifo with 12 header first , then video data,, bofore the next SOF interrupt,  I use the PKTEND signal to tell to Fireware to send all the previous data.

   

            and the slavefifo is configured as 1K*4 bufferd , and autoin;  ISO packet length is 3;

   

           the busbound results shows in most case , the ISO transfer is not begin with the header I inserted, and I thougt the reason  in the previous text;

   

         would you please help anylise the root cause of the two method?

   

          or  Is there other possible  ways to add UVC header by FPGA  so  68013  could send the data as UVC spec said?

   

         Thanks

   

        BR
       xlhu3

0 Likes
Anonymous
Not applicable

 Hi,

   

 

   

ISO transfer in FX2LP is just like any other ISO transfer. Also, one more thing even though first 1k packet of data is available for transfer only after 30us in a microframe, the 1k packet transfer will happen at USB 2.0 speed across the USB bus and not at 27mhz. So, after 90us even your third packet would be available and still you have (125-90)us left for transferring the third packet in the microframe. Theoretically it seems possible, just observe the USB traffic and see how it takes place in real. USB traffic analyzer like CATC/Ellysis can be a good help in this regard, than Bus hound.

   

Now, if you are considering (AUTOIN = 0) manual mode for implementing UVC, I don't think it would be feasible to implement ISO transfers, as 8051 in the data path will make it tremendously slow. Such an implementation will not be possible.

   

 

   

Regards,

   

Gayathri

0 Likes
Anonymous
Not applicable

 Hello all,

   

So what is the final solution?

   

What we've implemented is that the FPGA has a task to add the header every 1024Bytes. Then add EOF header at last packet.

   

The FX2LP is configured for Slave FIFO, AUTOIN =1, EP2AUTOINLENH:L=1024, ISO EP2 Buffer 4 x 1024, EP2ISOINPKTS = 0x82 (2 transactions / microframe).

   

It works well but not very reliable.

   

I want to add the header from 8051 but I don't know how 😛

   

My question:

   

How can do this process:

   

   (1) - Add header in 12 first bytes. EP2FIFOBUF[0]=0x0C; EP2FIFOBUF[1]=0x02; EP2FIFOBUF[3]=0x80......EP2FIFOBUF[11]=0

   

   (2)- Let FPGA append video data

   

My question >

   

When I add manually the header (12bytes), how can I ensure that the FPGA will not overwrite my header previously added? in over hand the EP2FIFOBCH:L is auto-incremented after action (1) ?

   

Thabk you.

0 Likes
Anonymous
Not applicable

 Hi,

   

 

   

In order to insert header from FX2LP, you will have to configure FX2LP in manual mode. However, adding header using FX2LP will be time consuming, since you have to shift the data in the endpoint to make room for 12 bytes header. What is your expected bandwidth? 

   

How are you implementing the same using FPGA now? Are you using Isoc transfers? If so, are you notifying the SOF information to FPGA using GPIO or something?

   

 

   

Regards,

   

Gayathri

0 Likes
Anonymous
Not applicable

  Hi,

   

 

   

In order to insert header from FX2LP, you will have to configure FX2LP in manual mode. However, adding header using FX2LP will be time consuming, since you have to shift the data in the endpoint to make room for 12 bytes header.

   

>>What is your expected bandwidth? 

   

I use iso endpoint. the maw bandwidth is 24Mbytes/s. it's enough for me.

   

 

   

>>How are you implementing the same using FPGA now?  Are you using Isoc transfers?

   

EP2 config: ISO, maxPacketSize: 2x1024 (2 transactions/µframe)

   

FIFO EP2 config: 4x1024 buffer, AUTOIN=1, WORDWIDE=1

   

 

   

USB transaction: [SOF] [FPGA data: 2 bytes (header payload) + 2046 bytes (data payload)] - [SOF] [FPGA data: 2 bytes (header payload) + 2046 bytes (data payload)] -...............

   

 

   

So the header payload is inserted by FPGA every 1024 words (write strobe) according to EP maxPacketSize.

   

I use only 2 byte of header payload.

   

 

   

>>If so, are you notifying the SOF information to FPGA using GPIO or something?

   

No, because its already implement in FPGA

   

 

   

 

   

But now, I want to add header from FX2LP CPU using SlaveFIFO manual mode:

   

 

   

How do you thin about this:

   


void TD_Poll(void) // Called repeatedly while the device is idle
{
........

if (MAKE_WORD (EP2FIFOBCH, EP2FIFOBCL) == 0)//Wait until endpoint is empty
{ //Add header payload
EP2FIFOBUF[0] = 0x02;
EP2FIFOBUF[1] = 0x80;
}
else if (MAKE_WORD (EP2FIFOBCH, EP2FIFOBCL) == 1024)//Wait until current buffer is full
{ //Committing a buffer via INPKTEND
INPKTEND = 0x02;
}
....
}

0 Likes
Anonymous
Not applicable

 Hi,

   

 

   

If you are using Slave FIFO manual mode, then the 8051 CPU would need to keep checking for data in TD_Poll() and then add/modify few bytes and then commit the buffer. All this would cause some processing delay, and as a result you might not be able to achieve the 24Mbytes/sec max throughput. If your throughput requirement is lesser than this, then it might be possible, but it would need to be tested anyway.

   

 

   

Regards

   

Shashank

0 Likes