Compile Error Adafruit GPS library. TWI connection

Hardware Nano Family Nano Every
1

I am trying to connect a GPS to an Arduino via TWI connection. This works fine when I use the Adafruit GPS library and basic Arduino Nano. However, simply changing to Arduino Nano Every, the same source code induces the following compilation errors. Has anyone encountered a similar problem? Anyone know a fix?

In file included from c:\Users\User\OneDrive\GregData\Projects\Arduino\Data\Target Firmware\libraries\Adafruit_GPS_Library\src/Adafruit_GPS.h:66:0,
                 from c:\Users\User\OneDrive\GregData\Projects\Arduino\Data\Target Firmware\libraries\Adafruit_GPS_Library\src\Adafruit_GPS.cpp:31:
C:\Users\User\AppData\Local\Arduino15\packages\arduino\hardware\megaavr\1.8.8\libraries\Wire\src/Wire.h: In member function 'char Adafruit_GPS::read()':
C:\Users\User\AppData\Local\Arduino15\packages\arduino\hardware\megaavr\1.8.8\libraries\Wire\src/Wire.h:64:12: note: candidate 1: size_t TwoWire::requestFrom(int, int, int)
     size_t requestFrom(int, int, int);
            ^~~~~~~~~~~
C:\Users\User\AppData\Local\Arduino15\packages\arduino\hardware\megaavr\1.8.8\libraries\Wire\src/Wire.h:62:12: note: candidate 2: virtual size_t TwoWire::requestFrom(uint8_t, size_t, bool)
     size_t requestFrom(uint8_t, size_t, bool);
            ^~~~~~~~~~~
Sketch uses 16432 bytes (33%) of program storage space. Maximum is 49152 bytes.
Global variables use 3611 bytes (58%) of dynamic memory, leaving 2533 bytes for local variables. Maximum is 6144 bytes.
2

Please post ALL of the error message.

3

It is a well-known bug. It is a parameter mismatch.

You can either remove the casting of the parameters, or cast the parameters to "int" in the library. The library is in the folder "Documents \ Arduino \ libraries".

For example here: https://github.com/adafruit/Adafruit_GPS/blob/master/src/Adafruit_GPS.cpp#L311

you will see this code (between other code):

requestFrom((uint8_t)0x10, (uint8_t)GPS_MAX_I2C_TRANSFER, (uint8_t)true)

Change it to this:

requestFrom(0x10, GPS_MAX_I2C_TRANSFER, true)

or if that does not work, try this:

requestFrom((int)0x10, (int)GPS_MAX_I2C_TRANSFER, (int)true)

You might have to change it in other places as well.

4

I copied everything from the output window & posted all of that into a code block. If there really is more to the error message than this, how do you know that? I'm afraid I need more of a clue as to what I'm looking for.

Would you explain the difference between "all" and "ALL"?

5

One is all upper case.

6

Sorry, I am trying to understand why you chose to do that. Was it for emphasis? I am receiving your message as though you are trying to make a point that I'm afraid is completely lost on me. By stating the obvious you are not helping.

7

Thank you @Koepel. You have succinctly explained the diagnostic messages & I understand the problem. I am not familiar with where the IDE library manager puts stuff. It's a consequence of that that I somehow have several copies of the .h & .cpp files. I tweaked the .cpp file in the directory that you identified, but it didn't fix the problem. I am satisfied that my sketch is getting its library files from somewhere else, although the location you identified did hold the files with the appropriate names. Ultimately, I haven't figured out the search path my IDE us using. I'm leaning towards using the library manager to unload what it thinks is the repository for the Adafruit GPS library, & just put the .h and .cpp into the same folder as my .ino. I think you've given me enough to get to the solution. I can see the explicit cast & it's incompatability with the prototype of the called function. I guess that prototype is different for the Atmega328 and Atmega4809 implementations of the Wire library & that's determined by one of the #defines between the two personalities. I'm onto it, and think I'll get there.

8

Problem solved. I removed the library using library manager. That clarified where it was putting the source files.

Looks like the Atmega328 build has 2 forms of requestFrame, - int,int,int & uint_8,uint_8,uint_8. However, the Atmega4809 is different. Its 2 possible forms are int,int,int & uint_8,size_t,uint_8. I know size_t is 2 bytes for the 328, but am not sure for 4809. In any event, it is different from uint_8.

I tried removing the cast for the middle parameter, leaving uint_8 for first and last, hoping that would be enough for the compiler to resolve the ambiguity. But it didn’t.

Therefore, @Koepel you are right in that I have to make it use the int,int,int form, but I did have to explicitly cast all parameters to int. Removing the casts altogether left the unresolved ambiguity and the compiler failed.

So the 328 options are 2,2,2 bytes and 1,1,1 bytes, but the 4809 options are 2,2,2 and 1,2,1 (or is it 1,4,1?) The only form that’s common to both is 2,2,2 - ie int,int,int.

9

Maybe. I just call it a big mess.

The documenation of the Wire library should force the type for the parameters, or the Wire library should accept all possible combinations of parameters. It is not hard to do it right :smirk:

Adafruit has gone too far in my opinion by adding all the "(uint8_t)" cast for the parameters. I see that as a unnecessary showing off. Source code should be readable in the first place.

In the Arduino IDE, in the preferences, you can set the option to show the verbose output of the compiler. Then the compiler tells it all, also the path of the libraries. We have that turned on.

10

Agreed. Adafruit sensor libraries are now hopeless, in my opinion, especially with the relatively new "unified sensor framework".

They have become grotesque bloatware, and in some cases, the example code for simply getting raw data from a single sensor won't fit in the memory of an Arduino Uno, due to all the extraneous libraries that are loaded.

11

Something I struggle with is it is really difficult to read the code. There are great rafts of text in the source files, purportedly to explain what they are doing, but it has gone so far that I struggle to even find the code.

I suppose with the requestFrame method, since there are two flavours in the wire library, they are obliged to eliminate the ambiguity to get it to compile. I am actually troubled by the wire library, which is not Adafruit. The functions are inconsistent between Atmega328 & Atmega4809.

12

Good point you made about “bloatware”. I’m thinking the time has come to give up on a third party library & write my own from scratch. I know the TWI address is 0x10. I believe the GPS is only sending NMEA sentences. I know the form of an NMEA sentence is <$> payload <*> XX <\r\n> where XX is the two byte hexadecimal XOR checksum of the payload. I am already doing my own sentence assembly & validation. I believe the GPS is just receiving PMTK commands of the same form, and from the examples I have seen it doesn’t even seem to be doing the checksum computation. Without delving too deep the price in resources used by the Adafruit library and grief I am encountering just isn’t worth it.

13

Sure, use TinyGPSplus or any of the other GPS libraries, this is a simple example of reading a Ublox GPS via I2C;


#include <Wire.h>
const uint16_t GPSI2CAddress = 0x42;


void loop()
{
  uint8_t GPSByte;
  
  do
    {
      Wire.requestFrom(GPSI2CAddress, 1);
      GPSByte = Wire.read();

      if (GPSByte != 0xFF)
      {
        Serial.write(GPSByte);
      }
    }
    while (true);
}


void setup()
{
  Wire.begin();
  Serial.begin(115200);
  Serial.println();
  Serial.println("GPS_Echo_I2C Starting");
}

All you need to do to use TinyGPSplus to decode the GPS data is use the above code and pass the read character to the encode function like this;

 if (GPSByte != 0xFF)
 {
 gps.encode(GPSByte);
 }
14

@srnet - thanks for the steer. I have had grief with both Sparkfun & Adafruit GPS libraries, both of which I would say involved me in chasing their bugs. Of course their remit is a product that works for all flavours of Arduino & who knows? Possibly other microcontroller platforms. My requirement is much narrower. I will have a look, as you suggest.

But do correct me if I am mistaken. It’s not a Ublox gps I’m working with. It’s MT3333, I think. I do need to send it commands to configure it.

I fear I am moving away from the Nano Every classification for this thread.

15

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.