We're designing a new rackmount box, basicly a fancy power supply, with an 800x480 4.3" LCD on the front. Roughly this:
formatting link
Does anyone have an estimate of how many characters X and Y we might use? We'll try to fire it up next week and experiment, but I'd like to start thinking about screen layouts and have no idea about what might be reasonable. We'd want good visibility so wouldn't want anything really tiny.
I'd prefer a fixed-size, fixed-pitch font, to keep the design simple. We might have some characters/boxes with different background colors.
The off-screen (mechanical) pushbuttons will be page left/right and cursor up/dn/left/right, and a spinner knob. There will be some box overhead pages and one page per plugin board.
Why make the screen so small? You have plenty of room - why not use it?
You could show a huge amount of important information that would be very valuable to the customer. They would like it. You could increase the value and your profit.
Stop and think for ten minutes what you would like to see. Voltage, current, time plots, errors, etc. It would take your programmer a day to install. The chips and ram needed are extremely cheap and don't take much space. You would own the world.
Normally you would want a fixed character size for that sort of thing (for every sort of thing if you ask me unless you want to be artistic). I usually do 8x12 pixels, which in your case would be smallish, 0.12mm.
So your best approach would be to go 4 physical pixels into one logical one and do 8x12, this would mean 25 symbols per line, 20 lines. If this is not enough you can still go for the 0.12mm pixel and get
50 symbols/40 lines but people past say 55 will need spectacles to read that. Don't fall for blurry scaling, make sure each character has the same pixel representation anywhere on the display.
You can use my character set (I made it around 1985...),
formatting link
, people don't complain about it and this won't be the first time I declare it "use for free". If you go for it let me know, I can send you the binary bitmap.
Well, ten characters per inch and five lines per vertical inch is readable. Typewriter spacing...
More to the point, why do a new screen and protocol for a new box? Could you go to USB or Bluetooth for the communication, and source a display (like a tablet, or electronic picture frame, or just an app for a cellphone) that has builtin software support?
Doesn't it make more sense to use a mass-produced standard software target instead of a novel build-from-sticks hardware assembly?
USB interface is a good idea. However, you need a computer which is not so useful for rack mount installations. Also, you must download and install the software on each computer that could be used. Microsoft 11 is making it very difficult to install non-approved software. You can run linux, but then you need a version of software that runs on different flavors. You could attach to a smartphone, but again you need different versions. You could use bluetooth instead of USB, but you still have to download and install software for sifferent hosts.
Running software on a host computer is a very bad idea.
short answer: get a Snellen Eye chart; Your characters size should be at least as those at the 20:20 (6:6 in EU) line For easy readability use double that (20:40)
longer answer: The characters need to be large enough to be distinguishable from one another, from a stated maximum viewing distance, by your intended user. First I assume your letters & numbers use a simple block type font (sans serif). characters are high contrast (black on white background, or vice versa). that white part of the image luminance is a comfortable brightness range. the pixels constructing the characters are small, not visible at the viewing distance. the person has with 20:20 vision (6:6 in EU). (Apply formula here - to lazy to look it up)
To the degree you vary from these assumptions, the size should be increased.
From what distance? I.e., when you put a display ON a bit of kit, you are essentially defining how/where you expect the user to interact with it. If the user has other ideas, he's SoL (or, your sale is lost to a competitor that accommodates his needs).
Unless you are painting on a predefined "virtual display", you're going to end up designing some display software.
Increasingly (almost to the point of being ubiquitous), devices are shedding *their* displays in favor of some "remote" display/control capability. Devices look, more and more, like client (or, servers if you're uncomfortable with the display-as-server model).
I.e., you expose the interface to the "back end". This leaves you with the task of designing a server that can harvest the information desired and present it on *it's* UI.
And, if you stop thinking like an equipment manufacturer but, instead, see your role in a *system*, then you can imagine the UI might NOT want to conform to your idea of what the user *might* want to see on a screen and, instead, let the user *build* an interface that suits his needs.
Possibly simultaneously displaying information from other devices (of which you may be ignorant!).
Isn't it annoying to have to deal with a variety of devices, each with their own notion of *how* you should interact with them?
[Do you display the time-of-day? date? what timezone? what format? etc. Do you really want to be making that decision for the user and annoying him at your lack of foresight for *his* needs? "Why are the timestamps on your device skewed with respect to those on this other device?"]
When I designed the UI for my disk sanitizer, I initially tried to cram as much information on a "standard" display as possible. So, an "operator" could look at the state of all 60 disks at once in order to get an idea as to their progress, completion times, failure rates, etc.
But, there are countless collections of data that might be of interest; what if the Operator wanted to focus on a *single* disk? What if he wanted to see it's historical performance depicted graphically instead of a "current state"? What if he wanted to *compare* two disks to highlight differences? What if he has a second such system -- another
60 spindles -- that he wants to monitor from the same point? What if that point is his *home* (cuz he doesn't want to sit around for
13 hours waiting for the process to play out)? etc.
So, the smart solution is to separate the display from the device and, once that connection has been abstracted/virtualized, spend effort on ADDING VALUE to the UI beyond what you *thought* was appropriate.
86 the hardware as you can buy something COTS for less dollars.
But, the software will likely still remain. If you plan well, you can write it portably to address a variety of likely "presentation devices" -- just like web pages that display on tablets, phones, PCs, etc.
The effort can then be leveraged, going forward, for other devices you produce.
For what timeframe? Where will USB be in 10 years? Will you even be able to buy a computer with a USB interface?
That's ancient thinking. You need "something" to act as an agent between the display and device. If you think in terms of a single device, then there is pressure to integrate that agent in the device -- or the display.
But, it can reside in a third location -- one that is more accessible to a variety of devices and displays!
E.g., let <something> talk to your devices and (possibly) present a web interface to *any* hardware UI (tablet, PC, phone) that wants to interact with your device. Now, you care less about Android vs. iOS; Mac vs. PC; computer vs phone; big vs small screen; etc.
And, solve that problem *once* and it won't care when your Windows 27 PC with *3D* display comes along!
Or most likely his box has a zynq running linux on one processor. Then it just needs a USB connector on his card.
Running linux solves a lot of mess with writing your own software for anything other than your application.
I like the way Larkin asks us what length string he should use without any details on what he needs. My preference these days is to make text as large as possible. So the text size would depend on what is required to be displayed and what will fit.
Any smart device in a big rackmount box has probably got some microprocessor inside (what generates the characters otherwise?). What I'm wondering, is if there's a USB-slave display device, with non-proprietary standard I/O protocols, that can serve. Displays can fail, it'd be nice if they were easy to replace ten years from now. Can you get a replacement for a ten-year-old black/white LCD, and its attached backlight nowadays? Pin-compatible? For a USB mouse or keyboard, you CAN get the replacement.
Doesn't have to be USB, of course; bluetooth board in an Arduino would also suffice to drive a slide-show (slow changing) display. It'd need a power supply, too, then. Firewire would have been perfect (lots of bus power available, isochronous transport), but it's kinda dead these days.
Oh, no, the whole purpose is defeated if you put a bunch of licensed specific-version general-purpose-computer OS software in the middle. It's a tethered display problem, devoid of a deep string of software dependencies, that is under consideration.
I want a kind of micro- display standard socket. It could be TTY emulator, or VGA. That can be supported long-term.
I presume you mean a remote server computer? Well, yeah. Go too deep with infrastructure, then Ukraine gets invaded and Ne gas becomes unobtainium...
I could do something like 50x24 or 50x20 chars on my 800x480 LCD.
That's actually a lot for my power supply thing. I might have as many as 8 channels per board/screen, one line each. Or even 12.
I was trying to guess how many chars might work X and Y first.
We could design the screens with Word and a fixed-pitch font, text in a box or something.
The box will use a microZed board, running linux. The display controller will be an FT800 chip, with an SPI interface from the zed. We've done this before, just not with such a giant display.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.