Arduino Pro Mini with multiple SoftwareSerial objects

Hi all,

I've a "little" problem with a couple of devices on a Arduino Pro Mini, but I'm new in Arduino world so, forgive me my nonsense.

I use two devices (Sim800L GSM and Adafruit GPS shields) throught 2 SoftwareSerial objects; individually they works fine, but together there are a lot of problems to get messages.

I tried to put the ports in listen() individually, but without great results; from Arduino documentation I understood that there is just one serial buffer shared among SoftwareSerial objects; so, when GPS starts to push its messages, GSM data are continuously overwritten.

I did a lot of tries, but I did not obtained any results.

I thought to solve the issue in a hardway way, with a little relay, using only a pin on arduino and switching the tx when needed but, honestly, I don't like the idea.

Instead, I'd like to solve it in sw way, but I dont know how.

Any ideas? Anyone already saw this problem?

Thanks to all in advance,

Using more than one instance of SoftwareSerial is troublesome as you have discovered. The listen() method provides a partial solution but data received on the pins not currently listening will be lost as there is no flow control.

Can you not use the normal serial interface for one of the devices ?

You mean using Serial object for one device and SoftwareSerial for the other one?

Yes, I could do it, but in this case I wouldn't know how to access the board in development phase (I'm using a FTDI USB<->RS232 interface).

Can I access the Pro Mini in other ways?

Thanks a lot,

Can I access the Pro Mini in other ways?

You can put it in a drawer and get a Mega.

Hi Paul.

You can put it in a drawer and get a Mega.

No, I can't; there is a reason if I'm using a Pro Mini: its size.

Hi Paul.

No, I can't; there is a reason if I'm using a Pro Mini: its size.

For developing and testing, size is usually not an issue.

I think it is possible to do a conditional compilation based on the used board. If it's a Mega, use software serial and serial1 (serial will be available for upload and debugging), if it's a pro micro, use software serial and serial.

Hi sterretje,'re right. I could develop on a board and then applying all to another one.

But sound very strange the absence of workarounds :sob:

So, no ways to do that via software?

Thanks again to all,

So, no ways to do that via software?

Can you listen to the radio and the TV at the same time? No. But you and your brother could listen to one device each. And, a computer could listen to both, independently, and record the data from each one, independently, so you could listen to both recordings later.

The Arduino can't listen to two software serial ports at the same time, either. You need to either get it a brother so each can listen to one device, or you need to replace it with something that has more than one hardware serial port, or you need to give up any hope of debugging the program.

It is your choice. Persisting in the delusion that you can use multiple SoftwareSerial instances to listen at the same time is NOT an option.

Try a '1284P board with 2 hardware serial ports.
I offer them in several form factors. Example:

with lots of extra ground pins, as there never seems to be enough.
Or DIP sized, in case you smoke the processor

Thanks a lot to all for the interest and the suggestions.
I understood the problem, but I need to work around it.

For now I'll try to get a Mega (thanks Paul & sterretje for the suggestion)

In the mean time, I'd like to take a look at the 1284P board suggested by CrossRoads.

Thanks to all,

to clarify: combination of one "hardware"serial and one software serial is possible without problems with listen function? I want connect hardwareserial to USB and softwareserial for communication with BT module.

I don't know what the listen function is, but it is quite practical to use hardware serial and one software serial on a Uno etc., so long as you understand the limitations of software serial. These are mainly to do with speed.

  1. Software serial clogs up Uno's other operations and slows it down.
  2. It is unreliable at speeds over 38400 baud.
  3. It takes up memory space that may be better employed for more useful things.