Open salkinium opened 6 years ago
Good to see you running the unittest in hardware!
FAIL: bme280_test:208 : true == false
This is comparing the error in conversion against an arbitrarily chosen upper bound for the error. This might be caused by a less accurate emulation of floating point operations on the AVR.
FAIL: ltc2984_test:25 : true == false
FAIL: ltc2984_test:26 : true == false
Fix:
- TEST_ASSERT_TRUE(modm::ltc2984::Data(0x01 << 24).isValid());
+ TEST_ASSERT_TRUE(modm::ltc2984::Data(0x01ul << 24).isValid());
- TEST_ASSERT_TRUE(modm::ltc2984::Data(0xff << 24).isValid());
+ TEST_ASSERT_TRUE(modm::ltc2984::Data(0xfful << 24).isValid());
FAIL: ltc2984_test:98 : 1048576 == 0
TEST_ASSERT_EQUALS(temperature.getTemperatureFixed(), temperatureTableFixed[jj]);
Hmmm...
Hmmm...
There are several shift overflow warnings emitted during compilation for AVR, that's probably the source.
- return (this->data & 0x800000) ? -(((~ret) + 1) & 0xffffff) : ret;
+ return (this->data & 0x800000ul) ? -(((~ret) + 1) & 0xfffffful) : ret;
FAIL: ltc2984_test:98 : 1048576 == 0
The test is inside executes in a loop, so it should more than once.
Some AVR unittests are failing, which is troubling. I'm executing these tests on a AT90CAN128, with 4kB RAM. The tests have to be split up into several chunks or they won't fit into the Flash. This can be done simply by including just a few modules instead of all.
Unfortunately, the unittests for Resumables cause a Stack Overflow, which resets the DUT and therefore loops forever. Manually removing a handful of test cases that cause this, shows no tests failed in the resumable however. I'll try this again on a ATmega2560 with 8kB RAM.
These are the failed test cases: