interferences between SoftwareSerial and Servo libraries...

Strange side effect between SoftwareSerial and Servo libraries:

  • A set of 4 small servos with no load and with their own power supply (but all grounded to the same ground as board supply as it should be) are constantly re-positioned by the Nano V3 board based on sensors readings.

  • It works great when using HW Serial, Serial.println("some data") function.

  • When using SoftwareSerial library println() function it causes all Servos to jump to their upper max position for the duration of the println() function.

Serial.println("sen data as expected no side effect"); //works great but if replaced with below line

mySoftSerial.println("this line causes a max position jumping side effect on Servo"); //side effect occurs

For example using a loop like the one below locks all servos in their upper max position for a long time:

for (int i=0; i<100; i++) mySoftSerial.println("this line causes a max position jumping side effect on Servo");

  • Any known issue there?
  • Is there a workaround?

Using HW Serial is not an option in my project as HW Serial Rx/Tx pins have to be used for something else, only pin 2 and 3 of Nano V3 board can be available for Serial communication in final project, hence the need for SoftwareSerial but the side effect described above is causing the solution to fall apart.

SoftwareSerial turns off interrupts while each character is sent. Usually this just causes some jitter in the Servos because the pulse length get lengthened when the timer interrupt is delayed. Are you using a very low baudrate?!? Are you sending text from an ISR or when interrupts are disabled?

  • Any known issue there?

Yes. SoftwareSerial (ab)uses interrupts. The Servo library needs to use interrupts to keep the servos in position. With SoftwareSerial constantly interrupting, the Servo interrupts don't happen often enough.

  • Is there a workaround?

Use an Arduino (or other board) with more hardware serial ports.

The Teensy boards are as small as the Nano, but have more memory, more code space, are faster, AND have multiple hardware serial ports. And, they are cheap.

@Johnwasser: I suspected clock/interrupt being the root issue, thanks for confirming that. I have been using 9600. I was hopping for a clean solution that would not allow jitter but I raised rate to 115200 and surprisingly jitter is impossible to notice at that rate, I also have room to make data sent more compact so a great and very simple workaround in the end. Thank you.

@PaulS: In that instance a Nano or Pin-compatible board is preferable as it will be inserted inside a socket on a peripheral board that already exist, but point taken, using the right tools for the project requirements tends to work better. Thank you.

There is another solution, maybe up a pay grade or two. The SoftwareSerial library needs to be hacked. If you can confine your SoftwareSerial to a port where no other bits of your application rely on interrupts (without seeing any code, difficult to say) you can selectively disable the parts of the SS library that deal with yhe unused ports. I've done this and shared with others and most of the problems go away.