AVR unittests not in best shape

[salkinium]

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:

FAIL: slave_test:117 : 0 == 1
FAIL: slave_test:139 : 0 == 2
FAIL: slave_test:147 : true == false
FAIL: slave_test:150 : 1 == 2
FAIL: slave_test:154 :
[1, 163]
[205, 171]
FAIL: slave_test:165 : 0 == 3
FAIL: slave_test:189 : 0 == 4
FAIL: slave_test:190 : 0 == 39030
FAIL: slave_test:198 : true == false
FAIL: slave_test:201 : 1 == 4
FAIL: slave_test:204 :
[1, 9, 0, 222]
[120, 86, 52, 18]
FAIL: bme280_test:208 : true == false
FAIL: bme280_test:209 : true == false
FAIL: bme280_test:289 : true == false
FAIL: bme280_test:290 : true == false
FAIL: bme280_test:208 : true == false
FAIL: bme280_test:209 : true == false
FAIL: bme280_test:289 : true == false
FAIL: bme280_test:290 : true == false
FAIL: ltc2984_test:25 : true == false
FAIL: ltc2984_test:26 : true == false
FAIL: ltc2984_test:98 : 1048576 == 0
FAIL: angle_test:40 : -3.14159e+00 == 3.14159e+00
FAIL: time_test:33 : 1017971200 == 1000000000
FAIL: time_test:52 : 1073676288 == 1073741824
FAIL: time_test:71 : 1322192521 == 1311738121
FAIL: time_test:89 : 1337044484 == 1333329284
FAIL: time_test:108 : 3152047053 == 3141592653
FAIL: time_test:123 : 16 == 9
FAIL: time_test:124 : 5 == 8
FAIL: time_test:157 : 24 == 27
FAIL: time_test:158 : 4 == 6
FAIL: time_test:174 : 9 == 2
FAIL: time_test:175 : 2 == 3
FAIL: time_test:192 : 18 == 21
FAIL: time_test:193 : 4 == 6

36 test failed

[strongly-typed]

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.

[rleh]

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...

[salkinium]

Hmmm...

There are several shift overflow warnings emitted during compilation for AVR, that's probably the source.

[rleh]

modm/src/modm/driver/temperature/ltc2984.hpp

Lines 78 to 83 in 9abe715

	int32_t
	getTemperatureFixed() const
	{
	int32_t ret(this->data & 0xfffffful);
	return (this->data & 0x800000) ? -(((~ret) + 1) & 0xffffff) : ret;
	}

Fix: (?)

- 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.