I was under the assumption that the arduino 1.0 softwareserial is a rewritten NewSoftSerial authored by Mike Hart but was I so wrong! For a whole morning I was puzzled by it. Why didn't I get anything from my serial LCD keypad?! The not New SoftwareSerial must be very different under the hood from Mike Hart's version. In his version you can use any pins but in this official version you can only use a few select pins for RX. I later learned out from the sample code.

Quote

Note: Not all pins on the Mega and Mega 2560 support change interrupts, so only the following can be used for RX: 10, 11, 12, 13, 50, 51, 52, 53, 62, 63, 64, 65, 66, 67, 68, 69

As I know Mike's version can't simultaneously receive from multiple instances of NSS (right?).

Does this mean the official SoftwareSerial can simultaneously receive from multiple instances of SoftwareSerial? Thanks.

Further reading:

Quote

It is possible to have multiple software serial ports with speeds up to 115200 bps.

Sounds like more powerful.

In general, how do I get these updates if I'm already using a lot of arduino libraries?

I strongly doubt you could use any version of softwareSerial to receive simultaneously. The ones I have seen use tight timing loops to clock bits in, so once the original bit started it turns interrupts off and you couldn't clock in bits from other ports.

I may be wrong, but I think you will run out of processing power attempting to do it, particularly at high baud rates.

Please post technical questions on the forum, not by personal message. Thanks!

Software Serial cannot receive OR send simultaneously as SW has to control the timing of the pulses and the Arduino is single threaded.RX is triggered by an interrupt but TX does not use interrupts. So carefully choosing which pin to RX and TX, increases the (theoretical) amount of soft serial ports.

What I like the most of SoftSerial is that you can create a TX or RX only serial port by declaring the other -1.

Rob, I have not read about the -1 yet. Is it mentioned in reference? Would be helpful for gps or other output only devices and non-smart serial lcds. In my case the lcd returns button pushes and menu choices so both rx and tx are needed.

It only supports a single instance, and requires specific pins, and uses a timer.... but it creates much less interrupt latency than normal SoftwareSerial. In some cases (with carefully chosen baud rates), it can even be used together with AltSoftSerial and SoftwareSerial in the same project, for 3 serial ports on an Arduino Uno.

Of course, if you're using Mega, Due, Teensy3 or any other board that has multiple real hardware serial, you should always use the hardware serial before resorting to software serial.

On Arduino Mega, if you really need 6 serial ports, and 2 of them could run at relatively slow baud rates (eg, 9600 or maybe even 19200 baud)... you probably could use 2 copies of AltSoftSerial. You'd need to make another copy of the library, change the name to something like AltOtherSerial, and edit its copy of config/known_boards.h to use the other timer.

Mega actually has 4 of those timers, so in theory it would be possible to have 4 copies of AltSoftSerial working simultaneously (at slower baud rates), for 8 serial ports working simultaneously. Unfortunately, 2 of those 4 timers can't be used, because the input capture pin for those timers is not brought out to any location on the board. However, if you only wanted to transmit and never receive, you could make modified copies of AltSoftSerial that only transmit. It's the receive pins that aren't available on Mega's PCB layout.

It only supports a single instance, and requires specific pins, and uses a timer.... but it creates much less interrupt latency than normal SoftwareSerial. In some cases (with carefully chosen baud rates), it can even be used together with AltSoftSerial and SoftwareSerial in the same project, for 3 serial ports on an Arduino Uno.

Of course, if you're using Mega, Due, Teensy3 or any other board that has multiple real hardware serial, you should always use the hardware serial before resorting to software serial.

I wan't to second this. I was using SoftwareSerial to talk to a serial LCD that is currently locked at 9600 baud (no documentation available). It seriously interfered with the stuff on Timer0 (millis() and delay()) and was causing my clock project to lose massive amounts of time due to lost Timer0 interrupts. I switched it to Paul's stuff here and it works perfectly now. There are no more lost interrupts and no more code running for more than 1mS with interrupts disabled (gag). His stuff works perfectly so far, but I"m not doing simultaneous send and receive. Since he uses interrupts and apparently the PWM feature for output, I expect it to have no trouble in that situation.