It feels a bit like when ddevault got pissy about “int” not meaning “codepoint”, when the minimum size of int is 16 bits (though in that case what they were doing was literally listed as UB in the docs).
OTOH I'm not surprised at all that embedded compilers play fast and loose with the standard.
It was surprising until I needed I/O between two systems with different CHAR_BITs to work.
Many systems need to access octet based field and communicate over octet based busses, and CHAR_BIT>8 machines are rare.
If the entire char is serialized, interoperability becomes a much larger mess.
Chars 2 to 4 times larger than what the standard requires? Not really. It means one platform would be reading / writing 4 bytes (octets) at a time, at which point endianness rears its ugly head.
That sounds a lot worse than clamping values to a byte.
On such a platform, if you have the string "Hello" and would write the chars un-truncated you'd end up with "H\0e\0l\0l\0o\0" in the file.
However, if you are not writing a string, but binary data, this would mean you now loose every 2nd 8-bit byte.
buf[0] = (data >> 24) & 0xFF;
buf[1] = (data >> 16) & 0xFF;
buf[2] = (data >> 8) & 0xFF;
buf[3] = data & 0xFF;