Arduino goodness, libraries, stream and serial ports.


I'm writing a library that parses TSIP packets employed by some GPS units.

For libraries requiring a serial port, I've read that it is recommended to utilize the Stream class vs. specific serial port classes. It certainly does simplify using the library and works fine. However, it is also recommended to avoid using pointers in public accessible library interfaces... and I have so far failed to uncover a way to achieve that with using serial ports.

Some libraries provide a second method for passing initialized hardware serial port instances, passing an integer representing the hardware serial port number, then using #ifdefs to "detect" what HW serial ports are available on a system. That method also works, but I've had problems with that on Due devices. (note: there also seems to be several different #defines for HW serial ports and I am confused a bit there too)

My C++ is pretty rusty, and I probably have missed something. Is there a recommended method or construct that would meet the "no pointers" design principle for this use case?

Thanks in advance, Dan

I would suggest using normal Serial code to receive the data, and writing the library only to process/interpret/decode the data packets after it has been received.

That's what tinyGPS does and that's what my own code for GPS NMEA and other packet data does, also.

There is nothing wrong with using pointers, if you actually know how to use them.

Since the third method of function arguments was invented, there is a lot less necessity to use pointers. I suggest you use that.

@michinyon - thank you for the response. I’m not sure I follow on what you mean by “normal Serial code” or “third method of function arguments”. The library I am writing requires that users pass a serial port instance to it, for sending data. The start of the receive chain is in the .ino sketch.

The issue I am wrestling with is how to pass an instance of a Serial class (for example, SoftwareSerial or HardwareSerial) to the library without requiring the library user to “know” how to the address of operator.