I am using the USB CDC device with the virtual com example on a K60 with MQX 3.7 adapted to our use to send data to a pc in response to requests. Currently just using hyperterminal. It mostly works fine, but if I try to send between 92 and 100 packets, it doesn't send anything until I send another packet in response to a request from the PC. Up to 91 packets works fine, 101 packets works fine. Each packet is 16 bytes in size. I am using the following to send each packet:
error = USB_Class_CDC_Send_Data(g_app_handle,DIC_BULK_IN_ENDPOINT, g_curr_send_buf, size);
Any suggestions at all?
Solved! Go to Solution.
Hooked it up to a Linux system instead, and all is good, so I am thinking it's the Windows driver that is the issue here. I am using the driver supplied by Freescale.
oops, that is actually the call within the virtual com example, we are using:
result = VirtualComSendBuffer(Buffer, BufferLength, bAddNewLine);
to use the virtual com example to send the data, the buffer passed to VirtualComSendBuffer is 16 bytes in this case.
Additional info. We increased the transmit buffer size in virtual_com.c to 2048 bytes to accomodate the amount of data we are transmitting. We also increased CDC_MAX_QUEUE_ELEMS to 32 to accomodate the data. We are seeing no errors.
Hooked it up to a Linux system instead, and all is good, so I am thinking it's the Windows driver that is the issue here. I am using the driver supplied by Freescale.
Hi,
As I found out, there are some un-neccessary code in the Virtual Com example.
https://community.freescale.com/thread/90752
Today, I also found the program in PC side can only send a packet of 16 bytes or less to VCOM, and also need some sleep between packets, othterwise the VCOM will totally blocked. So, I am wondering if you run Hyperterm in a faster PC, what will happen?
By increasing your buffer, you only delay the issue from happenning. it is not the root of the problem. You have to have your own program in PC side to slow down the sending.