Hacks to get Adafruit GPS library working on Uno32

Created Sat, 29 Dec 2012 18:48:15 +0000 by diemkae

diemkae

Sat, 29 Dec 2012 18:48:15 +0000

Here's what I did to get the Adafruit GPS library working with both hardware & software Serial...

HowTo use Adafruit_GPS library:

https://github.com/adafruit/Adafruit-GPS-Library

with a mpide/Uno32 (on a Fedora Linux system):

1 - Copy the ChipKit SoftwareSerial library to your ~/Arduino%/libraries directory (user libraries override ChipKit distro libraries - which seem to contain 2 different instances of a SoftwareSerial which does not have an "available" method (like the Arduino SoftwareSerial library) which is used by the Adafruit GPS library and some examples. FWIW, the ChipKit distro HardwareSerial library does provide the "available" method.

2 - To keep the Adafruit GPS library and others that access the "standard" <Serial>.available() method happy, add a dummy/trivial "available" method to the SoftwareSerial.cpp file:

int SoftwareSerial::available()
{
  return true;
}

and a prototype to the public: section in SoftwareSerial.h:

  public:
      SoftwareSerial(uint8_t, uint8_t);
      void begin(long);
      int available();
      int read();
       void pr ...

in your ~/Arduino%/libraries/SoftwareSerial directory.

3 - In that same directory, create a symlink for NewSoftSerial.h to SoftwareSerial.h:

   ln -s SoftwareSerial.h NewSoftSerial.h

to satisfy code that tests the value of ARDUINO and includes
either SoftwareSerial.h or NewSoftSerial.h - my goal here is to
require few if any changes to the Adafruit GPS library code and exisitng
sketches.

4 - In sketches that use (or include) code|headers that reference SoftwareSerial.h or NewSoftSerial.h, need to add

   #include <SoftwareSerial.h>

at the top, or at least ahead of any #includes that attempt
to include SoftwareSerial.h or NewSoftserial.h otherwise mpide
won't find the (nested?) include file(s) ...

With these tweaks, sketches using the Adafruit GPS library compiles and runs with hardware serial (pins 39,40) and software serial (pins 7,8).

diemkae

Fri, 04 Jan 2013 17:13:29 +0000

This post may have been too optimistic in its assertion that the Digilent SoftwareSerial library "works".

At best, it seems to work only when no "work" is attempted between chars. It seems that the reason there is no "available" method may be because it does not buffer any chars, hence there is little one can do between chars, even at 80MHz.

Running the TinyGPS "test_with_gps_device" example, having modfied the feedgps() function to accomodate the Digilent distro SoftwareSerial library (by David Mellis), with pins 7,8 connected to a Skylabs SKM53 GPS device, thusly:

static bool feedgps() { char c; while ((c = nss.read()) != -1) { // The Mellis read method returns -1 when no data is available if (gps.encode(c) ) return true; } return false; }

the data displayed (see attached log - mellisSS.log) indicates that roughtly half of the GPS sentences received fail the checksum test, probably due to lost chars, despite the design of the example code to read/drain the GPS serial data [buffer] between every print operation (see the various print functions, each of which calls feedgps() at the end), and using Serial.begin(115200); to print the data as fast as possible.

In contrast, this same code posts NO checksum failures when using the Hardware Serial library with the same SKM53 device connected to pins 39,40, or on an Arduino Uno using the Arduino SoftwareSerial library.

FWIW, the Digilent/Mellis HardwareSerial library implements a 128 byte RX_BUFFER_SIZE, and the Arduino SoftwareSerial library (by Mikal Hart) implements a 64 byte (SS_MAX_RX_BUFF) buffer to hold incoming chars, which seems to be sufficent for this example code to "work" without losing incoming characters on an Ardunio Uno running at 16MHz.

I believe that if Mr Mellis could implement an RX_BUFFER of 64 bytes or more, and an "available" method, it would both work better, and be more compatible with his HardwareSerial implementation. It's really nice to be able to switch between hardware & software serial i/o without having to fiddle with the code!

Dave