USB CDC/ACM losing data

[acassis]

Hi Jan,

I have a question about how to avoid USB CDC/ACM losing (discarding) data.

According with this post the correct behavior should be discard data if buffer is full:
http://nuttx.org/doku.php?id=wiki:nxinternal:usb-out-nak

But many people on "forums" suggest the correct way should be sending NAK or stall (and let the HW to send NAK itself) if buffer is full, see:
http://www.eevblog.com/forum/microcontrollers/usb-cdc-'flow-control'/
https://groups.google.com/forum/#!topic/lufa-support/bkduO55cQjM
https://www.embeddedrelated.com/showthread/lpc2000/36681-1.php

From the last link:

"The windows implementation of CDC (usbser.sys) does not handle
handshaking signals reliably. I believe the Linux one does, as do most
of the 3rd party drivers to go with prolific or FTTI chipsets.

That said, I'm not sure if any actually implement flow control using
CTS/RTS. The other controls signals such as DTR/DST/DCD/RI etc should be
handled correctly and passed through as notify control, but flow control
would be better handled by the NAK process."

In your post http://janaxelson.com/usb_virtual_com_port.htm

You wrote:

"If the buffer is full, the virtual COM-port device can NAK attempts by the USB host
to send more data. When the remote device asserts CTS, the virtual COM-port
device can send the buffered data and accept new data from the host. To use
CTS in this way, the USB host doesn’t need to know the state of CTS."

What is the correct way to solve this issue? Should it be implementing Flow Control (RTS/CTS) ?

What is the best/reliable way to solve this issue? (the correct way could not be the best way)

BR,

Alan

[Jan Axelson]

RTS/CTS can provide flow control between two devices that are using asynchronous serial communications. For example, a USB/serial adapter might connect to a device with a serial interface and might use RTS/CTS for flow control on the serial interface.

The connection between the adapter and the USB host uses NAK/ACK for flow control.

From Serial Port Complete 2nd Edition:

The model doesn’t define a way for the host to read the state of RS-232’s CTS status signal. Device firmware can still read CTS on a local asynchronous port and take appropriate action. For example, if a virtual COM-port device has data to send to a remote device that hasn’t asserted CTS, the virtual COM-port device can store the data in a  buffer and wait to transmit. If the buffer is full, the virtual COM-port device can NAK attempts by the USB host to send data.

When the remote device asserts CTS, the virtual COM-port device can send the buffered data and begin accepting new data from the host. To use CTS in this way, the USB host doesn’t need to know the signal’s state.

[acassis]

Thank you very much Jan!

An important thing I forgot to comment in the previous message:

It is not a USB adapter with real serial lines. It is basically a microcontroller with USB interface that needs to exchange data with a host computer (Windows, Linux, Mac, *BSD, etc).

In this case using ACK / NAK is enough to implement the flow control and avoid losing data?

[Jan Axelson]

yes, that is the purpose of NAK. Your microcontroller must returns NAK when it can't receive data. The host will ACK all received data, which your host application can retrieve from the host driver's buffer.

[acassis]

Thank you Jan!

[david_s5]

ahh too many overloaded terms in our world.

I fear there may be a disconnect here.

When you are referring to ACK/NAK is the is traditional serial software protocol's or the USB's protocol ACK-ing or NAK-ing?

David

[Jan Axelson]

USB!