LCD character size

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

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")

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

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.

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 snipped-for-privacy@highlandsniptechnology.com wrote in snipped-for-privacy@4ax.com:

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:

960x800 in Linux X on a Raspberry Pi 4, same font as before: alarm from cenral heating radiator now, it also detects humans.

Accepts keys, has help menu:

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):

On a sunny day (Sat, 5 Mar 2022 14:04:12 -0800 (PST)) it happened Rich S snipped-for-privacy@gmail.com wrote in snipped-for-privacy@googlegroups.com:

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 snipped-for-privacy@gmail.com wrote in snipped-for-privacy@googlegroups.com:

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.

Something like this instrument?

I'm the hardware designer, and wonder how the hell they got hold of my schematics:

See the user manual for the 'screenshots':

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:

Artisan has more of the stuff I designed:

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

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

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.

On a sunny day (Sun, 06 Mar 2022 07:33:53 -0800) it happened snipped-for-privacy@highlandsniptechnology.com wrote in snipped-for-privacy@4ax.com:

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.

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.

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.

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.

On a sunny day (Sun, 6 Mar 2022 09:14:11 -0800 (PST)) it happened Rick C snipped-for-privacy@gmail.com wrote in snipped-for-privacy@googlegroups.com:

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.

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

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

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.

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.

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

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.

Readable by whom?

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.

On a sunny day (Sun, 06 Mar 2022 10:03:22 -0800) it happened snipped-for-privacy@highlandsniptechnology.com wrote in snipped-for-privacy@4ax.com:

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:

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.

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.

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?

On a sunny day (Mon, 7 Mar 2022 01:49:28 -0800 (PST)) it happened Rick C snipped-for-privacy@gmail.com wrote in snipped-for-privacy@googlegroups.com:

?

All I see is some numbers displayed?

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.

Like I said, they insisted on keeping it simple as possible. They also talked about using a tablet to provide graphs as an optional extension. The UI is rather crude with only four buttons, but it works. A member of the team found software to allow simulation of the UI in a virtually identical manner to how it actually looks, or so I'm told. It required a support package that I could never get working correctly.

Yeah, Forth is great for hardware interaction, because it is interactive and can be operated from the command line. Any word (subroutine) can be tested as soon as it is written. The compilation process is so simple even large program can be compiled as fast as the file can be loaded. The development system can actually be on the target as it often uses only 8 or 12 kB.

Did you use the Forth tools at all?

I was playing with a TI development board and ran the development on that target from another room, using a serial port on a Raspberry Pi. I just needed a virtual connection and I could do everything I could do if sitting next to it, other than rebooting if it really messed up. I looked for a USB hub (it used a virtual com port cable) that could toggle power. They exist, but I didn't bother to get one. We need to walk around some anyway, so I used the reset as an excuse to stretch my legs.

The numbers of people using Forth are dwindling. It no longer even shows up on the lists of languages. lol But as I said, it is great for interacting with hardware and debugging, so like Codewright, I keep using it.