Extend RTT protocol to report buffer overflows

[ianrrees]

By default, when an "up" RTT buffer in the target is full, writes to that buffer will be skipped (docs). At the debug terminal, this looks just like a gap in output; it's a silent failure which seems a bit bothersome and not very Rusty.

So, I wonder if we could use a bit in RttChannel::flags to indicate that the buffer overflowed? Once that was in place, RTT software on the host would be able to indicate that the target tried to send output but was unable to.

[ianrrees]

probe-rs masks off the two bits of flags that are used for channel mode, for instance here.

I did a quick test with a J-Link and Segger's RTT viewer (so, I presume using the on-probe RTT facilities) and firmware that sets bit 0x4 in flags of an up channel - it didn't seem to cause any issue.

One issue with shoehorning this functionality in to the flags field: the host clearing the overflow flag isn't atomic (or, could it be?), so the host could miss some overflow indications. Maybe that's not a big problem, since at least the first overflow will be reported. Other approaches could be to change the protocol, or add a data structure outside the normal RTT one.

[Yatekii]

Hmm I have thought about extending the protocol even more in the past. Maybe discarding RTT compatibility. We could do so many cool things :) I think RTT, ultimately is very C oriented and thus very limited.