Allow MPU6050 suport (including DMP) for Arduino to compile on ESP32 with Arduino core

[josefadamcik]

This is a tiny change which allows MPU6050 support library to compile on ESP32 with Arduino core. It also allows to compile DMP support and run the MotionApps examples on ESP32. I have verified this on hardware, everything works very well. This practical fixes #500

Changes are only small and related to 2 compilation problems:

Things related to progmem being redecalerd in MPU6050_..Axis_MotionApps_... header files. The code in those 3 files assumes that when__AVR__ is not defined, it should be defining those for Teensy.
ESP32 has those defined in progmem.h (which is usually already included, but in order to make the change easier to understand and the conde seflexplanatory I have also included the #include progmem.h directive). As a side note: there was already #ifndef __PGMSPACE_H_ in the code in order to prevent double definitions. But ESP32 Arduino code uses #define PGMSPACE_INCLUDE instead of #define __PGMSPACE_H_ in their progmem.h.

Another change is missing BUFFER_LENGHT. The only remark regarding this I have that there is already similar #ifndef in I2Cdev.cpp:90 . So maybe it would make sense to have this in i2cdev.h instead. I chose the approach in this PR mainly because i don't know the library well and I am trying to minimize a risk of some regression I couldn't foresee.

This PR fixes #500 as it states in the description (there is a lot of discussion which talks about other boards, but the issue itself was created for particular compilation problems I am proposing to fix in this PR.

[ZHomeSlice]

Looks great!
Z

[cybercatnet]

tested, it works

[RodGat100]

Tested on my Heltec ESP32. Thank you!

[duanegran]

I tested with an adafruit esp32 feather and these changes worked just fine. Thank you.

[zjor]

I tried these changes with my Sparkfun ESP32 Thing Plus (WROOM), it worked, but I got a significant performance issue:

with empty loop() it performs about 1 million cycles per second,
when I call mpu.dmpGetCurrentFIFOPacket(fifoBuffer) it drops to 4k cycles per second, the same code gives me 25k cycles on Arduino Nano.

Do you have any idea what might be the issue?
Thanks in advance!

[josefadamcik]

@zjor

with empty loop() it performs about 1 million cycles per second,
when I call mpu.dmpGetCurrentFIFOPacket(fifoBuffer) it drops to 4k cycles per second, the same code gives me 25k cycles on Arduino Nano.

Do you have any idea what might be the issue?

I have not. I didn't do any performance profiling so I can't even tell if I had the same issue. But I guess I did and I just didn't know that.

[ZHomeSlice]

Note that the FIFO buffer only fills 100 times each second. all other requests will return false. each request requires the code to communicate through the i2c bus. I would expect the performance struggles to be related to the i2c bus. I would also suggest once you get a good reading to skip mpu.dmpGetCurrentFIFOPacket(fifoBuffer) for just less than 10 milliseconds so you catch the buffer after a new reading is acquired.
hope this helps.
Z

[jrowberg]

Sorry this took me so long to get to this. It's a safe improvement to the code, even if other performance issues exist on the ESP32 platform. This PR certain isn't the cause of them!