[RESOLVED] SerialPort on MRK Zero (issue with MS5611.h Library)

Context: we wrote up a Guidance/Navigation/Control script, prototyping off of the Uno. It is essentially an assemblage of sensors (MPU6050, MS5611, NEO-6M GPS, HMC5883L) that output to two servos and record telemetry to an SD card. We naturally needed more RAM and Flash Memory, while taking up less space, so we purchased the MKR Zero. Started running into problems from there...

Generally speaking, our problems seem to be interfacing with the Serial Port (see bottom for a bit more detail). However, for where we are at the moment, I've isolated a single problem that I hope to get some help to resolve. It is as follows:

I am getting the following error code for a library for the MS5611.h (posted below error code).

ERROR

In file included from C:\Users\Wolfgang Repository\AppData\Local\Arduino15\packages\arduino\hardware\samd\1.6.18\cores\arduino/WCharacter.h:22:0,

                 from C:\Users\Wolfgang Repository\AppData\Local\Arduino15\packages\arduino\hardware\samd\1.6.18\cores\arduino/Arduino.h:74,

                 from sketch\MS5611data2serial.ino.cpp:1:

C:\Users\Wolfgang Repository\Documents\Arduino\libraries\MS5611-master/MS5611.h:36:12: error: expected unqualified-id before numeric constant

   int32_t  _P;

            ^

C:\Users\Wolfgang Repository\Documents\Arduino\libraries\MS5611-master/MS5611.h:39:13: error: expected unqualified-id before numeric constant

   uint16_t  _C[N_PROM_PARAMS];

             ^

exit status 1
Error compiling for board Arduino MKRZERO.

LIBRARY

/*
ms5611.h
Library for barometric pressure sensor MS5611-01BA on I2C with arduino

by Petr Gronat@2014
*/

// Include guard token - prevents to include header file twice
#ifndef MS5611_h
#define MS5611_h //create token

// Include Arduino libraries
#include "Arduino.h"
#include <Wire.h>

#define N_PROM_PARAMS 6


// address of the device MS5611
#define ADD_MS5611 0x77 // can be 0x76 if CSB pin is connected to GND

class MS5611{
 public:
 MS5611(); //constructor
 void begin();
 uint32_t getRawTemperature();
 int32_t getTemperature();
 uint32_t getRawPressure();
 int32_t getPressure();
 void readCalibration();
 void getCalibration(uint16_t *);
 void sendCommand(uint8_t);
 uint32_t readnBytes(uint8_t);
 private:
 void reset();
 int32_t _P;
 int32_t   _T;
 int32_t _dT;
 uint16_t _C[N_PROM_PARAMS];
 uint32_t _lastTime;
};

#endif

I've tried playing around with the library a bit, but I've made no progress. Would like to utilize this as it's done us well during prototyping. That said, I've tried other MS5611 libraries, and they just result in the board completely disconnecting (you know how it does that thing where it disconnects and reconnects, sometimes you need to select another COM## to view the Serial output? None of that, it just disconnects...). The latter seems like an odd problem, and I haven't faced it with any of our other sensors yet. That said, I am still working on isolating problems, so the only components I've truly 'cleared' are the MPU6050 and SD card reader/writer.

hugs and kisses,
Wolfgang

[EDIT]
Here's an example code (probably the simplest possible script to test the MS5611 with this library) that came with the library. This brings up the error mentioned above, when it (like our script, and other test scripts afterwards) did not have an issue with the UNO.

#include <MS5611.h>

MS5611 baro;
int32_t pressure;

void setup() {
  // Start barometer
  baro = MS5611();
  baro.begin();
  // Start serial (UART)
  Serial.begin(9600);
  delay(2);
}

void loop() {
  // Read pressure
  pressure = baro.getPressure();
  // Send pressure via serial (UART);
  Serial.println(pressure);
}

In fact, including just the library seems to have no problems. It is only when adding in

MS5611 baro;
int32_t pressure;

that it gets all crazy on us.

Also posted at:

If you're going to do that then please be considerate enough to add links to the other places you cross posted. This will let us avoid wasting time due to duplicate effort and also help others who have the same questions and find your post to discover all the relevant information. When you post links please always use the chain links icon on the toolbar to make them clickable.

This really just comes down to poor programming practices on the part of the library author.

First of all, the C++ specification states that all identifiers that start with an underscore followed by an uppercase letter are reserved.

Second, the C++ specification states that all identifiers that start with an underscore are reserved for use in the global namespace.

Third, use descriptive variable names!!! Not only will this make the code much easier to understand, it also makes name collisions less likely.

Ah, makes sense, thanks for the heads up on that. Clearly, I'm new to this form of troubleshooting.

Made changes to the conflicting variable names, that seems to have resolved the issue! Thanks for the methodological answer!