Go Down

Topic: software serial limitations (Read 398 times) previous topic - next topic

gcjr

The Two Port Receive example you quoted, shows two Software serial ports defined, with each being read in turn using port.listen(). That you switch between the Software serial instances in this way should make clear that the two ports cannot be used simultaneously.
which version of SoftwareSerial do you use?

isn't that what the example code (posted below from TwoPortReceive) is doing?   it executes listen() on one port and checks available() then does the same for the the other port.

of course this a do nothing example.   the limited delay in listening between each port is when processing a byte from the other port.

it's not clear to me how often and when specifically listen() needs to run.

Code: [Select]
void loop() {
  // By default, the last intialized port is listening.
  // when you want to listen on a port, explicitly select it:
  portOne.listen();
  Serial.println("Data from port one:");
  // while there is data coming in, read it
  // and send to the hardware serial port:
  while (portOne.available() > 0) {
    char inByte = portOne.read();
    Serial.write(inByte);
  }

  // blank line to separate data from the two ports:
  Serial.println();

  // Now listen on the second port
  portTwo.listen();
  // while there is data coming in, read it
  // and send to the hardware serial port:
  Serial.println("Data from port two:");
  while (portTwo.available() > 0) {
    char inByte = portTwo.read();
    Serial.write(inByte);
  }

  // blank line to separate data from the two ports:
  Serial.println();
}
greg - somerset, nj

gcjr

I think we can be quite sure that nobody is using it like you do with any success,
is that because SoftwareSerial is too limited for such an application?

and nobody else has bothered to look at your code, which is mostly junk as far as comms is concerned.
got the interface working in a couple hours using a Mega

And while you are at it, you might consider including the software serial library,
which version of the library do you use?

Further, if you can't work out whether you have a Uno or a Mega in your hand,
i want to use the same code on either an Uno or Mega.   The code determines the hardware using a defined macro.

Code: [Select]
#if defined __AVR_ATmega328P__      // Uno
greg - somerset, nj

Nick_Pyner

is that because SoftwareSerial is too limited for such an application?
In your case, no. I'm afraid it is because you don't know what you are doing.
Quote
got the interface working in a couple hours using a Mega
Good. I guess you now see the advantage of the Mega
Quote
which version of the library do you use?
I don't use software serial ever. Mostly I use a Mega, but I don't use it on a Uno or my Pro Mini either. There is no need. There certainly are cases where you have no option but to use software serial, but it is more rare than you would think, and when you do it is under sufferance. Quite often software serial is just a refuge for the lazy and incompetent.
Quote
i want to use the same code on either an Uno or Mega.   The code determines the hardware using a defined macro.

Code: [Select]
#if defined __AVR_ATmega328P__      // Uno
That sounds like a particularly dumb idea. God only knows what the motivation for that is and, if it means you are obliged to use software serial on a Mega, that would be code you should definitely not show your mother. Most code that will run on a Uno will run essentially verbatim on a Mega, but one of the major differences, thereby requiring different code, is serial communication.

gcjr

I don't use software serial ever.
wow!  ??


God only knows what the motivation for that is and, if it means you are obliged to use software serial on a Mega, that would be code you should definitely not show your mother.
the purpose is not to use SoftwareSerial unnecessarily on a Mega but be able switch back to the Mega to verify that any changes don't break the code.

it's pretty common in industry.  i guess you've never had to write code professionally that needs to operate on different types of hardware.   I've had to work on RF code that supports different RF hardware that operates on different bands with various restrictions
greg - somerset, nj

Nick_Pyner

wow!  ??
No wow, just no need. My serial peripheral adventures involve just one Bluetooth connected at 115200. In that situation, there is never ever a need to use software serial, and it wouldn't work at that speed anyway.
Quote
the purpose is not to use SoftwareSerial unnecessarily on a Mega but be able switch back to the Mega to verify that any changes don't break the code.
Whatever floats your boat.... Don't bother explaining why you wouldn't use another Uno to do that. I assume no RTC or SD card is involved in your exercise, and you confine software serial to pins that work on a Mega.

UKHeliBob

Quote
My serial peripheral adventures involve just one Bluetooth connected at 115200In that situation, there is never ever a need to use software serial
What do you do if you are using hardware Serial to connect to a peripheral such as a Bluetooth adaptor and need to print messages for debugging or other purposes ?
Please do not send me PMs asking for help.  Post in the forum then everyone will benefit from seeing the questions and answers.

Nick_Pyner

#21
May 24, 2020, 06:17 pm Last Edit: May 25, 2020, 04:38 am by Nick_Pyner
What do you do if you are using hardware Serial to connect to a peripheral such as a Bluetooth adaptor and need to print messages for debugging or other purposes ?
I don't, the data is from sensors, and any messages go out via Bluetooth - as one would expect.. The debugging is done through hardware serial in the normal manner with Bluetooth disconnected. Bluetooth on software serial is more a hinderance than a help in debugging, and anyway, once you have the need to connect bluetooth, at 115200, the debugging is done.

Go Up