core::fmt::write! causes unexpected behavior about avr-hal

[Rahix]

The problem is that core::fmt uses a lot of memory for its formatting. For any non-trivial cases, it usually surpasses the capabilities of an AVR chip so essentially you just cannot use it at all. That's why all the examples make use of the ufmt crate instead.

However, there is one place where core::fmt sneaks in and cannot be replaced so easily: panic message formatting. The only real solution at the moment is to make sure that all panics do not provide a formatted message and instead simply panic with a static message / no message. For example, you need to replace all Result::unwrap() calls with something like

trait ResultExt {
    type T;
    fn unwrap_avr(self) -> Self::T;
}

impl<T, E> UnwrapExt for Result<T, E> {
    type T = T;

    fn unwrap_avr(self) -> Self::T {
        match self {
            Ok(t) => t,
            Err(_) => panic!(),
        }
    }
}

(Or alternatively follow your suggestion from #463 but that means you don't get any custom panic behavior at all)

[djdisodo]

@Rahix i thought it might be caused by insufficient sram but i didn't thought further because compiling with release profile fixed it
(maybe core::fmt heavily rely on compiler optimizations to reduce ram usage)

about immediate abort, iirc just avoiding print of error message didn't strip out all of the error messages

[Rahix]

Relying on optimizations with core::fmt is very hit or miss. Compiling with LTO manages to eliminate a lot of overhead a surprising number of times, but it does not always work. And when it doesn't, there is little you can do, unfortunately.

iirc just avoiding print of error message didn't strip out all of the error messages

The things is that you need to ensure all panicking code paths do not lead to a panic with a message. This is not an easy feat of course. The ResultExt shown above just takes care of the worst offender - Result::unwrap() which usually pulls in the full core::fmt::Debug implementations of the error types. But to get rid of all error message strings, you'll of course need to do a lot more. A list that certainly isn't exhaustive:

• Option::unwrap()
• Any uses of ops::Index/ops::IndexMut where the bounds check isn't optimized away - replace with fallible .get()/.get_mut calls and then work around the following Option::unwrap() as before.
• If overflow checks are enabled, you get panicking code paths from a lot of maths operations. Either disable overflow checks or use the fallible methods on integer types instead (e.g. u32::checked_add())