SoftwareSerial - Bug

[4D_Systems]

Hello,

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.

The code currently is:-

Code: [Select]

void SoftwareSerial::setTX(uint8_t tx)
{
  pinMode(tx, OUTPUT);
  digitalWrite(tx, HIGH);
  _transmitBitMask = digitalPinToBitMask(tx);
  uint8_t port = digitalPinToPort(tx);
  _transmitPortRegister = portOutputRegister(port);
}

The 'fixed' code is:-

Code: [Select]

void SoftwareSerial::setTX(uint8_t tx)
{
  digitalWrite(tx, HIGH);
  pinMode(tx, OUTPUT);
  _transmitBitMask = digitalPinToBitMask(tx);
  uint8_t port = digitalPinToPort(tx);
  _transmitPortRegister = portOutputRegister(port);
}

This solves the issue.

Please advise

Regards
4D Systems

[retrolefty]

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:

Code: [Select]


void SoftwareSerial::setTX(uint8_t tx)
{
 pinMode(tx, INPUT_PULLUP);
 pinMode(tx, OUTPUT);
 _transmitBitMask = digitalPinToBitMask(tx);
 uint8_t port = digitalPinToPort(tx);
 _transmitPortRegister = portOutputRegister(port);
}


[Coding Badly]

@4D_Systems, please create an issue here...
https://github.com/arduino/Arduino/issues
https://github.com/arduino/Arduino/issues/new

[4D_Systems]

Done

https://github.com/arduino/Arduino/issues/1195

Thank you

[4D_Systems]

Hello again

After posting the bug report 8 days ago, still no one seems to be assigned to the bug...

Is there anything further we can do to get this seen to?

Looking at other bug reports, there seem to be numerous without someone being assigned to them either...

Can probably put a lot of it down to the holiday season.

Please advise

Regards
4D Systems

[PaulS]

Can probably put a lot of it down to the holiday season.

And other priorities, and a small staff. Patience, grasshopper.

[Coding Badly]

Hello,

After posting the bug report 8 days ago, still no one seems to be assigned to the bug...

Is there anything further we can do to get this seen to?

Absolutely!  Fork.  Fix.  Submit a pull request.

This dramatically increases the chances of the change being included much sooner than if you rely on someone else.

As an added bonus, until the fix has been applied, you can maintain your own up-to-date version by re-merging and using your fork.

[oric_dan]

Can probably put a lot of it down to the holiday season.

And other priorities, and a small staff. Patience, grasshopper.

Indeed.

I always have trouble trying to interpret the links on github, but was this issue ever resolved over there?
https://github.com/arduino/Arduino/issues/1195

I was also wondering ... do people actually have success getting softserial to work?
It never worked worth poo for me, :-(.

[robtillaart]

@oric_dan
Yes worked with Software Serial several times but with restrictions.
1) Sending works far better than receiving, so I typically used it to connect a serial display (9600/19200)
2) used it for non standard speeds, see - http://forum.arduino.cc/index.php?topic=138497.0 -

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.

[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?

[Sembazuru]

@oric_dan
Yes worked with Software Serial several times but with restrictions.
1) Sending works far better than receiving, so I typically used it to connect a serial display (9600/19200)
2) used it for non standard speeds, see - http://forum.arduino.cc/index.php?topic=138497.0 -

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 http://forum.arduino.cc//index.php?topic=178201 for one (negative) effect I found limiting the speed on the hardware serial with software serial at 9600.

[robtillaart]

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?

Try the alternate serial of Paul Stoffregen -  http://forum.arduino.cc/index.php?topic=91499.0 -

[oric_dan]

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.

[stealthtransam]

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.

http://forum.arduino.cc/index.php?topic=253995.0