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?
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
ljbeng:
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
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.
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.
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.
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
Robin2:
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.
fungus:
Robin2:
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
fungus:
SoftwareSerial disables interrupts for long periods of time.
On that basis the ServoTimer2 library probably won't solve the problem.
...R
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.
Paul__B:
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
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.
bperrybap:
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.}
Paul__B:
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.
bperrybap:
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
Paul__B:
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.
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.
oric_dan:
Paul__B:
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.
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.
....
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.
....
Comparing software serial performance against hardware serial performance is a bridge too far in my book
This is why I abandoned the 328 chip in favor of the 1284 chip for most of my projects anymore - as the latter has 2 h.w. UARTs.
Software I2C or SPI are not really much of an issue, since the h.w. peripherals are built from the get-go to use unidirectional dataflow, master-slave operation, and are also designed from the get-go to use multiple nodes, up to 256 or so. Whereas in general, RS232 is dedicated between 2 nodes, and does none of the other.
OTOH, on one of my robots, I wanted to try having multiple "slave" boards on one RS232 channel, so I cooked up a master-slave addressing scheme, and wired all of the slave Tx pins together using a wired-"AND" diode ckt, and it works perfectly fine. [note - NOT the wired-OR ckt].
retrolefty:
oric_dan:
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.
Yep. The amount of time and effort spent trying to get it to work is astounding. There's a gazillian threads here about "software serial doesn't work!"
[/quote]
retrolefty:
Well just as with softwareSerial, there are software implementation of I2C and SPI
The "standard" SoftI2C library is shockingly bad as well. It doesn't even follow the I2C protocol.
Someone needs to sit down, and write a seriously decent version of SoftSerial to run on the UNO. I thought about it, but have found in the past that the basic way of doing things around here is too ingrained, and also decided to design my own mega1284 board in UNO form-factor, which I now use on all of my projects, and so have a 2nd h.w. UART - plus of course, tons more Flash+RAM. Plus of course, half or more of the people seem to think SoftSerial works correctly, so if you lambast it, a lot of people come to its defense. Duh ????
I'm sure a version of SS could be written that would have little impact on use of the servo library, misc timing functions, etc, if it were to adhere to the following:
have only 1 s.w. UART, and use only 2 dedicated pins (D2,D3), rather than support multiple pins and higher baudrates.
be limited to maybe 9600 bps.
use an efficient ISR based on Timer2, and which only disables interrupts for a few 100-nsec.
I'm sure it can be done.
oric_dan:
Someone needs to sit down, and write a seriously decent version of SoftSerial to run on the UNO.
I have made an attempt - though it hardly qualifies as serious, I hope it is decent.
...R
is there a way to use software serial & servo ??