Feature Request: Serial single-wire half-duplex mode and support

[EclipseBoom]

The HW USART on these parts has a single-wire mode where the TXD pin is used for both transmit and receive.

Support for this would be nice: Serial.begin(SERIAL_BAUD, SERIAL_HALF_DUPLEX);

and to have TX and RX swtiching built into write() and so forth.

So you can just Serial.println("output"); to switch to tx mode and send then auto switch to RX mode when done.

Teensy just added this support to their package and it works well. Perhaps you could snarf that except for the register twiddling.

Meanwhile I'm off to the datasheet to read register definitions and bit functions.

[SpenceKonde]

Please create an issue to track this feature request so it doesn't get lost - if this is not done, it will likjely be forgotten about and never implemented, even though it's not hard and I'm going to do some significant work on serial very soon,

I don't use teensy. one-wire half duplex serial on modern AVR devices includes loopback mode, so you also receive the data you transmit - does teensy's hardware do the same thing? If so, do they hide it from the user and a) silently throw it away or b) check each character against last transmitted one to make sure they'rethe same?

How do they guard against two devices sending data at the same time? Is that left as an exercise for the application developer? That seems to be how it's handled on AVR.

[EclipseBoom]

OK on the issue:

I think that the NXP chip doesn't receive its own data when it transmits. That seems like a small chip kind of thing. Either that or the driver dumps it. I don't know the details.

I think for the Tiny if you just document how it behaves then it will be OK for the small number of people who actually use that function. The Teensy serial driver does have a nice function called Serial.clear(); which discards anything in the receive buffer along with flush() which blocks until all characters are actually sent.

Transmission conflict has to be done at the application level. I think the AVR datasheet (or app note) explicitly says you have to do it in code.