USB low-full-high speed peripherals Forum Discussions
Hi,
We are validating RTS/CTS flow control of UART vendor mode on CYUSB236 EVK by sending a 7MB text file from SCB0 to SCB1. With referring to Cypress USB API document, we develop a program via Cypress Linux library to send, receive data, enable RTS/CTS flow control and register CTS notification callback function.
With RTS/CTS flow control enabled on both UART ports, the receiver(SCB1) showed some packets loss as transmitter(SCB0) just continuously sent data without knowing how to check CTS status.
We can’t find any Cypress document or sample codes of handling CTS via Cypress library on CYUSB236 or CY7C65215 website.
Could you provide document or sample codes of implementing RTS/CTS flow control correctly via Cypress library to prevent packets loss on receiver ?
Best Regards,
Justy Huang
Show Less
Hi,
On the FX2LP, I'm performing a 16-bit single read/write operation. Using the Control Center's Transfer IN button, I read 512 bytes in a single action. I use the Tiva Microcontroller to generate 16-bit data, which is just a sine wave lookup table. The sine lookup table contains 512 items, each of which is 16 bits, and I use a timer interrupt to generate sine signals at 50 Hz.
I can read some data when I press the Transfer IN button. The information I have is not what I should have. Let me give you an illustration. Let's assume that the sine lookup table has the value 0x30C0. It reads using FX2LP but repeats five to six times. Also, the majority of the data is missing. I was unable to plot the sine wave from the data. I also experimented
By altering the function of the Transfer IN button in Visual Studio, I also tried with a continuous stream of data. For a single slick, I added a while loop to gather 10 readings. But that is equally ineffective.
Can somebody advise me on what to do?
I wonder if this is a problem with the microcontroller that produces data. The controller can't produce data quickly enough.
Basically, I wanted to use this module to create a form of oscilloscope. Can somebody recommend an FX2LP example I should work on to gain a better sense of how to move forward with my project?
Thanks
Regards
Yazan Hussnain
Show Lessi have cypress hub usb manufacturing driver in dell aurora r4, x 64 based, windows 10 service tag 5W56422.
the driver is version 1.2.3.14 driver date 2015/08/19, but causing an error in device manager which is saying windows 10 is stopping this driver as it causes problems. i am looking for the most up to date driver please
Show LessDo CY7C65211-24LTXI has a Linux driver?
Can it be supported in Linux(Ubuntu)?
I only can found Windows driver for it.
Chinese describe/中文描述: 这款芯片有linux驱动吗?在linux下是否被支持?
Show LessHello,
This IC is used as a master to transmit data to a slave microcontroller via SPI communication.
SPI communication is used to send data to the slave microcontrollers.
However, the output time of this IC is less than half of the clock time.
It is difficult to satisfy the AC timing (hold time) between the slave microcontroller and the receiver microcontroller.
We are having a hard time satisfying the AC timing (hold time) between the slave microcontroller and the receiver microcontroller.
Q1)
In the data sheet of this IC, "Figure 1.SPI Master Timing" in the datasheet of this IC.
In the time chart of SPI Master Timing for CPHA = 0, MOSI(output) is output on the falling edge of SCK and
The output ends at the rising edge of SCK.
Therefore, the hold time is 0ns (THMO = 0ns).
Is this timing correct for data output?
Is data not output during one cycle from the falling edge of SCK to the falling edge of the next cycle?
(although in slave mode, one cycle of data retention is requested from the other side).
Q2)
Regarding question 1, if there is no mistake in the timing on the data sheet, the actual measurement of the data appears to show that the data changes with each falling edge of SCK.(every cycle).
This means that if the output is OFF at half-clock on SCK, the remaining half-wave is The high input impedance of the microcontroller on the receiver Is it correct to think that the potential is held by the capacitive component of the circuit? Is this correct?
Q3)
In relation to question 2 above, even after the output gate is turned off, does the output have an internal structure that keeps the potential for a while?
(How many pF is the output capacitance of this IC terminal?
Regards.
Show Less
Endpoint2 and Endpoint4 are set to be interrupted IN and OUT, respectively. To start the Endpoint2 Interrupt, I'm creating a writefile API call in Visual Basic. This is effective. I must use Endpoint4 to send data back to the host while in the Endpoint2 interrupt service routine.
Is the CY7C64013 able to detect an additional interrupt on Endpoint4 while in the Endpoint2 interrupt service routine? I am unable to accomplish this. Although I'm not sure if it's true, I think the CY7C64013 interrupt system is turned off as soon as an interrupt is generated.
As soon as I enter the Endpoint2 service routine, I re-enabled interrupts, but my code is still unable to detect the Endpoint4 interrupt.
Is there any test code that could demonstrate this to me?
Thanks,
Jamesbondss
Show LessWorking with an existing product that utilizes the FX2 for streaming video data over USB. The setup is as follows:
- Endpoint 2, bulk, 512-byte packets, quad buffering, 8-bit interface
- EP2CFG = 0xE0; // EP2 is DIR=IN, TYPE=BULK, SIZE=512, BUF=4x
- EP2FIFOCFG = 0x08; // AUTOIN, no zero-length packets, byte-wide interface on PortB
The video chip is continuously flowing data, even when no USB transfers are taking place. The frames are roughly 600 x 400 bytes in size. During the VSYNC pause, when the video chip is *not* flowing data, a small header is written to the FIFO containing some information that helps assure alignment with the video frames.
On the host pc, transfers are requested using a buffer that is larger than a single video frame. When starting up after being idle, the first few frames are thrown away -- this synchronizes the USB requests with the video frames (meaning, the first byte of the video frame is the first byte in the buffer that was passed for the read).
The problem is that after running for an indeterminate period of time, synchronization is lost. The host software normally receives data like so: header, image, header, image, ... with the sizes of those transfers being consistent with expectations. When synchronization is lost, the transfer sizes indicate fewer bytes than expected. What can cause these "short frames"?
The procedure for writing the header packets is as follows (called from within the VSYNC interrupt service routine):
- INPKTEND = 0x02, SYNCDELAY
- memcpy(&EP2FIFOBUF, &hdr, sizeof(hdr)), SYNCDELAY
- EP2BCH = 0, SYNCDELAY
- EP2BCL = sizeof(hdr), SYNCDELAY
Step 1 is needed to end the current USB transfer (the previous frame of video data). Is there a requirement that we write INPKTEND a second time -- just after writing the header?
Also, for testing, have tried eliminating the headers altogether and just letting the video frames flow, while monitoring for "short" frames. For this, I changed the ISR to *only* do step 1 (end the current packet). In this mode, I sometimes get errors and sometimes do not. If working, I always see full-sized video frames and can let it run for long periods. But if not working, every third or fourth frame will be "short" by a few bytes, and this condition will persist for as long as it is left running.
Help is very much appreciated.
-- donm
Show LessI'm working on to develop usb 2.0 host firmware which can handle USB camera(UVC).
The device(WebCam) provides video data through isochronous endpoint.
In the attached file you can hava a look what kind of interfaces and end points are supported by the device.
Belows are my fisrt test code but I'm not sure if I configure it properly.
Any comments will be highly appreciated.
glHostUvcEp = 0x81;
size = 1024;
/* Initialize the UVC */
CyU3PMemSet ((uint8_t *)&epCfg, 0, sizeof(epCfg));
//epCfg.type = CY_U3P_USB_EP_BULK;
epCfg.type = CY_U3P_USB_EP_ISO;
epCfg.mult = 1;
epCfg.maxPktSize = size;
epCfg.pollingRate = 0;
/* Since DMA buffer sizes can only be multiple of 16 bytes and
* also since this is an interrupt endpoint where the max data
* packet size is same as the maxPktSize field, the fullPktSize
* has to be a multiple of 16 bytes. */
size = ((size + 0x0F) & ~0x0F);
epCfg.fullPktSize = size;
epCfg.isStreamMode = CyFalse;
status = CyU3PUsbHostEpAdd (glHostUvcEp, &epCfg);
The structure of the descriptors in the pdf is simplified as below.
Show Less
I have a CY7C68013A-based design that I am supporting.
The design uses the GPIF to interface with an FPGA. We are using the IFCLK in internal mode (48MHz), undriven. The FPGA is clocked by CLKOUT (also 48MHz). I am trying to understand whether there is a known timing relationship between these 2 clocks, or whether I need to treat the GPIF as asynchronous to CLKOUT. I have not found any reference to a relationship between these 2 clocks in any of the documentation that I have.
Show Less
We have a CY7C68013 FX2LP processor connected to an FPGA device. Data is received from a host processor via Full Speed USB on EP2. Since it is FS USB, each packet is 64 bytes. The FX2LP processor then commits each 64-byte packet in EP2FIFOBUF to the peripheral domain and writes data to the FPGA via GPIF. I noticed that the data stream from the host processor contained large batches of contiguous zeros. To reduce USB transmission time, I devised a scheme for the host to send a special command to the FX2LP processor to generate the zeros locally. After receiving the command, I want the FX2LP processor to write the specified number of zeros (more than 64) to the FPGA. After much experimentation, I found that I can achieve this by clearing the EP2FIFOBUF to zero, then setting the GPIF transaction count (GPIFTCBx) to the desired count, and initiating a GPIF FIFO write transaction from EP2FIFOBUF. In the example below, 4000 zero bytes are written to the FPGA.
WORD byte_cnt;
byte_cnt = 4000;
memset(EP2FIFOBUF , 0, 64); // clear EP2FIFOBUF
OUTPKTEND = 0x2; // commit EP2 buffer to peripheral domain
SYNCDELAY;
GPIFTCB1 = byte_cnt>>8; // MSB of data count
SYNCDELAY;
GPIFTCB0 = byte_cnt; // LSB of data count
SYNCDELAY;
GPIFTRIG = GPIF_EP2; // launch GPIF FIFO WRITE Transaction from EP2 FIFO
SYNCDELAY;
while( !( GPIFTRIG & 0x80 ) ); // wait for GPIF Done bit
This seems to work, but I don't understand why. By experimentation I have found that when the data count is larger than 64, the 64th byte in EP2FIFOBUF (i.e. EP2FIFOBUF[63]) is repeatedly written to the FPGA. I would like to understand why this is working so that I can be assured that it is a reliable solution. I have not been able to find any information in the FX2LP documents to explain this behavior. I would appreciate if someone could provide some explanation.
Thanks.
Show Less