Sample SoftwareSerial code to use in Arduino+Xbee

Hi,
I am facing some problem using <SoftwareSerial.h>. Does anyone have sample code for SoftwareSerial where I can send a simple message from transmitter and it will be received by receiver the other end? I found codes but mostly transmitter whereas I am looking for transmitter - receiver code. Or if someone wants to run my code in his arduino+xbee that would be so much appreciated.

leduno:
Hi,
I am facing some problem using <SoftwareSerial.h>. Does anyone have sample code for SoftwareSerial where I can send a simple message from transmitter and it will be received by receiver the other end? I found codes but mostly transmitter whereas I am looking for transmitter - receiver code. Or if someone wants to run my code in his arduino+xbee that would be so much appreciated.

Well, check out the examples provided with the IDE for SoftwareSerial.h, or for a nearly identical version try this:

/*
 * SerialSoftwareSerial_loopback - This sketch simply connects the hardware Serial device to a SoftwareSerial device
 *  to provide a hardware testbed to check serial communication.
 *
 * By Chris "Sembazuru" Elliott, SembazuruCDE (at) GMail.com
 * 2013-07(JUL)-17
 *
 * Oops. Turns out this is nearly identical to the SoftwareSerialExample provided by the IDE.
 */

// Add any requred #include lines here for external libraries.
#include <SoftwareSerial.h>


// Define any desired global scope constants and variables.
// (Global constants and variables are usually intialized to zero when defined.)
SoftwareSerial sSerial(10, 11); // RX, TX

void setup()
{
  Serial.begin(115200); // Change this to whatever your like running your Serial Monitor at.
  while (!Serial); // Wait for serial port to connect. Needed for Leonardo only.
  delay(1000); // Simply to allow time for the ERW versions of the IDE time to automagically open the Serial Monitor. 1 second chosen arbitrarily.

  // Put your setup code here, to run once:
  sSerial.begin(9600); // Change this to whatever the device attached to SoftwareSerial is configured for.

}

void loop()
{
  // Put your main code here, to run repeatedly:
  if (Serial.available())
  {
    sSerial.write(Serial.read());
  }

  if (sSerial.available())
  {
    Serial.write(sSerial.read());
  }

}

I actually used this code when playing with my XBees the first time. I had one XBee connected directly to one COM port, and the other connected to my UNOr3. I had the UNOr3 connected to a second COM port. I opened both COM ports on my computer with terminal software (two instances of RealTerm in my case) and was able to verify that what I typed into one terminal showed up on the other terminal and vice-versa.

I did notice data burst issues with mismatched baudrates between SoftwareSerial and the hardware serial. Probably because both were trying to use the same interrupts so the slower baudrate would swallow multiple interrupt requests from the faster baudrate.

Enjoy.

Thank you for the code. But seems like something is wrong here in my hardware. I am using xbee Series 1 and xbee explorer in one side and other side its Uno R3+Xbee S-1+Xbee shield[https://solarbotics.com/product/51835/]. But for some strange reason the same thing whichever you just put is not working. I am not getting any data in either terminal.

But for some strange reason the same thing whichever you just put is not working

What are you using SoftwareSerial for? That shield can attach the XBee to the hardware serial port or to nothing. You can not, with additional wiring, connect the XBee to another set of pins. Which means that using SoftwareSerial to read from other pins is not going to work.

Trying to use even such a trivial sketch as in reply #2, some of us never got any of the softserial library variants to work worth poo, and completely gave up on trying to use it. Other people seem to be luckier, I don't know why, they usually mention something about following the "strict" rules. You'd think the trivial naive sketch would work, at the very least.

completely gave up on trying to use it.

Is there any alternative? Then how can I solve the problem of sending a command through serial monitor command box to another xbee node?

With a Uno, probably the most reliable method is to use a hardware switch to change the Rx,Tx pins between XBee and the USB debug port, so only one or the other is connected at a time. You can also go to Mega boards which have multiple h.w. UARTs. What I did was to develop my own Uno-size PCB using an ATmega1284 chip, which has 2 UARTs. Crossroads Bob sells the Bobuino board, which is similar. The h.w. UARTs are robust, and the softserial problems are forgotten.

http://www.crossroadsfencing.com/BobuinoRev17/

Except for the known bug about dropping char's... I've used SoftwareSerial on everything from a 328 to a tiny 85 with no problems..
I have on my desk now a tiny 85 reading a DHT22 and reporting via BT/SoftwareSerial... after I got it working which was just connecting the devices together.. I looked on the Forum and posted about it... I was told that it couldn't work... I guess my $150.00 Saleae Logic was lying to me... along with the serial monitor in the IDE. It works just fine and the code is about 6K long.

Doc

Would be nice to see some actual source code that is known to work in general, rather than just people saying it works. Hint, hint. Eg, the trivial example code in reply #2 is flakey.

I suspect it can be made to work, as long as there are no other interrupts or real-time tasks occurring.

I'm trying to remember how I had the XBee wired to my UNO. My shield is the official Arduino Wireless SD Shield which seems to connect the XBee to pind D0 and D1 (with a switch to swap RX and TX). I apparently used pins 10 and 11 for the XBee. The pins of my shield don't appear bent, so I may have used jumpers to connect the shield instead of plugging the shield into my UNO like normal.

Yes, the sketch in #2 can be flakey. I mentioned some of the effects in this thread: Hardware Serial buffer issues - Programming Questions - Arduino Forum Individual characters were fine, but data bursts had trouble until I reduced the HW serial port closer to the SW serial port. My theory is a result of only one interrupt being able to be serviced at a time. While the interrupt at the lower baudrate is being serviced, if more than one interrupt at the higher baudrate come in, you have just lost the opportunity to react to that first interrupt from the faster baudrate, so you loose data.

My theory is a result of only one interrupt being able to be serviced at a time. While the interrupt at the lower baudrate is being serviced, if more than one interrupt at the higher baudrate come in, you have just lost the opportunity to react to that first interrupt from the faster baudrate, so you loose data.

That's my take on it, too, except this pertains to softserial. Hardware serial will do fine, as long as you read the input character before the next one is received and a new UART interrupt is generated. OTOH, softserial has to time every individual bit being received, and if softserial stalls the processor for long periods, the whole thing grinds to a halt. Interrupts only work properly if their service routines are efficient, not cycle-hogs.

As I've mentioned elsewhere, I've gotten this sort of thing to work in the past on PICs, but I wrote the ISRs in assembler, and combined and fine-tuned them so the software interrupt could take precedence (within a couple of clock cycles) even if the hardware interrupt were currently being serviced. I doubt this will work with Arduino without some fullscale changes. Would likely have to combine with all other possible ISRs too. Not feasible, I think. Much easier just to use a cpu with more than one UART.

oric_dan:
Would be nice to see some actual source code that is known to work in general, rather than just people saying it works. Hint, hint. Eg, the trivial example code in reply #2 is flakey.

I suspect it can be made to work, as long as there are no other interrupts or real-time tasks occurring.

Sigh, I guess we're not gonna see any actual evidence of it actually working, sigh. Some of us will just have to remain in the "unlucky" group, sigh.