Strange bug in arduino

[Ted Meyers]

I'm looking for some help on this one; I want to test the difference between some gyros, but I got stuck on the MPU6050.  I'm using the jrowberg mpu6050 library (which I believe to be corrupting memory).  Anyway, I made a wrapper for it based on his arduino test code (lets call it xmpu), then added the xmpu object to my rover object (call it rover) which also has a function pointer.  Very strange behavior is exhibited.

Like this (but this is greatly simplified):

class Xmpu {

   public:

      MPU6050 mpu;

      int address;

      int packetSize;

      byte buffer[64]'

}

class Rover {

   public:

      Xmpu xmpu;

      void (*cb)();

}

Rover::test() {

   println("CB VALUE IN TEST: " + cb);

   if (cb) cb();

}

[In arduino code]:

  rover.cb = &cb_fn;

  println("CB VALUE 1: " + rover.cb);

  rover.test();

  println("CB VALUE 2: " + rover.cb);

  void cb_fn() {

     println("IN CB!");

   }

---------  RESULTS -----

   CB VALUE 1: 3257

   CB VALUE IN TEST: 0

   CB VALUE 2: 3257

Note that "IN CB!" was never printed.

Also, if I define cb in Rover _before_ xmpu, it runs as expected:

   CB VALUE 1: 3257

   CB VALUE IN TEST: 3257

   IN CB!

   CB VALUE 2: 3257

So, how does the value of rover.cb change from 3257 to 0 and back when the test() method is called (it doesn't _do_ anything!)?  All I can figure is that the stack and/or the heap are seriously messed up, but rover.cb is the only thing that seems to be acting strangely.

I have no idea, but I think that I will try to simply the mpu6050 library and see if the problem goes away.

Ted

[Jon Watte]

"+" does not add strings in C / C++. It offsets pointers.

println("CB VALUE IN TEST: " + cb);

This will implicitly cast "cb" to an int, and add the value of "cb"-as-int to the beginning of "CB VALUE IN TEST: " and use that as a pointer that it passes to println().

What's extra "awesome" about the Arduino environment is that it doesn't display compiler warnings, presumably because that would "confuse" beginners.

(The best thing to do for beginners is to treat warnings as errors and turn them all on, IMO)

Sincerely,

jw

Sincerely,

Jon Watte


--
"I find that the harder I work, the more luck I seem to have." -- Thomas Jefferson

--
You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/85bca0fc-b7e4-4ab8-8d7b-8d0ab625e17c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ted Meyers]

Yeah, that is pseudo code, what I actually did does work (I have to print statements).

Ted

[Ted Meyers]

TWO print statements.  Sorry about the confusion, I'm trying to keep things simple.

[Michael Shimniok]

Did you get this figured out?

Is the Arduino resetting?

I think for something this weird it'd help to look at the actual, real code.

Do the print statements read rover.cb() ? or rover.cb?

Michael

 

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/1e0e1817-182c-40b4-8bdc-75e532a9b048%40googlegroups.com.

[Ted Meyers]

No the arduino is certainly not resetting.

What I am finding is that when I access rover.cb from outside the rover class, the value is as expected, but when I access cb from inside the rover class, the value is 0.  I have tried inserting some delay statements to see if it is a timing issue, but it appears not to be.  Obviously this is some sort of memory corruption.  There are a couple thousand lines of code, so I don't think anyone wants to look at the actual code, but if you do, it is at: https://github.com/TedMeyers/XYZ-robo

Also, I replaces the function pointer with an int and got the same strange behavior; and declaring the int anywhere before the xmpu declaration "fixes" the problem, but declaring anywhere after xmpu causes the problem.  It would appear the problem has something to do with xmpu, just not sure what.

Ted

[Ted Meyers]

Problem found!

Way down in the mpu6050 library (.h file) (which I did not write) there is an #ifdef MPU6050_INCLUDE_DMP_MOTIONAPPS20 that has some integers defined. Well, depending on how the .h files are included, this MPU6050_INCLUDE_DMP_MOTIONAPPS20 may or may not be defined. In one place it was defined and in another it was not, so the compiler was schizophrenic about the size of the mpu6050 object. BAD LIBRARY, BAD, BAD, BAD!