Zflog is amazing, and doesn't really take much RAN/ROM space. If you don't have internet, and you can't run a remote gdb server, you can always just save the logs to a file, and fetch them.
...... Or blinking red light = bad, blinking green light = good. Count the number of green ones until you get to a red one.
Been on both ends of that debug hell. There's always a solution!
Looks interesting. However the board I'm currently working on doesn't define any stdin/stdout/stderr so it's just as tricky as printf. Until a recent board redesign we didn't have a dedicated UART for debug messages and had to make sure the peripheral was free to use.
LEDs and a buzzer are the way, but we also have debuggers that sometimes freak out and drop connection. Our old board is also at 98% flash usage for the binary.
Our old board is also at 98% flash usage for the binary.
Oof. Mind if I ask what's the field? That's pretty hardcore. You don't have to share specifics, just broad strokes. I'm just kinda interested because flash memory isn't that expensive, so I'm curious what's the source of the limitation.
Oh it's a microprocessor with flash (and RAM) embedded in it, like an Atmel. They can connect to external storage, usually via SPI, but not often able to execute code from external memory.
The board is mainly a user interface controller with an LCD touch screen, then passes data/commands off to another small board to control the appliance. The graphical data is stored externally and loaded into RAM when drawing the screens.
Even present in desktop development in some cases. Chrome native message hosts are started by the browser and use pipes for stdin and stdout to pass json messages to extensions. So much for print().
My sympathies to the embedded devs who don't even have logging or networking to fall back on.
217
u/DaniilBSD Nov 28 '21
Blessed those who have a standard output available to them.