Post by thread:[EE]:Optrex LCD

I've been trying out a few Optrex displays given to me yesterday, and found some that are a little different http://home.clear.net.nz/pages/joecolquitt/optrex.html Marked PJAD112ZC PWB-15164C and has a single Oki M6222B interface/driver (very similar to the HD44780) date coded 8920. The knob is the contrast control The thing is, although the data sheet for the M6222B says it's capable of a 16x1 display, this 'un has 15 alphanumeric positions and 3 x 7-segment characters starting where you'd expect address 0x0f. As you can see from the picture, 0x00 to 0x0e are readily accessible, but what's the deal with the other 3 positions ? I can write to address 0x0f, but I can't make sense of whatever appears. Sometimes you get recognisable characters in 0x0f, "0x10 & 0x11", sometimes not, sometimes blank. I didn't specifically program it to display " P1" Perhaps the 15164 is a clue ? 15 ? 16 ? I could use them for just the predictable 15 characters but would like to know if those other three are in fact useable TIA (btw, before I work on an LCD I ALWAYS put a piece of acrylic over it. I dropped a screwdriver on an LCD once. Just once, never again. Homey don't play that game no more) -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Jinx <spam_OUTjoecolquittTakeThisOuTCLEAR.NET.NZ> wrote: > I've been trying out a few Optrex displays given to me > yesterday, and found some that are a little different > > http://home.clear.net.nz/pages/joecolquitt/optrex.html My guess is that those 3 * 7 segments are just a remapping of some of the pixels that would have formed the 16th normal character, and that you'll need to use a custom character to usefully drive them. Try writing character 0 into that location, then walking a 1 bit through the first 8 bytes of CGRAM to map out the segments. Jason Harper -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

> My guess is that those 3 * 7 segments are just a > remapping of some of the pixels that would have > formed the 16th normal character A reasonable guess but...... I wrote a routine that cycles through writing 0-255 to position 16. Can confirm that all segments in the three characters work, but the result was like a poker machine. Each time a new value is written to pos16 all three characters change together. Occassionally they are the same but mostly all three are incomplete characters with no apparent relationship to the immediately previous or following characters. As they're 7-seg they aren't in the character table, ruling out Japanese, but even so they wouldn't come in groups of three The only combination I could relate to was "ILL" Will try an LCD forum, contact Optrex (ha !) or look closely for any markings like "Property Of Area 51, Alien Technologies And Languages Dept". I'm sure I saw something like it in "Predator" -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email .....listservKILLspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body

Jinx, I think Jason could still be right. Each normal character is 5x8 for 80 dots The 3x7 segments are 21 dots, only half of a characters dots. Thus you should on average see half of the segments 'lit' as charactor dots for the same code in address 0x00 -0x0E. Does a Space (0x20 and / or 0xA0) have all 3 characters off? 0xFF might have all segments on if it works. (Font table says may be inadequate.) Jeff Berosik Jinx wrote: {Quote hidden}> > My guess is that those 3 * 7 segments are just a > > remapping of some of the pixels that would have > > formed the 16th normal character > > A reasonable guess but...... > > I wrote a routine that cycles through writing 0-255 to > position 16. Can confirm that all segments in the three > characters work, but the result was like a poker machine. > > Each time a new value is written to pos16 all three > characters change together. Occassionally they are > the same but mostly all three are incomplete characters > with no apparent relationship to the immediately previous > or following characters. As they're 7-seg they aren't in > the character table, ruling out Japanese, but even so they > wouldn't come in groups of three > > The only combination I could relate to was "ILL" > > Will try an LCD forum, contact Optrex (ha !) or look > closely for any markings like "Property Of Area 51, > Alien Technologies And Languages Dept". I'm sure > I saw something like it in "Predator" > > -- > http://www.piclist.com#nomail Going offline? Don't AutoReply us! > email listservKILLspammitvma.mit.edu with SET PICList DIGEST in the body -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email .....listservKILLspam.....mitvma.mit.edu with SET PICList DIGEST in the body

>I think Jason could still be right. >Each normal character is 5x8 for 80 dots >The 3x7 segments are 21 dots, only half of a characters dots. >Thus you should on average see half of the segments 'lit' as charactor >dots for the same code in address 0x00 -0x0E. >Does a Space (0x20 and / or 0xA0) have all 3 characters off? >0xFF might have all segments on if it works. (Font table says may be >inadequate.) This was the way I started thinking as well. You say the chip is similar to a 44780, so I would start by setting char 16 to one of the downloadable char ram spots, and then download characters into the ram with only one bit of the dot matrix turned on, and see which segment lights. I suspect you will eventually map the 21 segments to individual dots in a character. -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email EraseMElistservspam_OUTTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

> I think Jason could still be right Yes, he may get his Jace The Ace badge after all ;-) There's some kind of relationship between CG and those three characters. segment a = top b = top right c = bottom right d = bottom e = bottom left f = top left g = middle Using a loop to load CG0 with increasing data a pattern can be seen, but it's not what I expected or simply hoped for. If you make a loop to load byte0 of CG0 from 0x00 to 0x1f you get this - Segment e is bit0, then g, b, a, f for bits 1,2,3,4 So, the binary sequence gives this display with just five segments of position 16 00001 e 00010 g 00011 e+g 00100 b etc 11110 g+b+a+f 11111 e+g+b+a+f That's just with the first byte - 6 others to load values into (presumably 35 bits for 21 segments) and that doesn't yet explain how the other two characters in positions 17 and 18 get displayed. More than likely each character has a shape contained within some part of CG RAM I've had a look through an LCD forum I usually turn to http://www.eio.com/public/lcd/ but no reference that I've found to the PWB15164C, although who knows what's buried in unspecified "LCD help needed" posts What started as a curiosity is now bugging me and holding up "proper" work, so I may have to leave it until I can make up table routines to test all possibilities, preferably by keys. Still, it's a challenge when you come across something so unexpected as to find a 16-character controller driving 18 -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listservspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

>That's just with the first byte - 6 others to load values into >(presumably 35 bits for 21 segments) and that doesn't >yet explain how the other two characters in positions 17 >and 18 get displayed. More than likely each character has >a shape contained within some part of CG RAM I was expecting all segments of the 3 digits to relate to dots of one char position. If you continue on loading the CG ram bytes for one char I suspect you find the segments of the other digit positions will illuminate. -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email @spam@listservKILLspammitvma.mit.edu with SET PICList DIGEST in the body

I think you missed the point of the prior post. The 16th character would normally contain 35 pixels (5*7). It is likely that this display instead maps 21 of those pixels to the 3 7-segment characters. Any normal ascii character you send is going to be a mess in this case. I am guessing three of the 7-pixel columns are mapped to the 3 7-segment characters. You will need to use the controllers 'downloadable' or 'user' character mode to define custom characters to get a meaningful result. Start by defining a custom character with a single pixel on -- this should turn on at most one segment in the 7-segment characters. Now turn off that pixel and turn on the next. Repeat until you've tried each possible pixel, one at a time. You should be able to determine the mapping from pixels in the custom character to segments on the display. Bob Ammerman RAm Systems {Original Message removed}

> I think you missed the point of the prior post. > > You will need to use the controllers 'downloadable' Yes, I did miss the point - but have now realised that the 7-seg patterns are part of CG RAM. It was one of those " 'allo, wot's goin' on 'ere ?" moments. An LCD with 18 chars, 3 of which didn't make sense etc etc etc -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email KILLspamlistservKILLspammitvma.mit.edu with SET PICList DIGEST in the body