You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Presumably, the current version of gcc, when invoked with the options passed by the current version of the Arduino IDE, generates assembly that orders the bytes in the expected way. But this cannot be relied upon, and can very well depend on the compiler, compiler version, compiler options, or even surrounding code. This is the kind of software error that cannot be unveiled by testing, as the code can “just work” even if it is incorrect.
The simplest solution is to issue the calls to wire->read() within separate statements. Unlike the arguments of the | operator, separate statements have a well define order of evaluation:
Thanks for your comment @edgar-bonet , however it seems that @tockn didn't update his library for several months :(
I forked the Tockn's library and took your comment into account in my own repository. Your comments are welcome.
The method
void MPU6050::calcGyroOffsets()
contains the following line:rx = wire->read() << 8 | wire->read();
and similar lines for
ry
andrz
. The same idiom is used inMPU6050::update()
.This kind of expression should be avoided, as it does not guarantee the endianness of the retrieved data. This is because, in C++, the order of evaluation of the arguments of the
|
operator is unspecified.Presumably, the current version of gcc, when invoked with the options passed by the current version of the Arduino IDE, generates assembly that orders the bytes in the expected way. But this cannot be relied upon, and can very well depend on the compiler, compiler version, compiler options, or even surrounding code. This is the kind of software error that cannot be unveiled by testing, as the code can “just work” even if it is incorrect.
The simplest solution is to issue the calls to
wire->read()
within separate statements. Unlike the arguments of the|
operator, separate statements have a well define order of evaluation:See also this post on the Arduino forum.
The text was updated successfully, but these errors were encountered: