Properly handle UART errors for a couple of unwraps

[trufae]

No description provided.

[trufae]

i wrote a script that builds the firmware for esp32c6 and reports the file size comparing it to the main branch:

firmware size of this branch:
Unstripped: 15274332 bytes
Stripped: 1089836 bytes

firmware size from main branch:
Unstripped: 15305316 bytes
Stripped: 1093964 bytes

[brainstorm]

i wrote a script that builds the firmware for esp32c6 and reports the file size comparing it to the main branch:

firmware size of this branch: Unstripped: 15274332 bytes Stripped: 1089836 bytes

firmware size from main branch: Unstripped: 15305316 bytes Stripped: 1093964 bytes

Turns out that we did experiment with a portable version of your script in the past: cargo-bloat ... unfortunately the symbol breakdown was quite broken for embedded targets, but yeah, perhaps your simple approach (just evaluating the size of the whole bin) works better for CI regressions. I'll look at integrating it.

Or maybe cargo-bloatED or binsize might work better? 🤔 ... the idea being that instead of wondering what made a binary grow (regress), we could get a breakdown directly done on CI.

[brainstorm]

@trufae Something like binsize is pretty close to what I mean:

... there seems to be a loooong tail of 0.0N% but I'm not sure that's well tallied up :_/

rvalls@framework:~/dev/personal/ssh-stamp$ binsize --max-rows 20 --profile release --color --desc --file ./target/riscv32imac-unknown-none-elf/release/ssh-stamp --ld-memory-map ./target/riscv32imac-unknown-none-elf/release/build/esp-hal-f38a8b7a8bfabcd7/out/memory.x

The total bin size seems to almost match your script output size (when stripped), since I'm using the --release profile:

Functions: 2915 symbols,  968252 bytes
Data:      1897 symbols,  196754 bytes
Total:     4812 symbols, 1165006 bytes

Anyway, I think this perf/regression watch work belongs to issue #28, I have higher/critical issues to tackle now-now in #7 #62 #21 :_S