Added overloaded encode function which can accept a character array

[madhuryagupta]

Existing encode function accepts 1 character input at a time. As a result, most examples using this library include a statement such as this

void loop(void)
{
  gps.encode( Serial2.read() );
  ...
}

Which reads from the GPS sensor serial interface, once character at a time.

Although, reading multiple characters from the GPS sensor serial interface at once is significantly more efficient. Therefore, adding an encode function which can take a collection of characters as input is very helpful. This pull request adds that overloaded encode function to the TinyGPSPlus library.

Following is a snippet from my arduino_ide project which uses the modified TinyGPSPlus library

#define SER_READ_BUF_SIZE 256
char gSerBuf[SER_READ_BUF_SIZE];

void loop(void)
{
  size_t serBufReadLen = Serial2.read( gSerBuf, SER_READ_BUF_SIZE );
  if( serBufReadLen > 0 && serBufReadLen < SER_READ_BUF_SIZE )
    gps.encode( gSerBuf, gSerBufReadLen );
  ...

  delay(10);
}

After this change, the code runs significantly faster and more efficiently.

[svdrummer]

I do this with my other programs. I love this proposal. Whilst it could be argued that using the old arduino micro is not that common any more, the extra ram for the buffer would not be a problem for modern micros such as ESP32 etc.

[TD-er]

I do this with my other programs. I love this proposal. Whilst it could be argued that using the old arduino micro is not that common any more, the extra ram for the buffer would not be a problem for modern micros such as ESP32 etc.

I wonder if this is actually a speed improvement over simply checking the available() count and loop over this.

Something like this:

int available = Serial.available();
while (available > 0) {
  gps.encode(Serial.read());
  --available;
}

[madhuryagupta]

I wonder if this is actually a speed improvement over simply checking the available() count and loop over this.

Something like this:

int available = Serial.available();
while (available > 0) {
  gps.encode(Serial.read());
  --available;
}

This would certainly use less memory since it does not require any extra buffer space to be allocated.

Although, this suggestion still has a disadvantage of reading from the serial interface, once character at a time. Bulk reads from the serial interface are significantly faster since they eliminate numerous unnecessary function calls (one more more function calls per character) which can easily be replaced by just a memcpy for all available characters from UART buffer into the buffer we create, which is what happens in this change.

The speed improvement comes from copying one character at a time vs entire available buffer at once.

[TD-er]

I think it also depends on the platform. For example ESP32 already has it copied to an extra buffer if you configure the serial RX buffer larger than the HW receive buffer. (at least this is how it is done in IDF5.1)

I can also imagine some will place a lock when reading.