SoftwareSerial should document it is half-duplex

[alieslam]

I was exploring SoftwareSerial library to see its performance in our application and I uploaded the following simple sketch:

#include <SoftwareSerial.h>

SoftwareSerial mySerial(10,11);

void setup() {
  mySerial.begin(9600);
}

void loop() {
  if(mySerial.available())
  {
    byte data = mySerial.read();
    mySerial.write(data);
  }
}

The results were surprising, the library couldn't reply back with the data I sent, even when we tested with data as low as 2 bytes per transaction.

We have tried with all standard baud rates mentioned on Arduino website and even went with rates as low as 300 bps.

Here are some sample data that I sent and received in hex:

Baud Rate = 9600

[TX] - 92 29 
[RX] - 92 FF

Baud Rate = 9600

[TX] - FF 29 A5 09 02 FD 02 FD 01 00 
[RX] - FF 95 13 02 01 FF 

Baud Rate = 4800

[TX] - FF 29 A5 09 02 FD 02 FD 01 00 
[RX] - FF 95 13 02 01 FF 

Baud Rate = 300

[TX] - FF 29 A5 09 02 FD 02 FD 01 00 
[RX] - FF 95 12 02 01 FF

As you may see, there are a pattern. The data is the same but the baud rate is different and still the date sequence is very similar.

My tests were performed using the last version of Arduino 1.6.8 using a USB to serial cable connected to the software serial pins. I repeated the tests on different Windows/OSX machines, different Arduino boards (Uno and Mega) and different USB-Serial cables and all of them had the same results.

I've tried AltSoftSerial library and all my tests where working with baud rates up to 57600 and data up to 200 bytes per transaction.

I think the implementation is broken somehow, I know its an issue related to timing, but I don't know how is that happening.

It is not mentioned anywhere that the communication is half-duplex, As i have tested the library by letting one Arduino sending data using SoftwareSerial and other Arduino receives data sent also by SoftwareSerial by the first and all the packets were received successfully.

Your documentation (https://www.arduino.cc/en/Reference.SoftwareSerial) mentions that it is possible to have multiple software serial posts with baud rates up to 115200, could you explain how that is possible but running my simple loopback sketch isn't?

Am i missing something ? Please advise.

Thanks,

[NicoHood]

I think that is the limitation of softserial. You cannot just do fullduplex with it.

If you receive a byte an interrupt listens to the whole byte and the continues with the main program.
The sending would be interrupted in this time.

So I am not sure if interrupts are disabled while sending. However if they are you are missing an incoming byte possibly. If not the sended byte gets corrupted (as the receiving could happen inside sending those 8n1 bits).

The only way to partly solve this would be to sync sending and receiving. But i dont know how complex this is.

[alieslam]

@NicoHood Thanks for your explanation ... But i think they should mention that the library doesn't work as a full duplex on their website.

[PaulStoffregen]

Not only does SoftwareSerial lack full duplex, but it disables interrupts for an entire byte transmission time. If you use slow baud rates, this has a pretty bad effect on regular hardware serial, and millis, and Servo, and anything else using interrupts.

Probably the biggest problem with SoftwareSerial is people intuitively but incorrectly assume it slower baud rates are better. In reality, the slower it goes, the more harm it inflicts on everything else. Documenting technical details in ways novices can understand is tough. But if even this two simple piece of advice could be communicated, that faster (not slower) baud rates are best to use, and that it can't simultaneously transmit and receive, much of the pain of SoftwareSerial misunderstanding could be solved...

I wrote AltSoftSerial to solve these issues. But it requires a 16 bit timer and is limited to only specific pins associated with that timer, so not a perfect solution for projects needing those commonly used hardware resources.

[MaderDash]

@per1234, is this issue still relevant for the documentation? If it is, could you specify where you would like it to be documented? Please inform me so I can address the fix.

[per1234]

Thanks for your valuable suggestion @alieslam. This was resolved a couple of years ago by #295 but we didn't close the issue at that time.