We are having problems with the SoftwareSerial library found in the Arduino 1.02 Release.
When the SoftwareSerial is initialised, it sets the tx port to output and then sets it to HIGH. This causes a momentary low spike that is being interpreted as a start bit on some controllers.
Interesting. What the fix is doing is enabling the internal pull-up resistor on the pin number in question while it's still an input pin so that when the pin mode is changed to output mode it's already at a high state, otherwise without out that, when the pin mode is first changed to output mode it's default state is low until the very next digitalWrite (tx,HIGH) is executed, causing the downstream circuit to see a very brief low 'spike' before the high takes place.
Lefty
Another maybe ( or maybe not) clearer 'fix' that does the same thing might be to use:
in (2) I did several tests which show that software serial fails consequently above ~70K or with normal baud rates above 57K6. Mind you these test were quite clean, so if there is (more) interference of e.g. interrupts etc. these numbers drop.
R-T, thanks for the link. Every time I've looked at the documentation or heard feedback on softserial, I've always thought ... instead of trying to do so many things, and which end up working so poorly in version after version, why didn't they just implement a version for a couple of dedicated pins (D2, D3 come to mind) and support one well-working and robust s.w. UART that can operate from low to high baud rates?
in (2) I did several tests which show that software serial fails consequently above ~70K or with normal baud rates above 57K6. Mind you these test were quite clean, so if there is (more) interference of e.g. interrupts etc. these numbers drop.
Also, if one uses both software serial and hardware serial together, watch out for interrupt collision effects. See Hardware Serial buffer issues - Programming Questions - Arduino Forum for one (negative) effect I found limiting the speed on the hardware serial with software serial at 9600.
oric_dan:
R-T, thanks for the link. Every time I've looked at the documentation or heard feedback on softserial, I've always thought ... instead of trying to do so many things, and which end up working so poorly in version after version, why didn't they just implement a version for a couple of dedicated pins (D2, D3 come to mind) and support one well-working and robust s.w. UART that can operate from low to high baud rates?
Thanks, I'll take a look at both of those links. I do recall looking at AltSoftSerial more than a year ago, but might be worth another look.
I know it would be possible to get s.w. serial to work adequately, if you prioritize the interrupts and code in assembler for max efficiency, cause I've done it with PICs, but it may never be efficient coded in C, and without specifically integrating with the h.w. serial ISR. You mainly have to give the s.w. interrupt precedence, even if currently handling the h.w. serial intterupt. The efficiency will be poor, unless they're both inside the same ISR, and sequenced properly. Probably not gonna work with Arduino.
I see this bug has not been fixed yet. I"m still having the same problem myself. The software serial takes 1.5s to time out from an imcomplete byte being transmitted. I have statted a different thread on it becuase I didn't know this one was here. Any resolve to this issue?
link to the thread as well as data I've accumulated to show this. I thought it was an issue on the mac but it appears to be a bigger issue with software serial.