Go Down

Topic: Servos jitter during software serial transmit (Read 2 times) previous topic - next topic

ljbeng

I have 3 servos on 9,10,11.

I have software serial transmit only on Pin 5.

Sorry I don't have the program with me to post here but it is very short.  In Setup, I attach the servos and move them "home", set up the software serial for TX on Pin 5. 

In Loop, I am just writing maybe 100 characters to software serial and then delay(6000).  After the 6s delay, all my servos jitter and the string is transmitted again.  Any ideas?

Robin2

I'm not sure from your question whether the message is intended to be transmitted repeatedly?

A possible problem is that the SoftwareSerial library conflicts with the Servo library. You could try connecting your servos to different pins - that might avoid a conflict. Or you could try controlling your servos with the ServoTimer2 library here. As its name suggests it uses Timer2 to control the servos.

Another common problem is trying to power servos from the Arduino 5v pin. They are likely to draw too much current and cause the Arduino to misbehave. Servos should have their own power supply with the power supply ground connected to the Arduino ground.

...R

Robin2


In Loop, I am just writing maybe 100 characters to software serial and then delay(6000). 


Just had another thought - maybe you should just send a single character on each iteration through loop() ? Or perhaps even time the transmission of the characters so that the previous one is defintely gone before you try to send the next one (I mean just figure out the milliseconds per character from the baud rate and add (say) 10%.

...R

ljbeng

These are all good answers... Thanks.   :)

It is a test program so I was just sending 100 character and waiting 6s just to watch things.  I did try changing the servo pins around but I still see the issue.  Will try 5v supply next.

Thanks.

ljbeng

A Quick test... If I changed to hardware serial and 6s delay, no jitter.  Is it tricky to have a permanent sensor connected to the hardware tx and program from the IDE at the same time?  I may have a standby pin on the serial receive device I am sending to.

Robin2


A Quick test... If I changed to hardware serial and 6s delay, no jitter.  Is it tricky to have a permanent sensor connected to the hardware tx and program from the IDE at the same time?  I may have a standby pin on the serial receive device I am sending to.


That suggests you should try the ServoTimer2 library in conjunction with SoftwareSerial.

I think you need to put resistors to prevent the permanently connected sensor from interfering with the other use of the Rx/Tx (as you can see I am not an electronics expert) and you probably need to ensure the sensor is off. Does the sensor need to be connected to the Arduino Tx?

...R

fungus


A possible problem is that the SoftwareSerial library conflicts with the Servo library.Arduino ground.


Upgrade that from "possible" to "definite".

SoftwareSerial disables interrupts for long periods of time.

No, I don't answer questions sent in private messages (but I do accept thank-you notes...)

bperrybap



A possible problem is that the SoftwareSerial library conflicts with the Servo library.Arduino ground.


Upgrade that from "possible" to "definite".

SoftwareSerial disables interrupts for long periods of time.



Exactly.
The problem is there are two things that are driven by s/w
(servo signal lines, async signal line) that need accurate timing with low latency/jitter.
One does it's timing using interrupts (servo), the other blocks interrupts to do its timing (soft serial)
This is the issue.
There is no way to make both work.
SoftSerial can only be used in environments or with libraries that either don't use interrupts
or don't care about the latency of the interrupt processing.
Servo is not one of them.

--- bill

Robin2


SoftwareSerial disables interrupts for long periods of time.


On that basis the ServoTimer2 library probably won't solve the problem.

...R

Paul__B


One does it's timing using interrupts (servo), the other blocks interrupts to do its timing (soft serial)
This is the issue.


Wow!

So SoftwareSerial is essentially useless.

bperrybap



One does it's timing using interrupts (servo), the other blocks interrupts to do its timing (soft serial)
This is the issue.


Wow!

So SoftwareSerial is essentially useless.


I wouldn't call it useless, it depends on your environment.
Many projects  don't use/need interrupts or are not super sensitive to
latency between when the interrupt occurs and when the ISR runs.

That said, it probably it can create issues.
What hurts is that interrupts are off for entire transmission,
the start bit and 8 bits.
At baud rates below starting at about 9600, the millis interrupt will start to miss ticks.

--- bill

Paul__B


I wouldn't call it useless, it depends on your environment.


Well, the reason for using it will generally be that you have a "busy" application, which is pretty likely to require various timing functions.


What hurts is that interrupts are off for entire transmission, the start bit and 8 bits.


I suppose I will have to look into what the library does.  The thing is that transmission is much the easier side, it only requires a timer interrupt for each bit, while reception requires three or four interrupt "clocks" per bit.  Well-written code would use the same (four per bit) interrupts for both to implement full-duplex.

{I wrote just this stuff for the Micro Color Computer some 26 years ago.}

bperrybap



I wouldn't call it useless, it depends on your environment.


Well, the reason for using it will generally be that you have a "busy" application, which is pretty likely to require various timing functions.


What hurts is that interrupts are off for entire transmission, the start bit and 8 bits.


I suppose I will have to look into what the library does.  The thing is that transmission is much the easier side, it only requires a timer interrupt for each bit, while reception requires three or four interrupt "clocks" per bit.  Well-written code would use the same (four per bit) interrupts for both to implement full-duplex.

{I wrote just this stuff for the Micro Color Computer some 26 years ago.}



The code is not very sophisticated.
No timer interrupts on the tx side.
It uses an ISR or the receive side to detect the start bit, after that it hangs out in the ISR
from the start bit, and then the code polls the line for all the data bits.

Timers is a big hole in Arduino. I'm amazed that for as  long as Arduino has been around
that the core code still doesn't have any timer support.

--- bill

oric_dan



One does it's timing using interrupts (servo), the other blocks interrupts to do its timing (soft serial)
This is the issue.


Wow!

So SoftwareSerial is essentially useless.


Well Paul, I for one agree with you 100%. Amazingly, SoftSerial has been rewritten now half a dozen times, and it's still just as bad as ever.

Anyone doing embedded programming 'outside' the ardunio environment knows that Rule #1 is: ISRs should be short and sweet, and quickly returned from.  Don't hang up the processor.

retrolefty




One does it's timing using interrupts (servo), the other blocks interrupts to do its timing (soft serial)
This is the issue.


Wow!

So SoftwareSerial is essentially useless.


Well Paul, I for one agree with you 100%. Amazingly, SoftSerial has been rewritten now half a dozen times, and it's still just as bad as ever.

Anyone doing embedded programming 'outside' the ardunio environment knows that Rule #1 is: ISRs should be short and sweet, and quickly returned from.  Don't hang up the processor.


Well just as with softwareSerial, there are software implementation of I2C and SPI and none are designed to operate as well or replace their hardware assisted versions. They are work a rounds when there are things like pin use conflicts, etc. If having two hardware serial ports are required a 644P/1284P 3rd party board could be looked at or up to four serial hardware ports on the mega2560 board is readily available.

Comparing software serial performance against hardware serial performance is a bridge too far in my book.

Go Up