Storing for screen display...

Depends... on the display device. If you have a 7-segment display series it may be best to convert it to that format in a logical storage location and let a background IO task update the display to the contents of that location; i.e. the task fires every 500ms and updates the LED display. This arrangement keeps the micro from unnessarily thumping the display even as the foreground computes many updates for display. Everyone knows what happens if you display is updated too often with changing data... lots of dim, uneven "8"s.

I guess it all depends upon whether the display output is purely output. Lots of programmers like to keep things in formats they can grab and use should the need ever arise. Its not always a good practice if you ignore the tradeoffs.

The way I look at it, its a compromise between concise storage and complexity of the display driver that actually grabs it. In a constricted 8051 environment, I'll often pack into nibbles by looking at the real range of display numbers used. We've had discussions about whether a fraction like .345 is better for some customers than a smooth round-off to .5 or .500. When it comes to displays, its best to visit the problem backwards, even if it doesn't always pay off. If you recall the steam-boat tachometer I wrote about long ago, I encoded the decimal point with a transparency number overlay... I used an out-of-range encoding to signal where the decimal point would be.

What ever feels fun for coding is the name of the game. :)

aka j