Handling of CDC without setting control line states (DTR)

[duempel]

This is a follow up to #400 and #401

Is your feature request related to a problem? Please describe.
Within #400 and #401 it's been discussed if there is a need for CDC to work without the data terminal ready (DTR) bit being set. Usually terminal application will set this bit to tell the data communication equipment (DCE) device that the data terminal equipment (DTE) device is present. But this is no standard and there are cases in which the DTR bit is not set by DTE:

• A lot of proprietary industrial software don't make use of this, as @HiFiPhile mentioned here. I also made this experience with controlling and sensing software before.
• Some application may abuse the control line states as @me-no-dev explained in some comments here. The line changes are used to hardware toggle reset pin of a target MCU to enable UART bootloader with USB-UART chips.

Also the request list of Universal Serial Bus Communications Class Subclass Specification for PSTN Devices for Abstract Control Model (ACM) does not require the SetControlLineState or even strongly recommend this as seen in the figure below.

Because we cannot guarantee that every application uses the DTR bit we agreed on changing our CDC implementation to work also without it.

Describe the solution you'd like

@HiFiPhile already set up a solution with #401 that introduces a define CFG_TUD_CDC_IGNORE_DTR to tell CDC class not to check the DTR bit when flushing tx data. This solution might work just fine, but there are some cons to think about:

• standard operation still does not work if the user not active set this define. Especially unexperienced user can run into problems with applications that do not use DTR and wonder why no data can be sent while it was working with different usb stack before
• a define will change the configuration for all cdc interfaces. Ignoring this bit for only one specific interface is not possible

A solution also should take into account that if DTR is never checked we cannot know if any connection is established and data is drained from FIFO. If no IN token are received the FIFO could be filled up with old data very fast and cannot take any new bytes. If new data is prefered the FIFO could be set to overwritable if no DTR is set. Detailed information to this are written in #401 .

We came up with a first idea for a solution which @hathach summarized here.

1. Skip connected() check within write_flush() --> up to application, not need for IGNORE_DTR macro
2. TX FIFO become overwritable if DTR is not set (nonoverwritable if DTR is set), this to prevent FIFO overflow without IN token from host. Application should use write_available() and/or connected() to prevent accidental ovewrite.
3. Skip abort API, which could possibly cause missing a chunk of data after EP BUF due to buffer overflow up when DTR is not set (and host not sending IN token).

(The mentioned abort API could be used to delete one very old data frame of endpoint size when a terminal software can start a connection with use of DTR bit.)

I'm going to create a draft PR with the above explained information in a couple of days. There are a lot of different cases of application functionality which might require different handling. It's important that current applications will not get effected by these changes, while future application can profit. The compability will be discussed within the related PR.

[hathach]

Thank you for the sum-up issue, this is definitely needed when doing PR later on 👍

[hathach]

closed by #506