Is it possible to invert the UART/UARTE logic in the nRF52832?

[LoungingHound]

We have a need to invert the TTL logic for the serial interface. All our "Unique" SWI serial interfaces use an inverted logic e.g. idle state 0 instead of idle state 1.

This has a number of benefits for us in the systems our hardware is designed to run on. We have a number of existing products which use an AVR processor which supports this configuration, and it is easy to implement. We now want to implement this with an nRF52832 based module and would prefer not to add a hardware inverter, if possible.

However I cannot see in the configuration files an method to configure the onboard UART/UARTE device in a similar manner, but I am not confident with all the features and capabilities of the nRF52832 yet.

The other possibility is to use a software serial function instead (we only need to support 9600 or 19200 baud, and only send and receive 8-10 byte packets once or twice a day.) Has anyone successfully implemented this within the nRF52832?

[RK]

No you can't invert it by changing configuration, the UART module only supports standard UART modes. Many, many people have bitbanged UART interfaces on the nRF series however you will have to deal, if you do it, with the softdevice interrupting you when you least want it. I'd just add a hardware inverter, by far the easiest way to accomplish this. 

[LoungingHound]

OK I think a softdevice will still work for us. We have a very defined Transmit and Receive window, so unexpected interrupts are not going to occur. (We poll the peripheral and it responds, and while waiting for a response the processor only has two non critical monitoring tasks to complete). The problem with a hardware inversion is the increased power consumption, which then require additional hardware to shut down to sleep mode (we are working in the 5-10 uA range in sleep mode which is critical as this device can be running for many years on a single charge). This is going to add to the product cost and board real estate, both of which are very limited.

We did try some other work around's but each seems to cause other issues and we keep coming back to the same point.

Thanks for your feedback.