LCD character size

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

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 

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

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

>s&#4294967295;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

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

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&oslash;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

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.

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.

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

On a sunny day (Mon, 7 Mar 2022 01:49:28 -0800 (PST)) it happened Rick C
<gnuarm.deletethisbit@gmail.com> wrote in
<10ffb89c-88ae-4b62-a536-663f12da61den@googlegroups.com>:

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

All I see is some numbers displayed?

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

sigh

BTW Forth, did not know anybody was still using it.
Last time I encountered it was when I had to do fault finding in a camera system for motion
picture production.
In those days they used a camera driven by a computah above some paper with text to zoom in and out
and make special effects, the guy wrote the code in Forth.
IIRC was a hardware design error I found out, took a few minutes.
He designed the 'tronics too, was an old fellow worker of mine from the TV days, he had quit so they were left with the problems.