I added the picture i forgot.
Yes a user format. That would be an idea. I already using the uart for debugging too, so it would be awesome to have a column for hex, ascii and decimal. But there was a feature suggested, that would write a whole packet of bytes in one line. But in this case, functionality could be adopted differently.
The automatically turning on channels was just a suggestion, since one can adopt. I wonder if others run into this problem of not beeing able to choose a channel, because it is not activated.
Your idea is good, and the best solution is to have multiple formats to choose from. Users can choose from 1, 2, 3, or N display formats on the same line, such as 01000001 | 0x41 | 'A' | ... If it cannot be displayed properly, it is the user's responsibility,
It can also be displayed in one column, such as
UART Time Rx
1 0us 01000001
1 0us 0x41
1 0us 'A'
I haven't seen any manufacturers doing this yet, when implemented, the workload looks very heavy, and all protocols need to consider supporting various display formats, Also, need to consider whether the decode bus supports multiple display formats.Some protocols have a relatively large amount of data, When the display cannot fit, users will be dissatisfied. Therefore, manufacturers still need to consider whether the display area is sufficient.
Add to Wanted Features No.27
UART protocol on electrical level is defined as sending single ASCII characters/single byte (or 7bits sometimes, not even a full byte).
Creating complex messages and/or binary transfer is left to application level.
There are protocols like Xmodem/Zmodem/Kermit, AT command set for modems, Modbus, and literally millions of custom data exchange protocols. Some send fixed length data, some are delimited at the end of a message with a character sequence. Protocol is asynchronous so Rx/Tx can happen at any time, intermixed..
So how do you group messages for all that?
As for coding, available space on screen limits what can be done. When showing characters, do we do only original ASCII or ANSI?
How do we deal with control characters? Are control characters used as control characters at all in this particular protocol? Do we show only "readable" characters and some symbol for the rest or we do mixed display where we show ASCII(or ANSI) for "readable" and hex for the rest ? Or decimal, or binary? Do we decode VT100 ?
And on and on...
There is whole world of terminal applications (standalone programs) for PCs for this purpose. Paid applications, where companies live from selling terminal/serial/modbus etc, serial protocol software for this purpose. Software made for sole purpose to be able to look at serial stream data.
That is a testament how easy it is.
This kind of higher level decoding of data is called "symbolic decoding" in scope world. Like when you are decoding CAN on a car, and then you load symbolic data for your specific car (you need special symbolic database for that) and then on a screen of a scope you can directly see that message came from throttle position sensor and that throttle is pressed 50% instead of seeing a message from ID 3345 with value 2024. These things exist. But on scopes that cost as much as your car.