Does SoftwareSerial really work at 115200 baud

Does software serial really work reliably at 115200 baud?

I need to have 2 serial devices attached at 115200 and cannot get software serial to work reliably.

I wrote a sketch to simply echo what was received and at 115200 I get ~0.2% of characters being echoed incorrectly. It works fine with 0% errors at 57600, but I really need 115200.

I jumped inside the software serial library and found this, amongst the code

   // When the start bit occurs, there are 3 or 4 cycles before the
    // interrupt flag is set, 4 cycles before the PC is set to the right
    // interrupt vector address and the old PC is pushed on the stack,
    // and then 75 cycles of instructions (including the RJMP in the
    // ISR vector table) until the first delay. After the delay, there
    // are 17 more cycles until the pin value is read (excluding the
    // delay in the loop).
    // We want to have a total delay of 1.5 bit time. Inside the loop,
    // we already wait for 1 bit time - 23 cycles, so here we wait for
    // 0.5 bit time - (71 + 18 - 22) cycles.
    _rx_delay_centering = subtract_cap(bit_delay / 2, (4 + 4 + 75 + 17 - 23) / 4);

For 115200 this means _rx_delay_centering will be 1.

To me this means there is no room for anything else to 'get in the way' at 115200.

Now I'm no expert on AVR/Arduino (never seen the instruction set until today), but surely that means the 'millis' interrupt could/can stop serial receive at 115200?

As an experiment I inserted this into my sketch TIMSK0 = 0; // disable Timer0/millis Interrupt

Now the echo program runs at 115200 without errors.

Obviously that isn't the correct answer to get things going properly, but I'm lost, how do you get SoftwareSerial working at 115200 (and gee the doco says "It is possible to have multiple software serial ports with speeds up to 115200 bps.", how?)

Thanks,

Mark

Does it even work at 38400 baud?

If you need high baud rates use HardwareSerial - perhaps use a Mega which has 4 HardwareSerial ports or a Leonardo which does not use its HardwareSerial port to communicate with the PC.

...R

If there are no interrupts Software serial can do 57600 at best (in a blocking mode). There is also ALT-serial which is more robust but cannot be used for all pins. Hardware serials are preferred as they do not need to block the processor.

did a lot of testing with SW serial speeds (UNO), see - http://forum.arduino.cc/index.php?topic=138497.0 -

Agree with Robin, get a HW serial if that is possible

So both responders said it doesn't work at 115200, my post got moved to 'project guidance'.

But neither of these address the core issue, the documentation at https://www.arduino.cc/en/Reference/softwareSerial says "It is possible to have multiple software serial ports with speeds up to 115200 bps." Who is responsible for the accuracy of the documented information?

mvandere: Who is responsible for the accuracy of the documented information?

I have no idea. But knowing will not make it work any better.

I agree it would be nice if there was an effective and prompt way to improve the documentation. You are not the first person with a complaint.

...R

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

Technically it is possible, so they are not lying there. They never said its gonna be reliable :)

In my experience I was never able to make it go beyond 57600 and I get much worse error rate then you at 115200

Our company (mvandere and I work together) has been working on a new product based around the Leonardo, and we have spent thousands on development, with facts taken from the pages like SoftwareSerial. We made initial hardware decisions based on what we researched, and then find in practice things like this SoftwareSerial issue - its disappointing really, and has been a large waste of money for us.

That page needs to be changed. While it might be true it is capable of 115200, it is under very specific and restrictive conditions, and having it state "115200 is OK", I believe is inaccurate. It needs further clarification and notes added to the page. May seem harmless but its cost us dearly. Base a prototype around information read off the Arduino website, and find its not quite as it was made out to be.

So now we have our prototype which is severely crippled because of this fact. We could have chosen a different processor and had different hardware developed around that instead. All this could have been avoided if the documentation was correct and accurate.

JADB: Our company (mvandere and I work together) has been working on a new product based around the Leonardo, and we have spent thousands on development, with facts taken from the pages like SoftwareSerial. We made initial hardware decisions based on what we researched, and then find in practice things like this SoftwareSerial issue - its disappointing really, and has been a large waste of money for us.

That page needs to be changed. While it might be true it is capable of 115200, it is under very specific and restrictive conditions, and having it state "115200 is OK", I believe is inaccurate. It needs further clarification and notes added to the page. May seem harmless but its cost us dearly. Base a prototype around information read off the Arduino website, and find its not quite as it was made out to be.

So now we have our prototype which is severely crippled because of this fact. We could have chosen a different processor and had different hardware developed around that instead. All this could have been avoided if the documentation was correct and accurate.

Just like the immortal words of President Reagan:

Trust, but Verify!

And as Gabriel Bell said:

You get what you pay for.

I'm sorry you were caught by the edges, Max performance is defined as the ragged edge.

Chuck.

JADB: we have spent thousands on development, with facts taken from the pages like SoftwareSerial. We made initial hardware decisions based on what we researched, and then find in practice things like this SoftwareSerial issue - its disappointing really, and has been a large waste of money for us

That does not seem like a wise strategy without first obtaining guarantees from the product supplier - regardlessof whether you are buying from Apple or Microsoft or an OpenSource Arduino.

Even with a guarantee I would test the performance of critical components before committing to them.

...R

So now we have our prototype which is severely crippled because of this fact. We could have chosen a different processor and had different hardware developed around that instead

Replacing the processor should add just a few dollars. Modifying the code from SoftwareSerial to hardware serial is almost immediate.

JADB: So now we have our prototype which is severely crippled because of this fact. We could have chosen a different processor and had different hardware developed around that instead. All this could have been avoided if the documentation was correct and accurate.

Your prototype process should have picked this up a long time before you spent any significant amount of money on custom boards. If you haven't actually had any custom boards made, then this is all part of the process. If it doesn't work, figure out why, and move on. I suspect we've all had 'severely crippled' prototypes at some point. That's why we prototype.

I usually start out on breadboard for the initial stages, and then make something a bit more robust on stripboard for proper testing and software development. Only when I'm happy that everything performs as expected do I look at custom boards. Even the first batch of those is expected to have some sort of issue.

Ian.

Plan B:

Bypass Arduino. Run everything at Linux side.

http://forum.arduino.cc/index.php?topic=338827.msg2341789#msg2341789

Plan C:

USB to UART bridge:

http://forum.arduino.cc/index.php?topic=338827.msg2342748#msg2342748

Plan D:

SPI-UART or I2C-UART bridge (like MAX3107 or SC16IS750)

http://forum.arduino.cc/index.php?topic=338827.msg2344203#msg2344203