Working on a weird problem. I'm making a serial probe to retrieve data off of a UART serial interface and display it on a little screen. That way you can take the probe wire and a ground wire and connect it to a circuit's serial transmit line (assuming it has one, otherwise no need for the probe) and you can see what's coming off of it.
The device only has two buttons and one of them scrolls up through the serial data, one scrolls down through the serial data, and holding button A down changes the baud rate.
Here's the tricky/clever bit. The data can either be textual or it can be binary.
If it's binary it's formatted like this
01 FA 5C 6A
24 CB C5 BF
etc
whereas if it's textual it will just come out as like
hello world
testing 1.2
.3.
This is to make it easier to view, and it will automatically detect the current format for the page you're on (textual or binary)
The reason it autodetects is because there are limited buttons so there's a lot of automagic necessary to make this thing work (it also does i2c scanning)
Anyway, the tricky bit is the page is a different size for textual versus binary data, and you potentially always have new data coming in.
So I have to dynamically compute where I am, based on the data coming in, and scroll with incoming data only if you're on the final page, or if the 32KB window is moving data off the beginning of the screen and your page is going out of scope.
while you scroll the page you're on may change from text to binary or from binary to text, such that the page winds up being a different size with each scroll.
It's really strange and I'm wondering if there isn't a better way to do it.
One option is to make it so if you hold button B down it changes from bin to txt (and maybe perhaps auto but that brings back the problem from above)
The issue with choosing a hard mode is that binary data will appear along with textual data always when monitoring many MCUs serial output, due to the fact that they post on their primary serial when they start up. That data will be textual no matter what.
I'm getting analysis paralysis thinking about this problem, so any insight into improving the design from a usability standpoint (given the tiny screen and extremely limited inputs) or alternative ideas to approach this would be helpful.
What I have tried:
This is a design question. I started producing code to implement the above but I decided I'm not done with the design phase and I don't want to go back and retool.
I figure community feedback from other devs will help me make a better probe, so this (very open ended) "question" is to that end.