How to manipulate control lines on a virtual serial connection ?

[dshadoff]

I have a project I would like to make, where a RP2040-based board is connected to a PC, and becomes a CDC device; besides transferring simple text back and forth, I need to send data to the host via control lines - specifically, DCD (data carrier detected), and RI (ring indicator).

I believe such functionality exists in tinyusb, but please let me know if it does not.

While I am comfortable to write most of the code based on the 'examples/device/cdc_msc' example, there are no examples which manipulate such control lines - so it might be useful to also update the cdc_msc example to demonstrate this.

[hathach]

in USB, device can only response to host request (cannot actively send anything). You need to run the run PC script to get the DCD, RI to see which command it send to device (similar to how DTR RTS is done with SET/GET CONTROL LINE STATE) then response accordingly.

https://github.com/hathach/tinyusb/blob/master/src/class/cdc/cdc_device.c#L352

The ACM functional descriptor may need some change to indicate support for those parameter, you could find more detail in the USB CDC PSTN specs

[dshadoff]

Thank you for your reply.
So it seems that it is not yet implemented.

I was planning to use python's pySerial class on the Host, but I don't have USB man-in-the-middle diagnostic hardware at this time. I have ordered a "Luna" from CrowdSupply, but it will be nearly a year until it arrives.

In order to capture the request type, I suppose the best way would be to:

1. Verify a functioning host script by testing using a FT232 device where I can manipulate the RI and DCD lines electrically/manually.
2. Run the same script against RP2040 with TinyUSB, where LOG is set to 2 and a special line added at the case's default statement, to log which request it was.
   

   tinyusb/src/class/cdc/cdc_device.c

   Line 412 in 58477b7

   default: return false; // stall unsupported request

Does this sound reasonable ?
Is there a better way ?

Based on how 'SET_LINE_CONTROL_STATE' works, I was expecting a corresponding 'GET_LINE_CONTROL_STATE'... but I guess USB is not so straightforward... I now suspect that it would be either 'GET_RINGER_PARMS' or 'GET_LINE_PARMS'.

[dshadoff]

According to "Serial Port Complete" by Jan Axelson, these lines are sent in a Notification. (note that I don't fully understand the internals of USB).

Are notifications currently supported ?

The book elaborates:

Abstract control model devices support up to three notifications:

NETWORK_CONNECTION  0x00  (Network or modem connection status)
RESPONSE_AVAILABLE  0x01  (Requests the host to issue a GET_ENCAPSULATED_RESPONSE request)
SERIAL_STATE        0x20  (State of CD, DSR, Break, and RI)

Each notification begins with an 8-byte header:

bmRequestType  1   0x0A
bNotification  1   Notification Code
wValue         2   Notification-specific data
wIndex         2   bInterfaceNumber
wLength        2   Number of data bytes to follow (zero or more)

In the SERIAL_STATE notification, wValue = 0x0000, wLength = 0x0002, and the returned data is in this format:

Bits   Field       Description
15..7  --           Reserved
6      bOverRun     Received data has been discarded due to overrun
5      bParity      A parity error has occurred
4      bFraming     A framing error has occurred
3      bRingSignal  State of ring indicator (RI)
2      bBreak       Break State
1      bTxCarrier   State of data set ready
0      bRxCarrier   State of carrier detect (CD)

The Abstract control management functional descriptor for the device would include:
bmCapabilities = 0x02 (support for SET_LINE_CODING, SET_CONTROL_LINE and GET_LINE_CODING requests and the SERIAL_STATE notification).

[hathach]

I was planning to use python's pySerial class on the Host, but I don't have USB man-in-the-middle diagnostic hardware at this time. I have ordered a "Luna" from CrowdSupply, but it will be nearly a year until it arrives.

you don't really need analyzer, it is mostly for troubleshooting the bus signal when doing hardware. For protocol level, log work fine, it just take more time for you to insert those printf

In order to capture the request type, I suppose the best way would be to:

1. Verify a functioning host script by testing using a FT232 device where I can manipulate the RI and DCD lines electrically/manually.

FTDI/CP2014 is not ACM but proprietary protocol, and cannot used as reference.

2. Run the same script against RP2040 with TinyUSB, where LOG is set to 2 and a special line added at the case's default statement, to log which request it was.
   Does this sound reasonable ?
   Is there a better way ?

Based on how 'SET_LINE_CONTROL_STATE' works, I was expecting a corresponding 'GET_LINE_CONTROL_STATE'... but I guess USB is not so straightforward... I now suspect that it would be either 'GET_RINGER_PARMS' or 'GET_LINE_PARMS'.

Just find an way to execute the corresponding request than try to reply accordingly to the specs.

[hathach]

According to "Serial Port Complete" by Jan Axelson, these lines are sent in a Notification. (note that I don't fully understand the internals of USB).

Are notifications currently supported ?

There is a notification endpoint, you can send notif message. The notification still need to wait for host to poll. Since you write the host script, you can just run the control request without the need of notification. Both way is possible. Just try it out.

[dshadoff]

I didn't see the notification endpoint in tinyusb... can you point me to where to find it ?
Once I understand that, I can add some code and do some experiments from there.

I'm not clear on what you mean by "just run the control request without the need of notification"...
The intent is to use python & pySerial, an existing library, together with currently-existing USB VCP protocol drivers; I am not prepared to add any host-side driver functionality.

[dshadoff]

While working with a separate theoretically-complete stack and library (PyFTDI and FTDI's VCP drivers), I was unable to get RI or DCD to respond reliably, so I will abandon this approach to communication (virtual COM port), as there seem to be too many other pieces missing from end to end, regardless of the status of tinyUSB.

I will close this line of inquiry.