I'm not sure if its just the terminology, but the DMA code is not a class, its just a series of functions.
Well, crap. I should probably not write in the forum after dinner and 3 beers.
What I was thinking when I posted my flawed logic was along the way that Limor handles her GPS code by capturing SoftwareSerial. In the case of the Maple-centric SoftwareSerial, it looks like:
SoftwareSerial::SoftwareSerial(uint8_t receivePin, uint8_t transmitPin, bool inverse_logic /* = false */)
{
if (receivePin == 0 && transmitPin == 1) {
port = &Serial3;
} else if (receivePin == 8 && transmitPin == 9) {
port = &Serial2;
} else if (receivePin == 25 && transmitPin == 26) {
port = &Serial1;
} else {
port = NULL;
}
}
SoftwareSerial::~SoftwareSerial()
{
end();
}
Then in my main sketch, I pass the GPS object the address:
// create mySerial object for exclusive use by Adafruit_GPS
SoftwareSerial mySerial(0, 1); // Rx Tx : Connect the GPS TX (transmit) pin 0 (NC on pin1)
Adafruit_GPS GPS(&mySerial); // create GPS object
The user code can detect when the 1st buffer has filled from serial interrupts and move on while the 2nd buffer is being loaded...
char c = GPS.read(); // read data from the GPS and check for full sentence
if (GPS.newNMEAreceived()) {
if (!GPS.parse(GPS.lastNMEA())); // sets the newNMEAreceived() flag: return; no longer used
}
...
But, honestly, sticking in more functionality as functions and implementing a callback is Ok by me. It needs to work with old Maple examples and it needs to cover the new uses.
Ray