LCD character size...

[Rick C]

On Saturday, March 5, 2022 at 6:10:53 PM UTC-5, whit3rd wrote:

On Saturday, March 5, 2022 at 1:44:49 PM UTC-8, Mike Monett wrote:
whit3rd <whi...@gmail.com> wrote:

On Saturday, March 5, 2022 at 11:25:51 AM UTC-8,
jla...@highlandsniptechnology.com wrote:
We\'re designing a new rackmount box, basicly a fancy power supply,
with an 800x480 4.3\" LCD on the front.
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.

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

I want a kind of micro- display standard socket. It could be TTY emulator, or VGA.
That can be supported long-term.
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 don\'t know why you guys make this so difficult. Raspberry Pi is as much a standard as any other formal standard.

https://www.dfrobot.com/product-1784.html

Use this as shown with an rPi piggybacked providing a USB port and you will be able to replace the entire assemblage with a similar unit with whatever rPi is being sold for the next 20 years... and yes, as someone asked, USB will be around longer than RS-232 was popular, partly because it is such a popular standard, and partly because it is so versatile with universally available connectors, etc., etc., etc.

--

Rick C.

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

 

[Don Y]

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)

 

[Jan Panteltje]

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

 

[Jan Panteltje]

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.

 

[Jan Panteltje]

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.

 

[Arie de Muijnck]

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

 

[server]

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

 

[Jan Panteltje]

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.

 

[Rick C]

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

 

[Jan Panteltje]

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

 

[server]

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

 

[Rick C]

On Sunday, March 6, 2022 at 12:42:22 PM UTC-5, Jan Panteltje wrote:

On a sunny day (Sun, 6 Mar 2022 09:14:11 -0800 (PST)) it happened Rick C
gnuarm.del...@gmail.com> wrote in
ac75a281-286d-487f...@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.

I don\'t think there is going to be a 1920 resolution 4 inch display, ever. Even if there was, the old resolution would always be available. Larkin is using 800x640 I believe. Good resolution even for a 7 inch display. I don\'t think that will become obsolete.

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

Fight? I guess there are no good programmers left in the world. It\'s a shame.

I don\'t know why you are talking about using a PIC in such an application. Larkin is running Linux in his box. There\'s no reason why the display can\'t have its own CPU, as I said, something like an rPi, but integrated with the display. Connect the two with USB or SPI or even RS-232. None of those are going away anytime soon.

The advantage of an integrated display is it does not require changes on the controlling unit if you change the display. You talk to the display as if it were a terminal. Can\'t get much simpler than that.

--

Rick C.

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

 

[Rick C]

On Sunday, March 6, 2022 at 1:03:38 PM UTC-5, jla...@highlandsniptechnology.com wrote:

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

On a sunny day (Sun, 6 Mar 2022 09:14:11 -0800 (PST)) it happened Rick C
gnuarm.del...@gmail.com> wrote in
ac75a281-286d-487f...@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.

You mean displays where the important parts are the graphs and the icons? Yes, they have to shrink the text to fit the display area. Same with buttons. Looks to me like the panel text is not bigger than much of the display text.

https://www.rigolna.com/images/products/MSO5000.jpg

What are the labels on the knobs on the Horizontal section? That frequency in the display is easy enough to read.

--

Rick C.

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

 

[Lasse Langwadt Christensen]

søndag den 6. marts 2022 kl. 19.45.32 UTC+1 skrev gnuarm.del...@gmail.com:

On Sunday, March 6, 2022 at 12:42:22 PM UTC-5, Jan Panteltje wrote:
On a sunny day (Sun, 6 Mar 2022 09:14:11 -0800 (PST)) it happened Rick C
gnuarm.del...@gmail.com> wrote in
ac75a281-286d-487f...@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.
I don\'t think there is going to be a 1920 resolution 4 inch display, ever..

cell phone screens are in that range

 

[server]

On Sun, 6 Mar 2022 11:28:16 -0800 (PST), Lasse Langwadt Christensen
<langwadt@fonz.dk> wrote:

søndag den 6. marts 2022 kl. 19.45.32 UTC+1 skrev gnuarm.del...@gmail.com:
On Sunday, March 6, 2022 at 12:42:22 PM UTC-5, Jan Panteltje wrote:
On a sunny day (Sun, 6 Mar 2022 09:14:11 -0800 (PST)) it happened Rick C
gnuarm.del...@gmail.com> wrote in
ac75a281-286d-487f...@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.
I don\'t think there is going to be a 1920 resolution 4 inch display, ever.

cell phone screens are in that range

The character pitch on the home page of my phone is about 0.05 inch;
some text like the mini weather report is even smaller. 80 chars
across on my 4\" wide LCD should be readable.

My phone is 760 x 360 pix. My LCD will be 800x480. So a phone is a
pretty good test bed for instrument display fonts.

I\'ve got to stop thinking about 7-seg LEDs and 16-seg VFs.



--

I yam what I yam - Popeye

 

[Rick C]

On Sunday, March 6, 2022 at 2:28:24 PM UTC-5, lang...@fonz.dk wrote:

søndag den 6. marts 2022 kl. 19.45.32 UTC+1 skrev gnuarm.del...@gmail.com:
On Sunday, March 6, 2022 at 12:42:22 PM UTC-5, Jan Panteltje wrote:
On a sunny day (Sun, 6 Mar 2022 09:14:11 -0800 (PST)) it happened Rick C
gnuarm.del...@gmail.com> wrote in
ac75a281-286d-487f...@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.
I don\'t think there is going to be a 1920 resolution 4 inch display, ever.
cell phone screens are in that range

I couldn\'t find a 4 inch cell phone, but I did find a 4.3 inch HD LCD on ebay. That makes the pixels around 70 nm or 360 to the inch. So they exist, but are extreme overkill for most LCD applications. That doesn\'t validate the idea they will take over and make it impossible to find the 800x480 display Larkin wants to use. 480x272 seems to be the most common format and LCDs have a tendency to support a given format forever because the cost factor isn\'t changing much with time and more dense displays are always more expensive to make.

Besides, the resolution is irrelevant. That\'s the responsibility of the controller. You don\'t need to send pixel based commands. That is a silly way to control an LCD from high level code on the main processor. For this application a controller processor should be emulating a virtual terminal. Even an ADM-3A would do this job just fine. However, something a bit more sophisticated could provide multiple type faces with different sizes.

I turned a small (12\" maybe) TV into a terminal display once. I think it used two optoisolators and a microprocessor. I expect a video display chip was used as well. It could get some pretty small fonts with up to 64 characters across. But my eyes worked a charm back then. There\'s no way I could use something that small and low resolution now.

--

Rick C.

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

 

[Rick C]

On Sunday, March 6, 2022 at 4:10:02 PM UTC-5, jla...@highlandsniptechnology..com wrote:

On Sun, 6 Mar 2022 11:28:16 -0800 (PST), Lasse Langwadt Christensen
lang...@fonz.dk> wrote:

søndag den 6. marts 2022 kl. 19.45.32 UTC+1 skrev gnuarm.del...@gmail.com:
On Sunday, March 6, 2022 at 12:42:22 PM UTC-5, Jan Panteltje wrote:
On a sunny day (Sun, 6 Mar 2022 09:14:11 -0800 (PST)) it happened Rick C
gnuarm.del...@gmail.com> wrote in
ac75a281-286d-487f...@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.
I don\'t think there is going to be a 1920 resolution 4 inch display, ever.

cell phone screens are in that range
The character pitch on the home page of my phone is about 0.05 inch;
some text like the mini weather report is even smaller. 80 chars
across on my 4\" wide LCD should be readable.

Readable by whom?

My phone is 760 x 360 pix. My LCD will be 800x480. So a phone is a
pretty good test bed for instrument display fonts.

I\'ve got to stop thinking about 7-seg LEDs and 16-seg VFs.

Use a simple processor to manage the display as a separate entity. Then the display is decoupled from the rest of the system. You can probably find something that is already programmed and just needs a serial character stream with CRLF and FF.

--

Rick C.

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

 

[Jan Panteltje]

On a sunny day (Sun, 6 Mar 2022 10:45:25 -0800 (PST)) it happened Rick C
<gnuarm.deletethisbit@gmail.com> wrote in
<5cd1f698-776b-4f88-80ba-3edc4d126b17n@googlegroups.com>:

On Sunday, March 6, 2022 at 12:42:22 PM UTC-5, Jan Panteltje wrote:
On a sunny day (Sun, 6 Mar 2022 09:14:11 -0800 (PST)) it happened Rick C

Using the small HDMI color LCDs is indeed a standard interface.
But then you have to fight with XLib..

Fight? I guess there are no good programmers left in the world. It\'s a shame.

You babble a lot and do not listen
Show us ONE program you wrote for X !
There was Xfree, then that got screwed up
all the related libraries have been broken over time, example libforms (wrote many many programs in it)
Old Xwindows code that works fine in XFree no longer does in X.Org
Here some history, good luck porting your stuff:
https://en.wikipedia.org/wiki/XFree86

don\'t know why you are talking about using a PIC in such an application.
Larkin is running Linux in his box. There\'s no reason why the display can\'t
have its own CPU, as I said, something like an rPi, but integrated with the
display. Connect the two with USB or SPI or even RS-232. None of those
are going away anytime soon.

Look dude I posted even a link to an HDMI LCD display

Stop twitching
Show us some code you wrote ror even somthing like that you build.

 

[Jan Panteltje]

On a sunny day (Sun, 06 Mar 2022 10:03:22 -0800) it happened
jlarkin@highlandsniptechnology.com wrote in
<8et92hd8uo0u2a3h70vmkl5ntp3lkfikki@4ax.com>:

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.

Yea I actually do not see the problems, my stuff works
I can read it no problems.
If you do not need graphics use a character LCD display...
SPI and I2C is good enough.
Only for video and fast moving stuff you want to write directly to the display buffer.
And even then:
http://panteltje.com/panteltje/pic/scope_pic/scope_pic-0.1-scope1_img_1941.jpg
from:
http://panteltje.com/panteltje/pic/scope_pic/
driving a graphics LCD from a PIC 8 bits port.
LCD-19-HG1286418C-VA.pdf
You want color, I am sure there are plenty on ebay.
Same font again, just a few lines of PIC ASM.

 

[Rick C]

On Monday, March 7, 2022 at 3:09:36 AM UTC-5, Jan Panteltje wrote:

On a sunny day (Sun, 6 Mar 2022 10:45:25 -0800 (PST)) it happened Rick C
gnuarm.del...@gmail.com> wrote in
5cd1f698-776b-4f88...@googlegroups.com>:
On Sunday, March 6, 2022 at 12:42:22 PM UTC-5, Jan Panteltje wrote:
On a sunny day (Sun, 6 Mar 2022 09:14:11 -0800 (PST)) it happened Rick C
Using the small HDMI color LCDs is indeed a standard interface.
But then you have to fight with XLib..

Fight? I guess there are no good programmers left in the world. It\'s a shame.
You babble a lot and do not listen
Show us ONE program you wrote for X !
There was Xfree, then that got screwed up
all the related libraries have been broken over time, example libforms (wrote many many programs in it)
Old Xwindows code that works fine in XFree no longer does in X.Org
Here some history, good luck porting your stuff:
https://en.wikipedia.org/wiki/XFree86
don\'t know why you are talking about using a PIC in such an application.
Larkin is running Linux in his box. There\'s no reason why the display can\'t
have its own CPU, as I said, something like an rPi, but integrated with the
display. Connect the two with USB or SPI or even RS-232. None of those
are going away anytime soon.
Look dude I posted even a link to an HDMI LCD display

Stop twitching
Show us some code you wrote ror even somthing like that you build.

You are learning from Larkin.

This is the last thing I designed. I didn\'t get to choose the display. They felt it was better to pick a standard display that was available from a hundred different sources and was very low cost. I would have used a graphic display where the data wasn\'t being shoehorned into such a limited format. But they are right. You will be able to get these displays even after the nukes rain down. But in the long run, I don\'t think it went anywhere.

https://helpfulengineering.org/projects-news/project-spotlight-openvent-bristol/

The last project I did for myself was a test fixture using a PC as a display for exactly the reasons I give above. Minimal work to get a display working, it\'s just a console window that I send text to. It also logs the comms information to another window using sockets. I\'d show you the code, but you would not likely understand any of it. Forth is a write only language. Oh, the PC also handled the data collection. It works great and a tip from another Forth user allowed the application to copy text to the windows paste buffer which the user can paste into a spread sheet, so no typing.

I\'m very happy with that design. Unfortunately I used a crap PCB house to make the test fixture boards and the via barrels crack every time you look at them. Had to solder wire through all the vias to put an end to that.

Are you happy or did you want to see something else?

--

Rick C.

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