inverted NewSoftSerial?

Mikal, how feasible would it be to add an inverting option to NSS?

One could use a simple zener diode+resistor to clamp voltages down to TTL and skip the buffer circuit for some input applications (e.g. GPS).

If the other device is sufficiently sensitive (I seem to recall there's an rs232 spec for 0V/5V levels? 232F maybe?) an inverted output could be connected directly to a receiver.



Jason, the “inversion” feature is fairly high on the NewSoftSerial wish list. I’ve had a couple of people contact me privately asking about how one would go about implementing such a feature, and if memory serves, once I gave them some guidance they had good results.

Logically, of course, it’s a pretty easy concept; you just flip all bits as you read or write them, so that for example

d |= (1 << mask);

becomes something like

if (invert)
  d &= ~(1 << mask);
  d |= (1 << mask);

The only reason I have not done this already myself is that because NewSoftSerial is so timing sensitive, making even small changes like that above can disrupt the carefully timed loops enough to introduce errors.

And I don’t have any inverse-logic devices lying around that I could test with, although wiring two inverse-logic Arduinos back to back might be a good start.

But I expect this this is a feature you’ll see in the next release or two.


Thanks for the info. I knew it was timing sensitive, so I didn't want to start blundering around in the code myself. :)

I happen to be interfacing to a Garmin GPS18, which uses TTL voltages but 232 levels.

At least one of the Motorola (er, Freescale) microcontrollers has hardware support for inverting the UART lines. I thought it was weird when I learned about it, but I begin to see the utility of such a feature.


What baud rate would you be using? Is that a 4800 baud device? If so, I wouldn't expect any timing problems no matter how much blundering you did. :)


What baud rate would you be using? Is that a 4800 baud device?

Yep, standard NMEA at 4800, RX only.


I would think that what makes it a little tricky to support inverted serial is that it's not just the received data bits that need inversion but also the start bit detection and stop bit verification, framing error, etc. It needs to be implemented close to the front end of the function where it is processing the data while it's still a serial stream. It might also carry a small performance hit that might effect the maximum data rate that may be usable.