Enhancement request: support for inverted UART communication

[hmeijdam]

I was reading through the Serial Reference pages for MegaTinyCore (links to DXCore text)
to see if Serial.begin() can support inverted serial protocols, but could not find that in the reference.

On a Teensy for example this command will get you HW support for inverted Serial.
Serial.begin(57600,SERIAL_8N1_RXINV_TXINV);

For the Attiny I can get inverted UART communication only by configuring the UART manually and then using the Inverted I/O Enable (INVEN) bit in the PORTx.PINnCTRL register.

Here is an example sketch with the inverted serial communication, that we collaborated on earlier in this discussion forum

Or....can I use the existing Serial.begin(57600) and then add the PORT_INVEN_bm to set Serial to inverted? Would this damage something else in the core?

[SpenceKonde]

There is no wrapper around automatically doing the extremely rare use case of inverted serial. Your best bet is to invert the pin (and turn off the pullups too...).
You can do both at once (without effecting anything else about the pin) with the pinConfigure function. See the advanced digital I/O reference. You might need an external pulldown on the RX line, since unlike some hardware, we don't get an internal pulldown option.

I have amended the 2.5.0+ serial documentation to briefly mention this possibility. The reason we can't really do better is that; as is serial.begin is horrifyingly bloated (the very high register pressure. is the main reason), (I spent several days just trying to make serial smaller, getting to the point where I'd reimplemented the ISRs in assembly (this saves a considerable amount of flash when multiple interrupts call a single function because of the prologue and epilogue and the rules of the ABI), just so that the flash use didn't increase so much that it would fail my own criteria for consideration for release. That was part of the massive serial changes for 2.5.0 that adds support for half duplex, synchronous mode, mspi mode, RS485 mode, and all that good stuff.

The fact that the changes to the RXC interrupt alkso make it possible to receive a continuous stream of bits at the highest speed the hardware is capable of and not have it outrun the interrupt's ability to save it is just a bonus.

Evolved from a related effort on DxCore, though there the prime directive was to make it possible to have more than twop pin mapping options, because the DD draws near (and I can' wait to get my hands on those DD's). I think right now DD support would be achived with a find-replace on the boards.txt and that's it.

[hmeijdam]

Ok thanks for your (as always prompt and thorough) answer.

I am glad I recently added a portable installation of the Arduino IDE where Github desktop syncs with your Github version of the core. i assume that's 2.5.0. I want to port another inverted half duplex solution from Teensy to Attiny, so better give that a go on 2.5.0 I guess.

[SpenceKonde]

What is the use case that calls for inverted half duplex serial?

I wonder how ODME interacts with inven. I have to think it would be turning the port output-high to send, relying on external pulldowns, but I have not tested that...

[hmeijdam]

S-Port Description.pdf

It is for decoding FRSky S-Port telemetry data. The bus is a master/slave polling arrangement running half duplex at 57.6k-baud 8N1 inverted, Please find a brief description of the protocol attached.
It's currently done via softwareserial on AVR's that have no HW support for inverted serial like STM32 and Teensy.

If it is a rare exception, which I think it is, I would not spend your time on this. I am fine setting the UART manually as with the SBUS where we receive inverted and then transmit uninverted and change baudrates inbetween TX<>RX.
That way I don't need 2 UARTS also as I want to port a S-Port sniffer that listens to the S-port bus and transmits certain data to the serial console.

I suspect first Futaba made S-BUS difficult to imitate (different polarity (inverted), different baudrate (10K), different byte size (10bits), different parity (even) and then FRSky continued to be difficult with their S-Port implementation.
Of course those protocols were all reverse engineered in the past.