L
L
lemon_spb2014-01-30 12:41:42
Arduino
lemon_spb, 2014-01-30 12:41:42

Arduino + MPU6050 (i2cdevlib library). What to do with "Multiple definition of MPU6050::XXXXXX" errors?

Hello dear experts!
I'm using i2cdevlib to make it easier to "communicate" with the MPU6050's gyroscope and accelerometer.
Their example compiled and worked without any problems:
I just copied the necessary files to the project folder, took the project itself from the examples and everything worked.
Here is the project
The sensor itself, obviously, is not needed to assemble and upload to Arduino.
But to wrap all work with the MPU6050 in a separate class that would hide all initialization, etc. Did not work out.
To do this, I created Sensor.cpp and Sensor.h. From Sensor.h I connected the headers for working with the MPU6050, as was done earlier in the main project.
In the main project, I removed everything, included Sensor.h there,
and errors started to appear:

testMPU.cpp.o: In function `MPU6050::dmpGetAccel(long*, unsigned char const*)':
/MPU6050_6Axis_MotionApps20.h:533: multiple definition of `MPU6050::dmpGetAccel(long*, unsigned char const*)'
sensor.cpp.o:/MPU6050_6Axis_MotionApps20.h:533: first defined here

Project file code:
//всякие дефайны

#include "Wire.h"
#include "sensor.h"


void setup() {
  Sensor::getInstance().init();
}

void loop() {
  float y,p,r;
  Sensor::getInstance().getYpr(y,p,r);
}

sensor.h code:
#ifndef SENSOR_H
#define SENSOR_H

#include "I2Cdev.h"
#include "MPU6050_6Axis_MotionApps20.h"
//#include "MPU6050.h" // not necessary if using MotionApps include file
// Arduino Wire library is required if I2Cdev I2CDEV_ARDUINO_WIRE implementation
// is used in I2Cdev.h
#if I2CDEV_IMPLEMENTATION == I2CDEV_ARDUINO_WIRE
    #include "Wire.h"
#endif

class Sensor{
public:
  static Sensor & getInstance(){
    static Sensor instance;
    return instance;
  }
  
  bool init();
  
  bool getYpr(float & y, float & p, float r);
  
protected:
  MPU6050 _mpu;
..............

Here's the unbuilt project itself, along with the i2cdevlib files.
Thanks to everyone who read to the end.

Answer the question

In order to leave comments, you need to log in

1 answer(s)
O
osnwt, 2014-02-10
@limon_spb

The problem is in the incorrect writing of the library.
By definition, header files should include only descriptions of functions and variables, and cpp files - their definitions (implementation). The include file MPU6050_6Axis_MotionApps20.h is not really a header file, it contains the implementation of functions that should be in only one project file. If you include it twice, all functions will be compiled into each object module, which will cause an error at the linking stage.
You can even guess why it was done this way: this file must be of type cpp. However, due to Arduino limitations, ALL cpp files in the directory will be compiled automatically when only one of them (6Axis or 9Axis) is needed. Therefore, they were made *.h, not taking into account the possibility of re-inclusion. This could have been done correctly, but the author did not bother with such "trifles".
Without editing the library, this problem cannot be solved. To do this, you need to expand the description of the library class in the selected variant into *.h, and its definition - into *.cpp. And in some way to take into account which of the options should be collected. In a normal development environment, it would be enough to add only one (necessary) *.cpp to the project with the implementation of one or another option. In the standard Arduino environment, this cannot be done (both cpp will be compiled), and it is necessary to pervert, for example, by dividing the library into two parts or in another way. As a result, due to the stupid limitations of the environment, instead of solving your problem, you have to think how to get out. Alas.
PS. My personal opinion about Arduino: while recognizing the advantages of the system in terms of popularizing microcontrollers among the "masses", its implementation, in my opinion, is worthless and instills bad programming skills. The simplest example of this is int led = 13, which is constantly repeated in all official examples, when the environment has long defined it as LED_BUILTIN, always correct for the SELECTED board. From such "little things" it turns out that people write interesting, in general, things, but they do it at random, which cannot but grieve. And the environment itself instills in them such a style.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question