Click here to Skip to main content
15,849,328 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
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

whereas if it's textual it will just come out as like
hello world
testing 1.2

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.
Updated 12-Mar-23 3:55am

1 solution

Switching mode by holding B is a good idea - I'd certainly prefer it to a autoswitch which can be annoying if you are trying to read text!

It really depends on the size of the screen: It would be nice to have both in "hex view", in the same way that many PC hex editors : PsPad Hex[^]
But if this limited, then in text mode, replace non-printable characters with '.' or similar to get the same size, and keep a note of the first visible character's address.
So when you switch, just display the first visible character at the top left in the new format. That way, you can read text, check non-printables, and back to text as you wish.
Share this answer
honey the codewitch 12-Mar-23 11:44am    
You're leaning me toward that option. The screen isn't very wide or I'd have considered doing what you say, but I have maybe a dozen characters left to right - i haven't counted yet, or rescaled the font or anything just yet. My app in fact, computes the max column count based on the size of the display.
OriginalGriff 12-Mar-23 12:00pm    
Good grief. A tiny display, and you are using scalable fonts?

I'd have selected a font and size that is readable, and hard coded it as a bitmap or similar - much faster to display than scalable fonts! That's what I';ve always done in the past, anyway - but my processors were limited to Z80@32MHz, which isn't a lot these days. :D
honey the codewitch 12-Mar-23 12:10pm    
This is a dual core 240MHz proc with about 360KB of usable SRAM. I am using TTF because frankly, it's the quickest and dirtiest way to get anti-aliased fonts onto my screen using the libraries I'm using, and gives me the option to scale to different displays if I want to support different hardware. If I was super concerned about performance in this instance, I could prerender to a bitmap, but you run into perf issues anyway due to blending required for kerning.

Edit: In my LVGL TTF lib I do glyph caching so what you're talking about happens in the background, but I haven't implemented that for htcw_gfx yet.
OriginalGriff 12-Mar-23 12:23pm    
I'd have killed for a PC with those specs back when I was doing that stuff ... :sigh:

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900