Error w/ Adafruit GPS Library & GSM Library together

[Dietger]

Sorry, can't help you on the interrupt-driven question. Just very basic programming for me is hard enough....

[adafruit_support_rick]

Do you have a link to this AltSoftSerial library?

[Dietger]

I downloaded it via this page http://www.pjrc.com/teensy/td_libs_AltSoftSerial.html.

When you have found out how AltSoftSerial does it, can you please explain it? Thanks


PS how long does it normaly takes for the GPS unit to get sat fix? sometimes i get no fix / sometimes it takes a couple of hours... It was also like this before the AltSoftSerial change in the adafruit library.

[adafruit_support_rick]

The reason AltSoftSerial works is that it doesn't depend on the pin-change interrupts used by SoftwareSerial. The problem with the GSM driver is that it uses the same pin-change interrupts as SoftwareSerial, so there's a conflict between the two.

(The GSM driver is actually a slightly modified version of SoftwareSerial. I don't know why Arduino did it that way instead of coming up with a way to use SoftwareSerial directly, which would have prevented this problem).

Instead of pin-change interrupts, AltSoftSerial uses a system of timer interrupts to clock the serial data in and out. It's actually a much better way to do it, but the trade-off is in flexibility. AltSoftSerial only works with certain pins, and it appears that you can only have one AltSoftSerial port.

[Dietger]

ok thank you for your explaination.

Yes the drawback is the use of fixed pins but for my current project it doesn't matter.

[paulstoffregen]

I'm the author of AltSoftSerial.

If you have an AVR chip with more than one 16 bit timer, with some fiddling you could make multiple copies of AltSoftSerial which each use a different timer. Arduino Uno only has 1 usable timer, but most other boards have 2 or more.

My main motivation for writing AltSoftSerial was improving the terrible interrupt latency problems of SoftwareSerial. Interrupt latency is the time between the hardware condition that triggers an interrupt and when the interrupt code actually begins running. There are 2 important issues to understand about interrupt latency... #1: libraries and some programs create interrupt latency, depending on how long their interrupt service routines execute (blocking other interrupts) and how long they disable interrupts while accessing data, and #2: different libraries vary in how much interrupt latency they can tolerate from other libraries.

For example, the millis timekeeping creates several microseconds of interrupt latency, because that's how long it takes to update the multiple variables it increments. It needs to run every 1.024 milliseconds. So it can tolerate about 1ms of latency before the timer sets the flag again, before the interrupt was able to execute the code to update those counters. That's pretty good... you could say millis() plays well with others: it creates a small amount of latency and can tolerate quite a lot.

SoftwareSerial is pretty much the opposite. It creates massive interrupt latency. It needs to disable interrupts for all 10 bit times. If you're using a NEMA format GPS at 4800 baud, interrupts are disabled for 2.08 ms. That's BAD. Even millis() will lose track of elapsed time. SoftwareSerial causes nearly all other interrupt-using libraries to have a lot of trouble.

SoftwareSerial is also pretty sensitive to interrupt latency created by other libraries. For incoming data, a pin change interrupt detects the start bit. If the device sending the data has a very accurate baud rate, then it's ok to have some interrupt latency. The result is SoftwareSerial will simply sample each incoming bit later, with still within each bit time. But if the sending is transmitting a bit faster, then the sampling of each bit will be a little farther in each bit time. Normally serial communication can handle about 2% baud rate errors. Many devices (including Arduino) send baud rates with some error, because it's usually ok to do so. How well SoftwareSerial can handle these normal baud rate mismatches depends entirely on the interrupt latency from other code.

Another source of interrupt latency is from Arduino's normal Serial. Presumably all uses of SoftwareSerial are using Serial, but whether they operate simultaneously is the issue. Arduino's hardware serial interrupt latency is gradually getting better (still it's about half the speed of my serial code in Teensyduino). Just using Serial and SoftwareSerial simultaneously can cause data loss or corruption. The problems tend to occur randomly and infrequently, than they're extremely difficult to diagnose. The errors occur when the Serial interrupt delays SoftwareSerial just a bit too much to receive a byte properly (resulting in corrupted incoming data), or when SoftwareSerial is used at much slower baud rates and keeps Serial's interrupt from running for so long that 2 bytes arrive and the hardware can't begin receiving a 3rd byte (resulting in missing incoming data).

I designed AltSoftSerial to be able to tolerate almost 1 full bit of interrupt latency from other libraries. The output waveform timing and input sampling is all precisely controlled by the timer hardware, so as long as AltSoftSerial's interrupt gets to run anywhere within one cycle of whatever baud rate is used, you get very reliable operation. AltSoftSerial also creates very little interrupt latency for other libraries. The interrupt routines are designed to execute very quickly. They never wait, like SoftwareSerial does. The main program also is designed to access the buffers quickly, so minimal interrupt latency is created.

If there's one take-away from this lengthy message, SoftwareSerial is particularly terrible with slower baud rates. Most people intuitively believe a software emulated serial port ought to work better at slower speeds. That is true of AltSoftSerial. But with SoftwareSerial, the slower your baud rate, the more interrupt latency it creates for other libraries, even to the point where millis() won't keep accurate time and ordinary Serial can miss incoming data!

[adafruit_support_rick]

Paul - Thanks for writing that library! I was just telling Bill about it yesterday. Before Dietger pointed it out, I was totally unaware of it.
I've never liked SoftwareSerial, for all the reasons you mention. I also think it's the first example of input capture I've seen in the wild...

[paulstoffregen]

Yeah, it's been difficult to get the word out about AltSoftSerial. It's unfortunate, because I know there are a LOT of Arduino projects on boards like Arduino Uno using a GPS, bluetooth module or other serial device where things fail intermittently and nobody can figure out why.

Input capture has been published for the more traditional use in my FreqMeasure library and Martin Nawrath's FreqPeriod library.

http://www.pjrc.com/teensy/td_libs_FreqMeasure.html
http://interface.khm.de/index.php/lab/e ... t-library/

It is true that input capture is one of the lesser used and generally not widely known features in the Arduino world.

Someday I'm going to try some ideas I have for emulating input capture using pin change events to trigger DMA channels that capture a free-running timer. At least in theory, it should be possible to build all sorts of interesting waveform input parsing for a variety of protocols, without tying up timer channels needed by PWM or other libraries, and without even much in the way of interrupt overhead, since the DMA engine can move data around on the buses without any CPU activity. Obviously this is impossible on normal AVR, but these new ARM processors with powerful DMA engines really open up a lot of amazing possibilities.

Over the next couple years, I'm going to leverage DMA to create libraries that seem impossible in the context of traditional microcontrollers....

[adafruit_support_rick]

I discovered input capture when I was coding an IR receiver/decoder. It a handy thing.

I used DMA back in the LSI-11 days, but I'd almost forgotten about it since then. Nice to see it making a comeback in MCUs

[mldemarie]

The first test show the problem is solved.

I used some info from following thread on the Arduino forums : http://forum.arduino.cc/index.php?PHPSE ... c=173459.0

Someone suggest AltSoftSerial instead of SoftwareSerial and change the GSM library. At first AltSoftSerial doesn't do the trick. Also I had a look at the gsm library but I'm not that good in programming so changing that one was a bit over my head.

Using AltSoftSerial only in the sketch still brings up the errors while compiling. In your Adafruit_gps library SoftwareSerial is also used/loaded and that one gives also problems. Replaced SoftwareSerial with AltSoftSerial, recompiled sketch and seems ok. First test give good results.

Hi guys,

I'm currently working on a project that also requires the use of the GSM ilbrary and adafruit GPS library together. I've read through all these post and their links, but i'm still having trouble getting rid of the errors (exactly the same as posted in other replies about the vectors clashing).
One post below seems to suggest that using the AltSoftSerial library appropriately can solve the problem. Can anyone specify exactly where to make the changes? Are the AltSoftSerial changes made only in the sketch, only in the GSM library or both? Thanks.

[adafruit_support_rick]

AltSoftSerial will fix the problem. You have to modify both your sketch and the Adafruit_GPS library to include AltSoftSerial.h instead of SoftwareSerial.h.

Download AltSoftSerial from here, and unzip it into your libraries folder: http://www.pjrc.com/teensy/td_libs_AltSoftSerial.html

Next, modify the Adafruit_GPS library. In the Adafruit_GPS library folder are two files, Adafruit_GPS.h and Adafruit_GPS.cpp. In both files, replace every instance of the word "SoftwareSerial" with "AltSoftSerial"

In your sketch, also replace every instance of the word "SoftwareSerial" with "AltSoftSerial". You also have to change the declaration of the AltSoftSerial object to remove the specifications of the Rx and Tx pins:

Code: Select all

//SoftwareSerial mySerial(3, 2);  //not using SoftwareSerial anymore
AltSoftSerial mySerial();  //AltSoftSerial ALWAYS uses the following pins:
                           //
                           // Board          Transmit  Receive   PWM Unusable
                           // -----          --------  -------   ------------
                           // Teensy 2.0         9        10       (none)
                           // Teensy++ 2.0      25         4       26, 27
                           // Arduino Uno        9         8         10
                           // Arduino Mega      46        48       44, 45
                           // Wiring-S           5         6          4
                           // Sanguino          13        14         12

Adafruit_GPS GPS(&mySerial);

If you are using an Ultimate GPS breakout, connect RX to Digital 9, and Tx to Digital 8.
If you are using an Ultimate GPS Shield, then you will have to cut the trace between Rx and Digital 7, and jumper Rx to Digital 9:

GPS_AltSoftSerial_Jumper.png (145.43 KiB) Viewed 4182 times

[mldemarie]

Hi Again,

Alright so i've been going through the steps for a couple hours and checking my work, here is what i end up with.

In the Adafruit_GPS.h library i did a search and replace all and replaced 5 instances of SoftwareSerial with AltSoftSerial. In the Adafruit_GPS.cpp file i did the same thing and replaced 2 instances.

For the next step where i modify my sketch i have the following:

Code: Select all

// Date Modiifed: 8/15/2013
//--------------------------------------------------------------------------------
// include libraries and definitions
#include <GSM.h>                  // include the GSM library
#include <EEPROM.h>               // include the Memory library
#define PINNUMBER ""              // PIN Number for the SIM


#include <Adafruit_GPS.h>         
#include <AltSoftSerial.h>
AltSoftSerial mySerial();
Adafruit_GPS GPS(&mySerial);

// initialize the library instances
GSM gsmAccess;
GSMVoiceCall vcs;
GSM_SMS sms;
//--------------------------------------------------------------------------------
void setup() {
  //--------------------------------------------------
  // GSM setup
  Serial.println("Please wait as we obtain GSM reception");
  boolean notConnected = true;                 // connection state
  while(notConnected) {                        // Start GSM connection
    if(gsmAccess.begin(PINNUMBER)==GSM_READY)  notConnected = false;
    else                                       Serial.println("Not connected");
    delay(1000);
  }
  Serial.println("GSM initialized");
  // GPS setup
  GPS.begin(9600);
  GPS.sendCommand(PMTK_SET_NMEA_OUTPUT_RMCONLY);
  GPS.sendCommand(PMTK_SET_NMEA_UPDATE_1HZ);
  GPS.sendCommand(PGCMD_ANTENNA);
  Serial.println("GPS initialized");
}
//--------------------------------------------------------------------------------
void loop() {
}

However i received the following error for the line "Adafruit_GPS GPS(&mySerial)"

Code: Select all

XXX_rev1:14: error: no matching function for call to 'Adafruit_GPS::Adafruit_GPS(AltSoftSerial (*)())'
C:\Program Files (x86)\Arduino\libraries\Adafruit_GPS/Adafruit_GPS.h:92: note: candidates are: Adafruit_GPS::Adafruit_GPS(HardwareSerial*)
C:\Program Files (x86)\Arduino\libraries\Adafruit_GPS/Adafruit_GPS.h:88: note:                 Adafruit_GPS::Adafruit_GPS(AltSoftSerial*)
C:\Program Files (x86)\Arduino\libraries\Adafruit_GPS/Adafruit_GPS.h:83: note:                 Adafruit_GPS::Adafruit_GPS(const Adafruit_GPS&)

Based on the error messages i decided to try something i'll run by you. Instead of using the two lines:

Code: Select all

AltSoftSerial mySerial();
Adafruit_GPS GPS(&mySerial);

I replaced them both with one line:

Code: Select all

Adafruit_GPS GPS(AltSoftSerial*);

With this line, i do not receive any error messages in this area of the sketch, but instead when i try to use any of the Adafruit_GPS class functions (begin, sendCommand, ...) i receive an error telling me that GPS is of non-class type Adafruit_GPS.

Code: Select all

XXX_rev1.ino: In function 'void setup()':
XXX_rev1:62: error: request for member 'begin' in 'GPS', which is of non-class type 'Adafruit_GPS ()(AltSoftSerial*)'
XXX_rev1:63: error: request for member 'sendCommand' in 'GPS', which is of non-class type 'Adafruit_GPS ()(AltSoftSerial*)'

Do you have any thoughts you notice right away ? Thanks for this btw, your previous post was extremely helpful.

[paulstoffregen]

For the next step where i modify my sketch i have the following:

Code: Select all

#include <Adafruit_GPS.h>         
#include <AltSoftSerial.h>
AltSoftSerial mySerial();
Adafruit_GPS GPS(&mySerial);

Try removing the parens from "mySerial".

In other words, try changing this:

Code: Select all

AltSoftSerial mySerial();

To this:

Code: Select all

AltSoftSerial mySerial;

I must confess, this is only a casual guess (I didn't actually try it), but I have a hunch it might solve your troubles. Of course, this suggestion is with the version where you replaced every "SoftwareSerial" with "AltSoftSerial", but before the edit the redefine the Adafruit library constructor.

[adafruit_support_rick]

Paul - removing the parens from mySerial does indeed solve the problem.
Trying to figure out why it works, and why mySerial() doesn't is making my brain hurt.
Care to explain?

@midemarie - I've got the modified version of the parsing sketch working with the modified Adafruit_GPS library. If you follow Paul's advice, you ought to be good to go with the GSM card.

[mldemarie]

Thanks to both of you. After removing the parentheses my code compiles without error.