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?)
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.
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.
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?
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.
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.
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.
