4 ms·
Not a cause. CAN messages are up to 8 bytes long, not a 64-bit signed integer. There is enough space there for packing the time as a 64-bit time_t (which will e
by gaius_baltar 5y ago
Not a cause. CAN messages are up to 8 bytes long, not a 64-bit signed integer. There is enough space there for packing the time as a 64-bit time_t (which will ensure it will work literally forever, as the Universe will die before it overflows) or that ugly BCD format that RTCs use (which will last for practical uses).
- rightbyte 5y agoWhen I worked in the auto industry we had to fight for every bit on the CAN bus since it was always on the verge of congestion. We did insane statemachines to carry payload in unrelated bits. I can easily see someone doing: unsigned date = 202201011758; *(unsigned*)&tx[0] = date; And in another ECU: int date = *(int*)&rx [0]; int y = date / 100000000; // -20 int M = date / 1000000 - y*100; // -93 ... Or just saturating negative numbers to 0, since integer values over 0xFD00 0000 (something) are reserved for error handling.
- kingcharles 5y agoI'm with you on this, and that would explain the bug if Honda hadn't said the code will return to its correct output in August.
- rightbyte 5y agoYe I was figuring which algorithms might give that bug behaviour but I could not think of any. Maybe they have a "Y since X", hit the Autosar reserved range at 0xfd..., and it wraps around 0xff... to 0 in August? A free running counter through the "non physical" range is the only thing I could think of that would behave like this and fix it self by a date. The timer could be any bit width or unit really.