Simultanous read and read/write on two serial connections

Question

At the moment I'm using two softserials to connect to a GPS and an GSM module.

It seems not possible to have two open software-serials. So I was looking for an solution

After the initial-setup, the GPS module is only needed to be read from; while the GSM module needs to be bidirectional. So:

GPS > listen only
GSM > listen and write

Now I came across the GPS library from Adafruit, which uses an interrupt to receive data. Is this instead of a software serial. Or do I again run into the limitation?

An other solution might be to use the D0 and D1 to attach eg the GPS module. But than I won't be able to see the debug messages in my serial monitor. Is that correct?

Sorry in advance for these n00b questions. But I'm frustrated the things dont work as I want :)

edit

• This is the adafruit GPS board.
• And the board with whom it is connected: Gboard
• The Sim900 is connected to D2/D3 and the GPS is connected to A2/A3.
• D0/D1 are connected to a FTDI breakout board, which is plugged into my USB.

• jippie: About the debug massages when using D0/D1, you'll at least have to provide the spec sheet and circuit diagram for the GPS module and Arduino Uno.
• stUrb: I update the OP with the boards en connections I use.
• gwideman: In case you weren't aware, Mega2560 has four UARTS, which could make life easier.
• stUrb: @gwideman That's a better solution, but for now I have to work with the Gboard. Next version of this device is going to be with at least two UARTS and separeted sim900 and GPS module.

Answer 1

So you want three serial ports: upload/debug (hardware serial), GSM (software serial) and GPS (software serial). Unfortunately, two SoftSerial ports are not going to work at the same time (or even send and receive at the same time on one SoftSerial port). In your current configuration it's not going to be solvable.

If you can wire the GPS to different pins, there are a couple of options to try. One would be to disconnect the FTDI when running (reconnect to program) so you can use the hardware serial port for either GSM or GPS (probably the former). If you need some print statements for debugging, you could use SoftSerial or AltSoftSerial (and connect the FTDI differently). Reconnecting between upload/debug and run phases would be a pain but it comes with the platform you are choosing and the number of serial ports you need; you might be able to wire up a DPDT switch externally to do the switching rapidly.

The other and perhaps easier approach would be to connect the GPS to pins 8 and 9, and use AltSoftSerial for the GPS; as long as your baud rate to the GSM is high enough that might work. (SoftSerial for the GSM will turn off interrupts for excessive periods of time at low baud rates). Using AltSoftSerial makes use of the single 16 bit timer (Timer1), so this won't work if you use any other library which requires Timer1.

• stUrb: All right! at te moment I am bound to this board/setup, but in the future I'll use the bigger chip with 4 UARTS. For the time being I'm going to use the HWs for the GPS and use the switch-technique. Because after the setup works, I won't be needing the debug messages as there won't be a computer connected to it.
• stUrb: Am I right that I would be able to use both HW an SS connections at the same time?
• Zeph: Yes, you can use both, with some caveats. The HW serial library could miss a received byte if interrupts are off too long; and the SS library inhibits interrupts while timing the bits. If the HW receive rate is much faster than the SS rate, this could be a problem.
• stUrb: Both are 9600 Baud, so that wouldn't be a problem. In the meantime I got it working with the GSM on SS and the GPS on the HWS; it was easier to use the library for the GPS on the HWS.

Answer 2

Adafruit_GPS.h (line 132-), which is included in Adafruit_GPS.cpp (line 13) refers in turn to the SoftwareSerial library on AVR platform and Arduino IDE version> 100.

#ifdef __AVR__
#if ARDUINO >= 100
 SoftwareSerial *gpsSwSerial;
#else
 NewSoftSerial *gpsSwSerial;
#endif
#endif

This means it uses software serial on an Uno. It also means if your problem is indeed with Software Serial, that is the library to check for bugs / updates or commit a patch to.

• stUrb: So the only solution might be to use the hardware RX/TX, with the downside being not able to see the debug messages.
• jippie: @stUrb Depends on the hardware I guess. I am not familiar with the GPS module.

Answer 3

The solution to your problem might be to combine AltSoftSerial with SoftwareSerial. I haven't done it myself (yet) but I have the same problem as yours.

SoftwareSerial does busy wait for counting time between two bits, so it can't read simultaneously from two ports (some bits could be lost).

AltSoftSerial was created to overcome some of these limitations. It's interrupt-based. Unfortunately, it's harwired for one port (and pins 7 & 8). My understanding is that you can combine it with SoftwareSerial to read from 2 simultaneous ports. Pins 7 & 8 aren't what you need, from the description of the GBoard, but AltSoftSerial is open source, you can change the pin numbers (and possibly some masks) in the source code.

Hope this helps.

Answer 4

I've done exactly this. The secret sauce for me was the SoftwareSerial.listen().

Before running your GSM commands you have to make sure the GSM module's SoftwareSerial port is "listening". Then when you're done you have to listen() again to the GPS.

This is, of course, not terribly efficient, while the GSM port is listening any GPS data will be lost, but at least in my case the impact was negligible.

My code is here: https://github.com/lectroidmarc/gsm-tracker

As an aside, I have also considered plugging the GPS into the UART and running debug messages to a SoftwareSerial serial port, to be monitored during testing with another Arduino. I'm just not sure the benefit would be there.

Answer 5

There is a working example of this, using the Adafruit Ultimate GPS, and the Arduino GSM shield http://www.mallinson-electrical.com/shop/gpsgsm I hope this helps

• sachleen: Generally it's not a good idea to post link-only answers. If the link goes down or moves, the answer becomes useless. Please expand by adding some more information (code sample) to the answer.