Change to USB Serial to not require DTR set by the host

It seems that our USB Serial functionality differs from the normal e.g AVR and SAM functionality in that we do not send data unless the USB connection DTR is set

I made a change for this in the ZUMspot branch to support the Ham radio community, where it does not check for DTR

See

https://github.com/rogerclarkmelbourne/ … re/ZUMspot

If our functionality differs from the norm, perhaps I should merge this change into the Master branch

Edit.

I’ve tested this, including leaving the Arduino terminal window open and I don’t see any negative effects of the is change.

So I think I will update the master repo unless anyone has any objections

Actually, there does seem to be a side effect of this change

If I close the terminal window and wait a while, by sketch seem to stop while waiting for the USB to send the data to the PC (as there multiple Serial.println () lines in the graphic test)

So perhaps we can’t do this after all. Well, not unless we prevent it from stopping in Serial.print etc if the host its not available

I’ll do some more testing to confirm this phenomenon

[RogerClark – Sun Jul 16, 2017 4:04 am] –
If I close the terminal window and wait a while, by sketch seem to stop while waiting for the USB to send the data to the PC (as there multiple Serial.println () lines in the graphic test)

Same issue currently for F4 too: https://github.com/rogerclarkmelbourne/ … issues/306
The problem is that I don’t know hot to fix it because the new USB lib (SPL from ST) has no function “usb_is_connected()”

The F1 only has this issue if I remove the check for DTR

I looked at why this may be happening, and it looks like its because the TX buffer gets filled and returns zero

https://github.com/rogerclarkmelbourne/ … acm.c#L428

So it stays in this while loop

https://github.com/rogerclarkmelbourne/ … #L127-L129

I don’t know the best fix for this. I presume that the best way to handle this, is for the oldest item in the buffer to be removed and just keep the newest, ready for when the USB Host is ready for the data.

We can probably do this my modifying the ring buffers in usb_cdcacm.c

[RogerClark – Sun Jul 16, 2017 10:23 am] –
I don’t know the best fix for this. I presume that the best way to handle this, is for the oldest item in the buffer to be removed and just keep the newest, ready for when the USB Host is ready for the data.

How is this solved for AVR and SAM boards?

Rather than simply remove this, can we make the change configurable, there may be times when you do want the sketch to wait for the host rather than simply dropping or skipping data. If configurable then I guess the default behaviour should match the “standard” Arduino behaviour.

Since in my connections I never used flow control and it works, I believe that DTR is used by the driver.

Arduino IDE uses DTR to reset the UNO when you open serial monitor. I don’t know if it is the same with Leonardo, Due, our STM32 boards and all other boards who have native USB.
As far as I know DTR is never used during communications, many terminal programs shows the serial line states but I can be wrong since I never investigated this, I simply assumed that DRT is never used.

If possible IMO is better to have this configurable.

DTR is a remnant from arduino world to generate the reset pulse for the “autoreset” feature. I am pretty sure that we don’t need to play with DTR in USB Serial implementation.

[Slammer – Mon Jun 18, 2018 5:06 pm] –
DTR is a remnant from arduino world to generate the reset pulse for the “autoreset” feature.

Only in Arduino with Atmega328 family, Leonardo and Due (usb native boards) use another method using 1200 baud connection.

[zoomx – Mon Jun 18, 2018 8:10 am] –
Since in my connections I never used flow control and it works, I believe that DTR is used by the driver.

Arduino IDE uses DTR to reset the UNO when you open serial monitor. I don’t know if it is the same with Leonardo, Due, our STM32 boards and all other boards who have native USB.
As far as I know DTR is never used during communications, many terminal programs shows the serial line states but I can be wrong since I never investigated this, I simply assumed that DRT is never used.

If possible IMO is better to have this configurable.

Arduino Leonardo just opens a serial connection at 1200 bps and after that it closes the connection. That occurs a reboot to the mcu and put it in bootloader mode.

The DTR is necessary in case of using the “1EAF” reboot magic sequence. Without the DTR, every incoming data has to be searched to see if it contains the magic sequence 1EAF.
In case of DTR, the incomming data will be searched only after a DTR incomming signal.

OK, then low DTR state is used as a flag to examine the incoming data; but why can’t we send while DTR is low?

I think I can modify usb_cdcacm_tx function to overwrite the oldest data in the TX ring buffer. If you can think of a situation where it could lead to a data loss, I can make new behaviour configurable, with old behaviour being the default.

Or, as another preposition, I can change size_t USBSerial::write(const uint8 *buf, uint32 len). Currently it always returns 0 if I’m not mistaken (https://github.com/rogerclarkmelbourne/ … l.cpp#L119) because n variable is never modified. Let’s make this function return the actual number of bytes written and let the user retry the transmission later if he wants. Also, a configurable TX timeout can be added to this function so that it doesn’t get stuck in the loop forever.

Then we can remove the check for DTR from USBSerial::operator bool().

As another thought, Wikipedia says that On many operating systems, including Windows, the DTR line is held low while the serial port is unused and not being controlled by any applications.
Then we can make this check for DTR configurable – if DTR is low, then the port is probably closed, but if the user still wants to send something, he can. I, for one, needed to send while DTR is low because I used STM32 as USB-Serial bridge for ESP32 chip, and its bootloader sets DTR low and it needs bidirectional data exchange.