LCD character size

On 3/5/2022 4:10 PM, whit3rd wrote:
> On Saturday, March 5, 2022 at 1:44:49 PM UTC-8, Mike Monett wrote:
>> whit3rd <whi...@gmail.com> wrote:
> 
>>> 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?
> 
>> USB interface is a good idea. However, you need a computer which is not so
>> useful for rack mount installations.
> 
> 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.

*Today*.  That's not to say you will be able to, some years from now.
(unless the device you are building has an inherent lifespan limitation
or is disposable -- or, the vendor wants to be in the USB mice business!).
I have bits of test equipment that used floppies (oops!), 5 pin XT keyboards
(oops!), 25 pin serial ports (oops), etc.

The *virtual* interface is the thing you should strive to preserve as it
can be adapted to future technologies.  HP was smart enough to realize
this **decades** ago (HPIB).  Once developed/supported, it is a lead-pipe
cinch to add it to other devices (and, benefit users who have adopted it!)

[And, find other *software* vendors to build tools to create custom
interfaces to a *suite* of devices]

Exposing it also offers other possibilities:  e.g., capturing data/sessions
(without having to buy a "data capture option").  I have all of my test
equipment tethered together so I can automate and document various processes.

E.g., bring up the power supplies for "product X", monitor loads on each
(having already set limits in the supplies established for THIS product)
to catch any gross faults.  Load excitation waveform in ARB.  Set DSO to
capture device's response.  Begin experiment (recording)...  archive to disk.

Remove DUT.  Select different "recipe/script" for product *Y*  ...

No need to wonder what data I *should* archive or lament NOT having archived
some particular observation/control in the past... it's all *free*!  (along 
with a chronology of what happened when -- disk space is cheap)  Unless, of
course, it's a "dumb" bit of test kit!

And, *not* have to waste bench space making all of these devices physically
accessible ... just so I can see their displays and twiddle their knobs!
(why?  I have access to ALL of that -- on every device -- from a SINGLE
console!)

And, I can access those things from any network drop, not just a specific
computer/workstation (though the computer with the GPIB interface has to
be "up" to act as bridge).

> 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.

How many such devices do you expect to be able to support, in close proximity?

Will other items in the environment interfere with reliable (wireless) comms?

[I suspect we're going to see undesirable interactions between wireless devices
as the move *away* from wired interfaces continues.  You can, already, get the
data AND power connections to USB devices without the cable.  How much longer
before that i/f is obsolescent?  The connectors keep getting smaller and
smaller... when will they occupy *zero* space?  Once wireless charging becomes
ubiquitous, how many folks are going to want to rely on a cabled interface
for all these little devices??  RS232 survived ~60 years, in various forms.
ST506?  IDE?  SASI/SCSI?  SATA?  1394?  SAS?  USB?  Particularly as the devices
typically *relying* on those connectors are effectively "disposable" (no
"investment" at stake)]

Plus, anytime you separate the UI from device, you raise the prospect of them
getting out of sync, races -- or, worse, the interface crashing and the user
not being able to determine that to be the case!  ("Wow!  Things have been
rock steady for the past 13 minutes!"  "No, the display hasn't been *updated*
in that long!"  i.e., the virtual interface has to present "something" that
user can use to determine if the link is still intact and content "current")

>> 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 ...
> 
> 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.

You can design the UI to be a web interface and the details of the OS, browser,
etc. all fall out of the equation (assuming you pick a stable/persistent HTML
version).  Because the interface protocols are "well established".  (Not true
between your backend and UI *inside* a device)

[The UniSite addressed this (1980?) by relying on ANSI3.64.  So, to this day,
I can interact with one (via tip(1) into a tty with an appropriate $TERM)
But, I can't alter what is presented nor how it is presented -- as all of
that is locked up in the device's back-end]

But, then you have to put the "web server" somewhere -- in the device or in the
computer.  Or, in ANOTHER *headless* computer that acts as agent between them
(and has all the appropriate hardware to interact with the variety of such
devices you own).

> I want a kind of micro- display standard socket.  It could be TTY emulator, or VGA.
> That can be supported long-term.

You can buy USB "display adapters".  Plug an LCD display into it.

But, you still need something to decide "what goes where, on the display".
And, are prone to display resolution/aspect ratio changes.  (the web
interface would minimize this -- if pages were designed properly)

And, have to hope the "coder" picked an appropriate set of data and
layout to meet *your* needs.

>> Running software on a host computer is a very bad idea.
> 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 suspect he is thinking that the UI is an "app" that has to be installed
on a computer -- that also acts as the (hardware) display device.  So,
users find themselves chasing the "supported" platforms.

[If you can dedicate a computer to be this agent (for a SUITE of devices),
then you're not faced with wanting to upgrade its OS (to accommodate some
other app) and thereby rendering the old software "unsupported on this OS".
As you've said, "computers" are now tiny/cheap/ubiquitous.  And, can be
replaced/upgraded a lot easier than some proprietary software INSIDE a
device.]

And, unless the device can masquerade as an OTS device (e.g., "mass storage"),
there's likely a custom driver involved.  (same problem as above, only worse)

On a sunny day (Sat, 05 Mar 2022 15:48:33 -0800) it happened
jlarkin@highlandsniptechnology.com wrote in
<46s72h94am11ll89gpavkgsldg3h7oj4pd@4ax.com>:

>>If you do not need graphics then that resolution is probably overkill
>>
>>128x64 LCD:
>> http://panteltje.com/pub/gamma_soectrometer_IMG_4505.JPG
>>
>>640x480 same font...
>> http://panteltje.com/pub/xvtx-p.gif
>
>Is that 40x20 characters? Looks readable.

Yes, 40x20, is the 'teletext' videotext / ceefax standard
but I display 4 screens in 640x480, and you can click on the page numbers.

The font I use
#define TXT_CHAR_WIDTH  8
#define TXT_CHAR_HEIGHT 9

Using it for most Microchip PIC projects too, OLED:
 http://panteltje.com/pub/SWR_bridge_IMG_5051.JPG




>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.
>
>>
>>Make a drawing to size first?
>
>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.
>
>>
>>There are a million fonts to chose from, some are free.
>>Some LCDs have their own character set.
>>Does it run an OS? Linux Xwindows has many fonts
>>
>
>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.


960x800 in Linux X on a        Raspberry Pi 4, same font as before:
 http://panteltje.com/pub/xflir_bar.gif
  alarm from cenral heating radiator now, it also detects humans.

Accepts keys, has help menu:
 http://panteltje.com/pub/xflir_help.gif
   I should change that to double height double width characters perhaps.

Thing runs about 5 frames per second here from that FLIR camera via i2c,
but it is not much data: 24x32 pixels.

Yes SPI will not be as fast, I write directly to the X buffer here,
the raspi has HDMI out to the monitor.


Have you ever considered Raspberry Pis?
Very fast the Pi4, but as with many things these days hard to find a seller that has any in stock.

I have a cheap HDMI LCD from ebay somewhere, lemme see, was something like this (not same panel, there are many):
 https://www.ebay.com/itm/134043252136

On a sunny day (Sat, 5 Mar 2022 14:04:12 -0800 (PST)) it happened Rich S
<richsulinengineer@gmail.com> wrote in
<7a6583bc-6d51-4c14-82db-051b4101fdebn@googlegroups.com>:

>> To the degree you vary from these assumptions, the size should be 
>> increased.
>
>w = 2 * d * tan (2.5 arcmin)
>
>so if d = 6 feet = 72 in., then w = 0.0175"
>
>formula from here
>https://en.wikipedia.org/wiki/Snellen_chart

Add voice output
"Current exceeding maximum, system will self-destruct in 10 seconds
  safe distance 30 miles"
"Clap hands to abort."

:-)

Yes I have voice on some projects.

On a sunny day (Sat, 5 Mar 2022 14:51:28 -0800 (PST)) it happened Rick C
<gnuarm.deletethisbit@gmail.com> wrote in
<467b8489-bef9-4b75-b018-1111104f8437n@googlegroups.com>:
>> There are a million fonts to chose from, some are free. 
>> Some LCDs have their own character set. 
>> Does it run an OS? Linux Xwindows has many fonts
>
>You are going to hate life when you develop presbyopia.  

Googke:
 Presbyopia is the gradual loss of your eyes' ability to focus on nearby objects.
 It's a natural, often annoying part of aging.
  Presbyopia usually becomes noticeable in your early to mid-40s and continues to worsen until around age 65.

No worry I am way and way past that age :-)
Reading glasses are just a few dollars from the local drugstore.
I put 2 on top of each other to do nano-nano electronics soldering.

On 2022-03-05 20:25, jlarkin@highlandsniptechnology.com wrote:
> We're designing a new rackmount box, basicly a fancy power supply,
> with an 800x480 4.3" LCD on the front. Roughly this:
> 
> https://www.dropbox.com/s/8ubv5if7cbnsjzn/P940-8_front.jpg?raw=1
> 
> 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.

Something like this instrument?

<https://www.artisantg.com/TestMeasurement/63548-1/Muetta-PLPS-2005-Programmable-Laser-Power-Supply>
<https://www.ebay.com/itm/323745466247?hash=item4b60bbc787:g:HQAAAOxytdlRAg3f>

I'm the hardware designer, and wonder how the hell they got hold of my 
schematics: <https://www.artisantg.com/info/Muetta_PLPS2005_Schematic.pdf>

See the user manual for the 'screenshots':
<https://www.artisantg.com/info/Muetta_PLPS2005_Manual.pdf>

Werner Damman wrote most of the software and the user manual. And put an 
easter egg inside...

We designed the PLSP2005 user interface up front, to be sure that LCD 
panel would be sufficient.

They are still being sold: 
<https://www.ebay.com/sch/i.html?_from=R40&_trksid=p2047675.m570.l1313&_nkw=PLPS2005&_sacat=0>


Artisan has more of the stuff I designed: 
<https://www.artisantg.com/PLC/61295-1/Muetta-SSL-T9-Motor-Controller> 
which is definitely NOT a motor controller, it is a simplified single 
channel of the PLPS architecture, 20..60 in a rack, with a single 
processor board driving the bus to acquire data. Useless without the 
rack and processor.


Arie de Muijnck

On Sun, 06 Mar 2022 08:29:26 GMT, Jan Panteltje
<pNaonStpealmtje@yahoo.com> wrote:

>On a sunny day (Sat, 05 Mar 2022 15:48:33 -0800) it happened
>jlarkin@highlandsniptechnology.com wrote in
><46s72h94am11ll89gpavkgsldg3h7oj4pd@4ax.com>:
>
>>>If you do not need graphics then that resolution is probably overkill
>>>
>>>128x64 LCD:
>>> http://panteltje.com/pub/gamma_soectrometer_IMG_4505.JPG
>>>
>>>640x480 same font...
>>> http://panteltje.com/pub/xvtx-p.gif
>>
>>Is that 40x20 characters? Looks readable.
>
>Yes, 40x20, is the 'teletext' videotext / ceefax standard
>but I display 4 screens in 640x480, and you can click on the page numbers.
>
>The font I use
>#define TXT_CHAR_WIDTH  8
>#define TXT_CHAR_HEIGHT 9
>
>Using it for most Microchip PIC projects too, OLED:
> http://panteltje.com/pub/SWR_bridge_IMG_5051.JPG
>
>
>
>
>>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.
>>
>>>
>>>Make a drawing to size first?
>>
>>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.
>>
>>>
>>>There are a million fonts to chose from, some are free.
>>>Some LCDs have their own character set.
>>>Does it run an OS? Linux Xwindows has many fonts
>>>
>>
>>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.
>
>
>960x800 in Linux X on a        Raspberry Pi 4, same font as before:
> http://panteltje.com/pub/xflir_bar.gif
>  alarm from cenral heating radiator now, it also detects humans.
>
>Accepts keys, has help menu:
> http://panteltje.com/pub/xflir_help.gif
>   I should change that to double height double width characters perhaps.
>
>Thing runs about 5 frames per second here from that FLIR camera via i2c,
>but it is not much data: 24x32 pixels.
>
>Yes SPI will not be as fast, I write directly to the X buffer here,
>the raspi has HDMI out to the monitor.

SPI isn't bad into the FT800 controller chip. It's pretty smart.

>
>
>Have you ever considered Raspberry Pis?
>Very fast the Pi4, but as with many things these days hard to find a seller that has any in stock.

The uZed has a Zynq chip, a lot of FPGA and two 600 MHz ARM cores. We
need the FPGA. We could use a pi for things that don't need that much
signal processing, but we usually need an FPGA.

The FT800 controller chips are hard to get, but their demo boards,
with LCD, are available, so we did one box that used the demo board
for the display. It was destined to be ugly anyhow.

https://www.dropbox.com/s/vjzhoths9v55gpq/Man_Front_1.jpg?raw=1

>
>I have a cheap HDMI LCD from ebay somewhere, lemme see, was something like this (not same panel, there are many):
> https://www.ebay.com/itm/134043252136


-- 

I yam what I yam - Popeye

On a sunny day (Sun, 06 Mar 2022 07:33:53 -0800) it happened
jlarkin@highlandsniptechnology.com wrote in
<qek92h9r2ndruf4rhceoi6sh2cbnbmui3v@4ax.com>:

>On Sun, 06 Mar 2022 08:29:26 GMT, Jan Panteltje
><pNaonStpealmtje@yahoo.com> wrote:
>
>>On a sunny day (Sat, 05 Mar 2022 15:48:33 -0800) it happened
>>jlarkin@highlandsniptechnology.com wrote in
>><46s72h94am11ll89gpavkgsldg3h7oj4pd@4ax.com>:
>>
>>>>If you do not need graphics then that resolution is probably overkill
>>>>
>>>>128x64 LCD:
>>>> http://panteltje.com/pub/gamma_soectrometer_IMG_4505.JPG
>>>>
>>>>640x480 same font...
>>>> http://panteltje.com/pub/xvtx-p.gif
>>>
>>>Is that 40x20 characters? Looks readable.
>>
>>Yes, 40x20, is the 'teletext' videotext / ceefax standard
>>but I display 4 screens in 640x480, and you can click on the page numbers.
>>
>>The font I use
>>#define TXT_CHAR_WIDTH  8
>>#define TXT_CHAR_HEIGHT 9
>>
>>Using it for most Microchip PIC projects too, OLED:
>> http://panteltje.com/pub/SWR_bridge_IMG_5051.JPG
>>
>>
>>
>>
>>>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.
>>>
>>>>
>>>>Make a drawing to size first?
>>>
>>>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.
>>>
>>>>
>>>>There are a million fonts to chose from, some are free.
>>>>Some LCDs have their own character set.
>>>>Does it run an OS? Linux Xwindows has many fonts
>>>>
>>>
>>>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.
>>
>>
>>960x800 in Linux X on a        Raspberry Pi 4, same font as before:
>> http://panteltje.com/pub/xflir_bar.gif
>>  alarm from cenral heating radiator now, it also detects humans.
>>
>>Accepts keys, has help menu:
>> http://panteltje.com/pub/xflir_help.gif
>>   I should change that to double height double width characters perhaps.
>>
>>Thing runs about 5 frames per second here from that FLIR camera via i2c,
>>but it is not much data: 24x32 pixels.
>>
>>Yes SPI will not be as fast, I write directly to the X buffer here,
>>the raspi has HDMI out to the monitor.
>
>SPI isn't bad into the FT800 controller chip. It's pretty smart.
>
>>
>>
>>Have you ever considered Raspberry Pis?
>>Very fast the Pi4, but as with many things these days hard to find a seller that has any in stock.
>
>The uZed has a Zynq chip, a lot of FPGA and two 600 MHz ARM cores. We
>need the FPGA. We could use a pi for things that don't need that much
>signal processing, but we usually need an FPGA.

The Pi will give you WiFi and bluetooth, although not from inside a metal box.
If you wanted to make a smartphone app... run as a server perhaps.
I have one old Pi running as server with a navigation program.


>The FT800 controller chips are hard to get, but their demo boards,
>with LCD, are available, so we did one box that used the demo board
>for the display. It was destined to be ugly anyhow.
>
>https://www.dropbox.com/s/vjzhoths9v55gpq/Man_Front_1.jpg?raw=1

Looks nice.
Things change fast, I had some trouble to find a replacement LCD for my lab power supply that used the same controller.
In the same way the new i2c OLED modules need a different initialization routine than the old ones.
Try as little as possible to depend on libraries, people do change those all the time, not always for the better.
Also then porting code to other systems is easier.

On Sunday, March 6, 2022 at 10:58:23 AM UTC-5, Jan Panteltje wrote:
> On a sunny day (Sun, 06 Mar 2022 07:33:53 -0800) it happened 
> jla...@highlandsniptechnology.com wrote in 
> <qek92h9r2ndruf4rh...@4ax.com>:
> >On Sun, 06 Mar 2022 08:29:26 GMT, Jan Panteltje 
> ><pNaonSt...@yahoo.com> wrote: 
> > 
> >>On a sunny day (Sat, 05 Mar 2022 15:48:33 -0800) it happened 
> >>jla...@highlandsniptechnology.com wrote in 
> >><46s72h94am11ll89g...@4ax.com>: 
> >> 
> >>>>If you do not need graphics then that resolution is probably overkill 
> >>>> 
> >>>>128x64 LCD: 
> >>>> http://panteltje.com/pub/gamma_soectrometer_IMG_4505.JPG 
> >>>> 
> >>>>640x480 same font... 
> >>>> http://panteltje.com/pub/xvtx-p.gif 
> >>> 
> >>>Is that 40x20 characters? Looks readable. 
> >> 
> >>Yes, 40x20, is the 'teletext' videotext / ceefax standard 
> >>but I display 4 screens in 640x480, and you can click on the page numbers. 
> >> 
> >>The font I use 
> >>#define TXT_CHAR_WIDTH 8 
> >>#define TXT_CHAR_HEIGHT 9 
> >> 
> >>Using it for most Microchip PIC projects too, OLED: 
> >> http://panteltje.com/pub/SWR_bridge_IMG_5051.JPG 
> >> 
> >> 
> >> 
> >> 
> >>>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. 
> >>> 
> >>>> 
> >>>>Make a drawing to size first? 
> >>> 
> >>>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. 
> >>> 
> >>>> 
> >>>>There are a million fonts to chose from, some are free. 
> >>>>Some LCDs have their own character set. 
> >>>>Does it run an OS? Linux Xwindows has many fonts 
> >>>> 
> >>> 
> >>>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. 
> >> 
> >> 
> >>960x800 in Linux X on a Raspberry Pi 4, same font as before: 
> >> http://panteltje.com/pub/xflir_bar.gif 
> >> alarm from cenral heating radiator now, it also detects humans. 
> >> 
> >>Accepts keys, has help menu: 
> >> http://panteltje.com/pub/xflir_help.gif 
> >> I should change that to double height double width characters perhaps. 
> >> 
> >>Thing runs about 5 frames per second here from that FLIR camera via i2c, 
> >>but it is not much data: 24x32 pixels. 
> >> 
> >>Yes SPI will not be as fast, I write directly to the X buffer here, 
> >>the raspi has HDMI out to the monitor. 
> > 
> >SPI isn't bad into the FT800 controller chip. It's pretty smart. 
> > 
> >> 
> >> 
> >>Have you ever considered Raspberry Pis? 
> >>Very fast the Pi4, but as with many things these days hard to find a seller that has any in stock. 
> > 
> >The uZed has a Zynq chip, a lot of FPGA and two 600 MHz ARM cores. We 
> >need the FPGA. We could use a pi for things that don't need that much 
> >signal processing, but we usually need an FPGA.
> The Pi will give you WiFi and bluetooth, although not from inside a metal box. 
> If you wanted to make a smartphone app... run as a server perhaps. 
> I have one old Pi running as server with a navigation program.
> >The FT800 controller chips are hard to get, but their demo boards, 
> >with LCD, are available, so we did one box that used the demo board 
> >for the display. It was destined to be ugly anyhow. 
> > 
> >https://www.dropbox.com/s/vjzhoths9v55gpq/Man_Front_1.jpg?raw=1
> Looks nice. 

To me the text is a bit squinty.   It looks like the opening is a LOT larger than the screen.  Why not a bigger screen giving bigger text?  The text on the front panel that will be read practically never is much larger yet.  Even the labels on the button are much larger than the screen text.   This is the typical engineer mistake in UIs. 


> Things change fast, I had some trouble to find a replacement LCD for my lab power supply that used the same controller. 
> In the same way the new i2c OLED modules need a different initialization routine than the old ones. 
> Try as little as possible to depend on libraries, people do change those all the time, not always for the better. 
> Also then porting code to other systems is easier.

Great reason to use an integrated device with it's own controller, connected by a simple protocol... like a modern TTY, rather than integrating a controller into the internal electronics of the box.  I bet if you look around there's a defacto standard for these things.  It looks to me like a 7 inch screen is very common.  I expect you can find integrated devices in that size. 

-- 

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

On a sunny day (Sun, 6 Mar 2022 09:14:11 -0800 (PST)) it happened Rick C
<gnuarm.deletethisbit@gmail.com> wrote in
<ac75a281-286d-487f-a80e-0cd6579e5d81n@googlegroups.com>:

>than the screen.  Why not a bigger screen giving bigger text?  The text on
>the front panel that will be read practically never is much larger yet.  Even
>the labels on the button are much larger than the screen text.   This is
>the typical engineer mistake in UIs.

One funny thing is that if you wrote say a program size 640x480
and over the years the monitor resolution has grown to 1920x1080 
then your application looks really small (3x) on the same physical size monitor.
Of course some programs have a re-size option but not all.

  
>> Things change fast, I had some trouble to find a replacement LCD for my lab
>power supply that used the same controller.
>> In the same way the new i2c OLED modules need a different initialization routine
>than the old ones.
>> Try as little as possible to depend on libraries, people do change those all
>the time, not always for the better.
>> Also then porting code to other systems is easier.
>
>Great reason to use an integrated device with it's own controller, connected
>by a simple protocol... like a modern TTY, rather than integrating a controller
>into the internal electronics of the box.  I bet if you look around there's
>a defacto standard for these things.  It looks to me like a 7 inch screen
>is very common.  I expect you can find integrated devices in that size.

All depends, if you have a single chip (I use for example PIC 18F14K22 a lot)
driving some display and write the code in asm, you have work to do if they change
controller for the display.
Using the small HDMI color LCDs is indeed a standard interface.
But then you have to fight with XLib..

On Sun, 06 Mar 2022 17:42:18 GMT, Jan Panteltje
<pNaonStpealmtje@yahoo.com> wrote:

>On a sunny day (Sun, 6 Mar 2022 09:14:11 -0800 (PST)) it happened Rick C
><gnuarm.deletethisbit@gmail.com> wrote in
><ac75a281-286d-487f-a80e-0cd6579e5d81n@googlegroups.com>:
>
>>than the screen.  Why not a bigger screen giving bigger text?  The text on
>>the front panel that will be read practically never is much larger yet.  Even
>>the labels on the button are much larger than the screen text.   This is
>>the typical engineer mistake in UIs.
>
>One funny thing is that if you wrote say a program size 640x480
>and over the years the monitor resolution has grown to 1920x1080 
>then your application looks really small (3x) on the same physical size monitor.
>Of course some programs have a re-size option but not all.
>

It's usual on an instrument to have fairly chunky fonts for pushbutton
and connector labels, and smaller, sometimes tiny, size text on an
LCD.

I guess Tek and Rigol and Keysight don't understand the rules noted
here.



-- 

I yam what I yam - Popeye