FTDI VCP Driver to include CTS signal on change? (IEC-460)

[Rotario]

Is your feature request related to a problem?

Hi - I'm trying to integrate with a device that uses CTS signals for flow control.

I can see below that the FTDI driver implementation follows the CNC-PSTN standard, so it's missing the CTS signal.

How can I use the ESP usb vcp driver to respect CTS signals from some legacy hardware?

esp-usb/host/class/cdc/usb_host_cdc_acm/include/usb/usb_types_cdc.h

/**
 * @brief UART State Bitmap
 * @see Table 31, USB CDC-PSTN specification rev. 1.2
 */
typedef union {
    struct {
        uint16_t bRxCarrier : 1;  // State of receiver carrier detection mechanism of device. This signal corresponds to V.24 signal 109 and RS-232 signal DCD.
        uint16_t bTxCarrier : 1;  // State of transmission carrier. This signal corresponds to V.24 signal 106 and RS-232 signal DSR.
        uint16_t bBreak : 1;      // State of break detection mechanism of the device.
        uint16_t bRingSignal : 1; // State of ring signal detection of the device.
        uint16_t bFraming : 1;    // A framing error has occurred.
        uint16_t bParity : 1;     // A parity error has occurred.
        uint16_t bOverRun : 1;    // Received data has been discarded due to overrun in the device.
        uint16_t reserved : 9;
    };
    uint16_t val;
} cdc_acm_uart_state_t;

Describe the solution you'd like.

I'd like to be able to monitor the state change using the already available
Here:

    const cdc_acm_host_device_config_t dev_config = {
      .connection_timeout_ms = 5000, // 5 seconds, enough time to plug the device in or experiment with timeout
      .out_buffer_size = 4096,
      .in_buffer_size = 4096,
      .event_cb = handle_event,
      .data_cb = handle_rx,
      .user_arg = NULL,
    };
  

Describe alternatives you've considered.

i can patch the FTDI driver for now to surface CTS in an unused bit of the cdc_acm_uart_state_t struct but I'd like to not have to patch this every time I update

Additional context.

No response

[github-actions]

Hi @Rotario! Please be aware that the following suggestions are generated by a bot and haven't been fact-checked by Espressif Systems. We hope that this message will help you until an Espressif Engineer looks at your issue.

---

You are correct that the generic CDC-ACM UART state bitmap (cdc_acm_uart_state_t) follows the CDC-PSTN spec and only exposes the standard modem status bits (DCD, DSR, etc.), not CTS. [USB CDC-ACM]

For FTDI-based USB–UART bridges, CTS is not part of the CDC UART state notification; instead, it is exposed via FTDI‑specific status bytes and control requests. The usb_host_ftdi_vcp component is a thin driver on top of the generic CDC-ACM host driver and is specifically meant to handle those FTDI details. [FTDI VCP driver]

However, in the provided knowledge sources there is:

• No documented API in usb_host_ftdi_vcp to read CTS or to get CTS change events.
• No extension of cdc_acm_uart_state_t to carry CTS.
• No example in cdc_acm_vcp showing CTS handling; it only demonstrates data and line‑coding (baud, parity, etc.) via the standard CDC-ACM callbacks. [CDC-ACM VCP example]

So, based on the available documentation:

1. There is currently no documented, stable way in the public CDC-ACM or FTDI VCP APIs to receive CTS state or CTS-change events. The CTS signal is simply not mapped into cdc_acm_uart_state_t, and no alternative field is documented.

2. Your workaround (patching the FTDI driver to surface CTS in an unused bit of cdc_acm_uart_state_t) is consistent with how this would need to be implemented internally, but it is not something you can do in a forward‑compatible way without modifying the component, because the official API does not expose CTS at all.

3. There is no configuration option in cdc_acm_host_device_config_t or the event_cb/data_cb callbacks that would enable CTS reporting; those callbacks only receive the standard CDC-ACM events and data. [USB CDC-ACM]

Given the limitations of the current knowledge sources, the only concrete options I can see are:

• Maintain a local fork/patch of usb_host_ftdi_vcp that:
  • Parses the FTDI modem‑status bytes.
  • Maps CTS into a chosen bit (or a new struct) and passes it through your event_cb.
• Or
• Open a feature request on the esp-usb repository asking for:
  • An official API in usb_host_ftdi_vcp to read CTS and possibly get CTS‑change callbacks.
  • Or an extension of the CDC-ACM notification path to carry vendor‑specific modem signals for VCP devices.

Unfortunately, the knowledge sources do not describe any existing “official” way to do what you want without modifying the driver, so I cannot point you to a ready‑made API or configuration flag.

[tore-espressif]

Hello @Rotario , thank you for raising this issue.

In your usecase, do you prefer:

1. The FTDI driver will handle CTS status. Eg. delaying TX operations unless CTS is asserted
2. The CTS value is propagated to your application via callback. The driver still tries to send data upon tx calls.

?

Please let us know, we'd like to fix soon

[Rotario]

Hiya, thanks for your comment.

Looking in the FTDI knowledge base, the chips support flow control and have 380 bytes of buffer:

""" https://www.ftdichip.com/Support/Knowledgebase/index.html?an232b_04flowctl.htm
It is strongly encouraged that flow control is used because it is impossible to ensure that the FTDI driver will always be scheduled. The chip can buffer up to 384 bytes of data. Windows can 'starve' the driver program of time if it is doing other things. The most obvious example of this is moving an application around the screen with the mouse by grabbing its task bar. This will result in a lot of graphics activity and data loss will occur if receiving data at 115200 baud (as an example) with no handshaking. If the data rate is low or data loss is acceptable then flow control may be omitted.
"""

So if flow control is enabled and CTS is enabled, then the chip will send, but as soon as CTS is dropped by the other device, the device stops sending from 384 byte buffer. Ideally we need a callback so we stop calling tx and don't overrun the 380 bytes on the FTDI chip.

How big is the buffer in esp_usb? if the application code is not notified then it could keep trying to tx and fill up the esp_usb buffer.

I think please can you do both? if you implement only 1 then data might get dropped in the esp_usb buffer if the application code keeps transmitting

If you implement only 2, then the data in esp_usb buffer already trying to send to the chip might fill up 384 bytes and cause data loss.

Would you be able to do both?