USB superspeed peripherals Forum Discussions
text.format{('custom.tabs.no.results')}
It all started with first LED Blinky for my FX3 explorer kit. The boot_fw was more elegant and readable than the recommended CyFx3 lib based Blinky and that was how the association started. Then went on to use the gpif example and was thrilled to hit near 400MB/s.
The time had come to build our firmware. Whether to take the bloated CyFx3 lib or the light weight boot_fw? The official recommendation was CyFx3 as it is multi threaded and has more features. As a hardware engineer, I was really sceptic about multi-thread. And it was also funny. A single core processor benefitting from a multithread capable OS!!
Went with boot_fw and built feature upon feature. Some key takeaways are 8 bit GPIF for FPGA configuration (wow never seen FPGA configured so fast) and 32bit GPIF for application streaming near 400MB/s in master mode with two GPIF threads and just a single tick gap between them. On top of it GPIF Ingress and Egress over control endpoint. Then some RS232 communications.
boot_fw never left me down during development. There were some missing functions. But so what. You could do a direct register access. Also, never faced any reliability issues.
So why is the boot_fw not that recommended. Really don't know.
But I can vouch that better performing systems with lower code size and more readable code can be built with boot_fw.
May be some applications have a lengthy call, or they have to wait on a flag for too long. But such things can be easily from handled from the main loop, without going for a bloated OS.
Finally, need more recommendation for boot_fw and definitely more examples.
Ravi
Show Less
Could anyone point me to an example of how to define more than 31 controls on an extension unit descriptor?
I believe a second extension unit is required for that.
I tried adding it in the following way, but it did not work.
/* Processing Unit Descriptor */
0x0D, /* Descriptor size */
CX3_CS_INTRFC_DESCR, /* Class specific interface desc type */
0x05, /* Processing Unit Descriptor type: VC_PROCESSING_UNIT*/
0x02, /* ID of this unit */
0x01, /* Source ID: 1: Connected to input terminal */
0x00, 0x40, /* Digital multiplier */
0x03, /* Size of controls field for this terminal: 3 bytes */
/* A bit set to 1 indicates that the mentioned */
/* Control is supported for the video stream. */
0b0111'1111, /* D0: Brightness
* D1: Contrast
* D2: Hue
* D3: Saturation
* D4: Sharpness
* D5: Gamma
* D6: White Balance Temperature
* D7: White Balance Component */
0b0001'0011, /* D8: Backlight Compensation
* D9: Gain
* D10: Power Line Frequency
* D11: Hue, Auto
* D12: White Balance Temperature, Auto
* D13: White Balance Component, Auto
* D14: Digital Multiplier
* D15: Digital Multiplier Limit */
0b0000'0000, /* D16: Analog Video Standard
* D17: Analog Video Lock Status
* D18..(n*8-1): Reserved. Set to zero */
0x00, /* String desc index: Not used */
0x00, /* Analog Video Standards Supported: None */
/* Extension Unit Descriptor */
//0x1C, /* Descriptor size */
0x1D, /* Descriptor size (4 control bytes) */
CX3_CS_INTRFC_DESCR, /* Class specific interface desc type */
0x06, /* Extension Unit Descriptor type */
0x03, /* ID of this terminal */
0x0C, 0x89, 0xB6, 0xAC, /* GUID specific to AN75779 firmware. Obtained from Visual studio */
0xB3, 0xA3, 0x60, 0x40, /* static const GUID <<name>> = */
0x8B, 0x9A, 0xDF, 0x34, /* { 0xacb6890c, 0xa3b3, 0x4060,{0x8b, 0x9a, 0xdf, 0x34, 0xee, 0xf3, 0x9a, 0x2e} };*/
0xEE, 0xF3, 0x9A, 0x2E,
//0x01, /* Number of controls in this terminal */
//0x1F, /* Number of controls in this terminal */ 1F = 31
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 */
0x04, /* Size of controls field for this terminal : 4 bytes */
0b1111'1111, /* Controls supported */
0b1111'1111, /* Controls supported */
0b1111'1111, /* Controls supported */
0b0111'1111, /* Controls supported */
0x00, /* String descriptor index : Not used */
#if true
/* 2nd Extension Unit Descriptor */
0x1C, /* Descriptor size 28 bytes*/
CX3_CS_INTRFC_DESCR, /* Class specific interface desc type */
0x06, /* Extension Unit Descriptor type */
0x04, /* ID of this terminal */
0xAF, 0x80, 0x74, 0x32, /* GUID specific to AN75779 firmware. Obtained from Visual studio */
0x25, 0x17, 0x49, 0x27, /* static const GUID <<name>> = */
0x9E, 0x71, 0xAB, 0x4D, /* { 0xacb6890c, 0xa3b3, 0x4060,{0x8b, 0x9a, 0xdf, 0x34, 0xee, 0xf3, 0x9a, 0x2e} };*/
0xD9, 0x82, 0x91, 0x95,
0x18, /* Number of controls in this terminal */
0x01, /* Number of input pins in this terminal */
0x03, /* Source ID : 3 : Connected to Ext. Unit */
0x03, /* Size of controls field for this terminal : 3 bytes */
0b1111'1111, /* Controls supported */
0b1111'1111, /* Controls supported */
0b1111'1111, /* Controls supported */
0x00, /* String descriptor index : Not used */
#endif
/* Output Terminal Descriptor */
0x09, /* Descriptor size */
CX3_CS_INTRFC_DESCR, /* Class specific interface desc type */
0x03, /* Output Terminal Descriptor type */
0x05, /* ID of this terminal */
0x01, 0x01, /* USB Streaming terminal type */
0x00, /* No association terminal */
0x04, /* Source ID : 3 : Connected to Extn Unit */
0x00, /* String desc index : Not used */
Show Less
Hello, I am using cyusb3014 chip, now I want to test the usb read and write speed through soft, but the speed I got has not been ideal, limited to 30MB/s, the following is my test logic, I want to know if I have a better way to send data, thank you.
I call the usb_write API multiple times, timing before and after the call.
Show Less
Hello, I am using the following method to test the usb 3.0 read and write rate of cyusb3014, I first verify that usb is successfully enumerated in the way of 3.0, I have tried the data transmission of synchronous and asynchronous methods, but the transmission rate has been limited to 30MB per second, I would like to ask if I have a better test method or because of other reasons, thank you
Show Less
I am trying to implement a variable USB configuration descriptors for my FX3 application to allow different features to be included under different conditions. To do this, I am creating a uint8_t pointer and using malloc to allocate the correct amount of memory and then use memcpy to fill in the required data. However, when I go to compile my program I am getting an error:
C:\Program Files (x86)\Cypress\EZ-USB FX3 SDK\1.3\ARM GCC\/arm-none-eabi/lib\libc.a(lib_a-sbrkr.o): In function `_sbrk_r':
sbrkr.c:(.text+0x18): undefined reference to `_sbrk'
collect2.exe: error: ld returned 1 exit status
cs-make: *** [USBVideoClassBulk.elf] Error 1
It seems that there is a missing define that malloc requires and I am unsure how to provide it. Looking at this forum post, it seems like adding cyfxcppsyscall.cpp would fix it however I then get errors where `extern char __heap_start`and `extern char __heap_end` are missing.
How do I solve this _sbrk error? Is there a better way to approach variable sized USB descriptors? Using a fixed size array I can create a correct descriptor but am getting error code 10 in device manager.
Show Less我这边分别取了两台电脑,三个批次的电路板,发现如下现象:
1> 编号1 的PC,与最新批次的电路板通过usb3.0接口连接,其上传速度很慢,都在几十k的速率
2> 编号1的PC,与最新批次的电路板通过usb3.1接口连接,工作正常
3>编号1的PC,与前两个批次的电路板通过usb3.0接口连接,工作正常
4>编号2的PC,USB3.0/USB3.1与三个批次均正常工作。
根据上述现象,目前不能找到合适的排查方法去锁定问题,电脑主板为 华硕 primeZ590-PLUS WIFI
Show LessI am creating a firmware for a UVC and UAC composite device but am encountering an error when trying to stream UVC data. In my Wireshark captures there is a URB_FUNCTION_ABORT_PIPE packet before the actual data comes through the device. This appears to be related to a CYU3P_USBEP_SS_SEQERR_EVT error and CLEAR_FEATURE packet is being sent however I am having difficulty determining why my code isn't handling it properly. I am using an endpoint callback to stall the USB endpoint (CyU3PUsbStall (CY_FX_EP_VID_BULK, CyTrue, CyFalse) when CYU3P_USBEP_SS_RESET_EVT is received and I am clearing the stall condition in my USB callback
if ((bTarget == CY_U3P_USB_TARGET_ENDPT) && (bRequest == CY_U3P_USB_SC_CLEAR_FEATURE))
{
if (wIndex == CY_FX_EP_VID_BULK)
{
CyU3PDebugPrint(4, "Video CLEAR_FEATURE, request=0x%x\r\n", bRequest);
/* Clear the stall condition and sequence numbers. */
CyU3PUsbStall (CY_FX_EP_VID_BULK, CyFalse, CyTrue);
CyFxUVCApplnAbortHandler();
}
}
I just switched from having my DMA created in the application initialize function to the stream start functions so maybe that is causing some issue? I have the firmware configured to stop the stream if a CLEAR_FEATURE is received with an endpoint selected, so this prevents any video from streaming. However, if I ignore this CLEAR_FEATURE then data streams after the CLEAR_FEATURE. I have included a Wireshark capture which shows this CLEAR_FEATURE and video streaming after it. Any help finding out why I am getting a CLEAR_FEATURE after streaming negotiation would be greatly appreciated.
I have looked at cyfxgpiftousb, an75779, USBVideoClassBulk and cyfxbulksrcsink examples and have configured my SET_FEATURE and CLEAR_FEATURE requests, the device checks if it is configured and if it is, use CyU3PUsbAckSetup API and otherwise use CyU3PUsbStall API. Specific to an75779 there is an additional handler for CLEAR_FEATURE addressed to an endpoint to abort the stream and this is whats causing my stream to end.
Am I correct that SET_FEATURE is directed at specific interfaces and CLEAR_FEATURE can be directed at an interface or endpoint? From what I have seen in the examples, SET_FEATURE and CLEAR_FEATURE directed at an interface simply check if the device is configured and use CyU3PUsbAckSetup if they are, otherwise CyU3PUsbStall and CLEAR_FEATURE when directed at an endpoint should abort streaming of that endpoint.
Show LessI am developing a UVC device but am confused about how the UVC protocol dictates a stream starts and stops. My UVC operation is based on the AN75779 example. Is my below understanding correct:
A stream starts with a series of negotiation packets (several PROBE packets and then a final COMMIT packet) targeting the VideoStreaming interface. These packets negotiate the resolution and frame rate that the stream will run at. Once the negotiation is complete, the COMMIT packet signals the start of the stream.
When a stream is set to close, a CLEAR_FEATURE is sent to the video endpoint followed by a SET_FEATURE targeting the interface. The CLEAR_FEATURE causes an endpoint reset according to the cyfxgpiftousb example and I am not sure what the SET_FEATURE does; AN75779 simply acknowledges if the device is configured and stalls otherwise.
I had some questions based on what I have seen:
1. When is the UVC stop function actually called? In my experience, the stream end and the FEATURE requests stop data from flowing through the FX3 but it never actually calls the UVC stop function. The only way Ive seen it called is through the frame timer. However when I implemented the frame timer for 1080p30 it resulted in an unstable output, like requesting a stream start while the stream was still active and the timer was counting missed frames.
2. Part of the previous question, what is the role of the frame timer? In the UVC example, the frame timer is used to detect stalls but why and when is this needed? When I implemented it, it only counted down if I closed the camera application I was using, when presumably the CLEAR_FEATURE told the application to stop sending data (and thus the timer was not needed).
3. Before streaming starts, I always see a FUNCTION SUSPEND SET_FEATURE packet with wInterface equal to 0. What do these mean? They are consistently 0.4s before the stream negotiation starts. Are these notifications to exit any LPM I am in? Again, these requests are ACKed if the device is configured and otherwise stalled.
Thanks,
Show Less
Hello,
My PC system is Win10. I'd like to know how to check my AMCAP.exe supports RGB888, RGB32... in UVC mode or not? And my final question was posted in: https://community.infineon.com/t5/USB-superspeed-peripherals/FX3-FPGA-with-GPIF-II-displays-black-screen-when-using-amcap-exe-and-720p-RGB888/m-p/467553#M34967 .
Thanks
Show Less