CDC Device initial sent data lost if application sends data immediately after tud_cdc_connected(). #2595
Replies: 3 comments
-
Beta Was this translation helpful? Give feedback.
-
This is probably a more helpful log - as above in the non-working case the application sends tx data as soon as DTR is set high which seems to clash with the remaining CDC control requests.
|
Beta Was this translation helpful? Give feedback.
-
Ah drats, turns out that data being sent "out of order" isn't really a problem.... Turns out In its implementation for serial port opening, right after it So that's where my "data sent slightly too early" is being thrown away. On micropython, the stm port is using the STM usb stack, not TinyUSB. It has a feature where data "sent" to usb CDC at startup is buffered (in the usb stack), before USB is init / connected. Then when USB is connected, data previously buffered is flushed down the line to the client. This feature has been there for years and is quite popular, I really want to replicate this feature on TinyUSB. |
Beta Was this translation helpful? Give feedback.
-
I'm working on adding a feature in micropython (tinyusb device) where a welcome banner is printed over CDC when the host opens the serial port.
At startup, the device essentially blocks on trying to send a newline over the com port, retrying until
tud_cdc_connected()
after which a few lines of text are sent and the device continues its normal startup.However, this banner text never shows on most terminal applications I've tried.
I initially found that adding a delay of at least 4ms after the initial
tud_cdc_connected() == True
"fixed" the problem, such that the banner text then comes through just fine.Further testing showed though even without the delay, the banner would show up when using:
cu -l /dev/ttyACM0
Whereas testing in
minicom
,mpremote
and (windows python based) tinycom all connected to the device fine, but never showed the banner. Any text I sent immediately after connection was lost, but ongoing comminuted communication both ways is fine.Eventually I narrowed it down to:
• working:
screen /dev/ttyACM0
• not working:
screen /dev/ttyACM0 115200
Confirmed with the following in python:
• working:
>>> import serial; p=serial.Serial("/dev/ttyACM0"); p.read(p.inWaiting())
• not working:
>>> import serial; p=serial.Serial("/dev/ttyACM0", baudrate=115200); p.read(p.inWaiting())
Note the tinyusb application on device never uses the baud rate for anything and ongoing communication works fine regardless of the set baud rate.
It appears to me that if the baud rate is set during the process of the the host opening the port, this presumably happens shortly after the DTR signal that
tud_cdc_connected()
responds to, then tinyusb clears any outgoing buffers that were loaded between DTR and baud setting?Does this sound likely / expected between behaviour?
Snippets of code involved:
Beta Was this translation helpful? Give feedback.
All reactions