Ideas for code instrumentation

[Nominal Animal]

So maybe this: in the beginning of each function (except some super performance critical funcs), use some helper macro to allocate 4-8 bytes out of stack, and store some magic number, plus any kind of identifier for the function, like a #defined unique constant for each .c file plus __LINE__ number - these would fit in maybe 20 bits.

It is surprisingly hard to get a C or C++ compiler to reliably put something on the stack.  Even expressions like
    *(void **)__builtin_alloca(sizeof (void *)) = (void *)(expression);
can be optimized out, and when you force it, say
    _label: *(void *volatile *)__builtin_alloca(sizeof (void *)) = &&_label;
you end up generating a lot of code instead of the simple mov+push one might expect (on ARM Thumb or x86 or x86-64, for example).

This is why I suggested using an external stack for call graph and stack pointers, because that you can do with very tight extended asm, and thus low overhead.

[NorthGuy]

ELF (that is DWARF) contains enough information to restore the call sequence if (stack + registers) is dumped, especially with newer DWARF versions. Perhaps, there may some weird situations, or DWARF bugs ..., but it works well in general.

[Kalvin]

Hmm, I wonder if scope decode could be used.
Hook an LDR/photodiode to the scope, play the video and hold the LDR/pd against the screen.
Heh, a lazy electronics engineer's way to avoid writing video decoder stuff

Heh, just tried this for fun.
Soft uart at 10 baud 8N1 driving LED.
Video the LED.
Playback the video with crude LDR detector just above LED on screen.
Serial decode LDR data using logic analyser (because my scope decode is 100 baud minimum).
Works fine.

Very large creepage and clearance opto isolator 

You can increase the throughput by 10% if you use 7N1 (if you are only sending ascii information and the MSB will be always zero anyway).

[NorthGuy]

You can increase the throughput by 10% if you use 7N1 (if you are only sending ascii information and the MSB will be always zero anyway).

Or, you can increase throughput by 50% or more if you switch from ASCII to binary

[Kalvin]

You can increase the throughput by 10% if you use 7N1 (if you are only sending ascii information and the MSB will be always zero anyway).

Or, you can increase throughput by 50% or more if you switch from ASCII to binary

Indeed. Using binary will become feasible if one implements some kind of framing for the payload. For example the SLIP protocol defines a simple framing: https://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol

The escape bytes should be selected so that they will appear in the raw payload only randomly.

Framing will decrease the throughput a little, but if the frames are relatively long and the escape bytes appear only rarely and randomly, the throughput remains very good. Adding framing will make implementation a little more complex, but the gains may justify the effort.

[voltsandjolts]

For this very simple application, I think a 1 second idle time would work fine as a frame delimiter.

When you need frame delimiting that is not timing dependent, SLIP is, hmm, functional. But COBS is much better, especially for low bandwidth channels.