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.

[TD-er]

I think you should return on a complete sentence, so you can process the data first.
But this also complicates stuff a bit as you then also should keep track of how many characters were read and keep the rest.
Or... you should pre-parse and only hand over chunks till the next newline char.

[madhuryagupta]

It would be a nice design change but that would also require several other changes in existing components of the library for your suggestion to integrate nicely. And as you mentioned already, that would make things more complicated. And even the way I have done, every statement gets processed, exactly like it would be by using the existing interface function which takes one character at a time (my change uses existing function anyway).

I had thought about what you have suggested but decided to implement this change the way I did because of the following reasons.

1. Simplicity of the code change and the library interface (the user code remains simple as well).

2. Consistency with the existing design and library interface. Existing encode function returns true upon completion of "A" sentence. The caller has no idea which sentence it was and what information (location? time? speed? etc.) was just updated as a result of this completion.

In a similar fashion, after my change, the caller knows that one or more valid sentences were successfully parsed by the library, but still does not know what was updated.

Therefore, this change is perfectly consistent with the existing library and it's external interface.

It would be another nice change if the library held "dirty" flags for all pieces of information it holds, so that the caller can figure out which fields contain new information.

3. Minimal changes to existing code while still achieving what I wanted to achieve.

[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.