product somebody could do

A monkey such as this one:

seems like a fun way to do that.

On a sunny day (Thu, 14 Jan 2010 15:16:20 -0800) it happened John Larkin wrote in :

What is there to test? LCDs normally work, and the interface diference is usually just a few #defines in C.

Why? If you use embedded with those LCDs you have the driver. They are easy to drive.

If you want to learn how to drive those, plenty of example code available. I even have BASIC code for that available if you need it,

"John Larkin" schreef in bericht news: snipped-for-privacy@4ax.com...

Hmm... I sure have both the skills and the equipment to develop a thing like that. Nevertheless I don't expect to be able to sell hundreds of them let alone thousends. While you need to sell let's say some hundred to brake even with the development costs. Meanwhile those displays become so dirt cheap that replacing a suspected one will soon be cheaper then testing it. But I agree it to be an interesting idea. If I ever build a proto I'll let you know :)

petrus bitbyter

I want to evaluate the appearance of various LCDs.

John

It would be handy for comparisons between the countless displays on the market. In terms of display readability and contrast, backlight performance, speed, custom character support, power consumption etc.

And a dog to do if you have to compare many different displays. The various connections available alone are a PITA to deal with sometimes. Might be handy if it had some sort of PC interface too, esp so for say the graphic displays.

This project has actually been on my to-do list for a decade or more, just never gotten around to it.

Dave.

"John Larkin" schreef in bericht news: snipped-for-privacy@4ax.com...

I see. But who is able to build the device you want today and finishing it yesterday? As the proverb on the R&D door says: "The impossible will be done immediately, miracles will take some time."

Guess you'd better get some old PC with a bidirectional printerport. Some good old LS-TTL chips and a few lines of antique GWBASIC will do the job. Anyway, when I finished my proto, you will not need it anymore :)

petrus bitbyter

I suspect most electronics engineers have an LCR around these days.

I can't see why anyone would want to do this for LCDs. Most folk that are using LCD displays already have drivers to match their chosen devices or are capable of writing them from scratch in a couple of hours. They are all much of a muchness after that unless you are trying to direct drive multiplexed bare LCD devices and obey the rules for keeping them from polarising.

Any of the cheap PIC kits that come with a small LCD display should be able to do what you want if you make up a small test lead/adapter. eg.

Intended for hobbyists but not a bad starting point if you only want to have a quick and dirty LCD driver for minimal cost and effort. Or

If you prefer AVR to PIC.

Regards, Martin Brown

On a sunny day (Fri, 15 Jan 2010 14:11:41 +1100) it happened "David L. Jones" wrote in :

I dunno, display technology is changing very fast, think Mirasol, and the only way you will be able to check for the usability is to get a development board or look at one at some exhibition. The connections will change, you can buy the same LCDs (the small character ones) with a RS232 interface too. I have a nice RGB LCD here somewhere that has unknown connections, but can make great video. It came out of a small monitor, no idea how to drive it, could connect it to some FPGA pins and write a driver in Verilog,. I have written a Verilog driver for the 2x20 lines character LCDs. Most you can just drive with a 4 bits data bus, and I think those are the ones John was talking about.

On a sunny day (Thu, 14 Jan 2010 16:54:59 -0800) it happened John Larkin wrote in :

If they all have that the Hitachi driver chip, I would use the PC par port, and write something in C. They can be driven with 4 data lines, 3 control lines, and a DC level or PWM for the LEDs. If for display only, then no need to read the char RAM, you only need to check the busy bit before sending the next byte, they are not timing critical if you do that, so no extra hardware is needed, 8 outputs and one input -> PC parport.

Could be a fun project, some resistors, LM317, a potmeter for brightness, a wall wart for power, and some Linux soft. I could even do it for fun some day if I felt like it :-)

"Jan Panteltje" schreef in bericht news:hipqhv$qjn$ snipped-for-privacy@news.albasani.net...

I've done so last year. Using 4 bit mode and only for checking a particular flaw (or feature). For more general testing I'd like some buffering to protect my printer port and making it possible to use 8 bit mode and reading back from the device. Contrast and backlight should also be checked.

petrus bitbyter

On a sunny day (Fri, 15 Jan 2010 15:58:05 +0100) it happened "petrus bitbyter" wrote in :

To protect against bus conflicts I simply put 810 Ohm resistors in series with the data lines.

That is with a PIC, and in case I made a software error.

It also takes care of any 5V logic to 3.3V logic conversion, I did that the same FPGA 3.3V to 5V LCD: ftp://panteltje.com/pub/2h/alles2.jpg IIRC I lowered the LCD voltage a bit too, you can see the resistors just above the LCD, and LM317 top left on the same board. My Verilog driver for that LCD is in here:

We have some (old product) circuit boards that have the 14-pin pinout. 16 if backlit. Would work fine for what you're talking about. All one would have to do is re-write the microcontroller code. You would not have to populate anything else on the board, just the LCD and controller (8051?)

I would think the bigger problem would be finding a reliable way to make a temporary connection to the LCD you want to test. I suspose you could make a jig with needle pins, or ?? Maybe an elastomeric with embedded conductors?

Anyway, my point is: Why start from scratch?

Note: I don't personally see a big market for this. Maybe the hobby market. (?) Anybody with a need to test more than a couple dozen LCD's is probably going to want a different solution.

You can use a standard printerport to control the LCD in 4 bit mode. I once wired a display in a way you can simply print something to the port to control the LCD so it works on any OS. Heck, it should even work on an USB LPT converter.

In 35+ years as an engineer I've never had one "around". There is one in the company, in the service department I think.

I can see the utility when choosing a display. We're always being offered alternatives to our displays. I'd go further than a suppressed yawn if I could see how they actually worked. I don't see it as a real possibility, though. Too many different display organizations and interfaces.

At companies doing component level RF design I think they're either (1) around or (2) there are enough VNAs that you just use those instead. :-) (Granted, VNAs don't work that well if you're trying to look at values more than 2 or 3 orders of magnitude away from their nominal impedances of 50ohms...)

Even a lot of hard-core radio hobbyists eventually get something like an old HP 4191 -- these days they're a very good value, if you have the bench space for them.

Personally I have an M3 electronics LCR meter -- it's a step up from the AADE unit (which I previously had), albeit spendier too.

I seem to recall your displays looked a skosh washed out even in *indoor* lighting and seemed a little slow to update, but that could have been software-related (i.e., we hadn't bothered to adjust the contrast properly)? :-)

The display on the base station looked nice.

He's thinking of the Hitachi controller-based ones that are quite ubiquitous for character-mode LCDs. (Or I should say... the ones that use the same electrical interface as the old Hitachi controller... these days who knows if you're talking to a MCU or an FPGA or a clone ASIC or who knows what... At a PPOE we switched from LCDs to a Noritake VFD that had a Hitachi-compatible interface, we plugged'em in and... they sat there dead. Took me about half an hour to track down a bug in my software to fix it... I was kinda thankful to Noritake that they didn't just "work anyway" like the LCDs had, since it let me find the bug and all.)

---Joel

Nah, real hams use a dipmeter, a bunch of well characterized caps, a soldering iron and a glass of beer to measure inductance :-)

But yes, I have to confess that I use a HP4191 myself.

Too small a market, too many interface variants. Other than the Hitachi I've come across oddles of other protocols. RS232, two (!) RS232 links, I2C, SPI, you name it.

You can do this through USB pods such as the LabJack. Nice screw terminals, comes with elementary software and GUI. I've never driven a Hitachi with it but SPI.

Much bigger market, same unit goes to everyone, no bugging for features by users, hardly any "It don't work" complaints from beginners. An inductor is an inductor is an inductor. It has two terminals and you are even allowed to reverse them. Not so with displays. All it takes is one wrong voltage and you see nothing, worst case you hear a little pffft ... pop. After you sold 500 you probably have to disconnect the phone :-)

You might have a hard time passing off the dip meter + beer approach to your clients when you're charging by the hour. :-)

I'm often astonished at just HOW BIG (and heavy) these old instruments were. Almost makes me think that *some* of that might have been for marketing purposes -- when you just spent fifteen-thousand-1980-dollars on a piece of equipment, people weren't going to be very impressed if it was only the size of a breadbox.

I cheaped out and bought an 8924C service monitor over the 8920B... about 1/2 the price, but twice the size and weight. Long-term chiropractic bills might end up making that a poor choice... :-)

Nope, strict rule, when working on client stuff the beer comes afterwards. Not before dinner anyhow.

And it had to say HP, Tektronix, Collins or IBM on there.

As the scouts say, be prepared. I do that with calcium/magnesium supplement from Costco.