Forgot your password?
No account? Register one!
March 9, 2009
Product LCD-10168 |
about 3 years ago
Where are you seeing a Vout pin?
I am guessing that you are seeing the PCB bent away from the back of the display, up near the “top” of the display region, when it is viewed in normal operation, right?
This is because this is where the connections are on the back of the “display glass”. These connections are carried down into the PCB via a small strip of that elastomeric connector material. This material works by being compressed between the two substrates (the glass and the PCB) to hold it in place and make the connections between the pads on each surface. As a result of being compressed, it puts a force “up” on the glass, and “down” onto the PCB. In this particular design, this has the result of bowing the PCB in the units I have purchased.
My thought, if I were up to me, would be to redesign the metal hold-down bracket, to have one more metal tab going down through an additional slot in the PCB, right there at the center of the top edge of the hold-down bracket. This would carry the majority of the reaction to the force exerted by the elastomeric strip, and should minimize board bowing.
Out of curiosity - what indication is it giving you that it is powering up, if there is nothing on the display? There are no outputs brought out from the controller, so what feedback are you seeing that leads you to believe it is powering up?
I found that same 0xB3 value works just right for the two units I have. I wonder if some of the difficulties people have getting them going is from using “E0” or “BF” or some of the other values I’ve seen posted. When I first powered mine up, I got NOTHING on the screen, and I would have thought it was dead, or assumed mine had “bad connections”, if I hadn’t known to play with that Vop value…
Did you get either of the LCDs to display anything, at any time? Is it possible that the connections were OK, but you were not initializing or driving them correctly? Or did they start to work at one point, and then fail at some later point?
When I originally tried to get mine working, I was seeing NOTHING on the display. Then I had to get my initialization sequence correct, and adjusted my Vop value (ultimately using a byte of 0xB3) before the screen would display anything visible at all.
Note that the backlight LED’s are soldered onto the breakout board, and have nothing to do with the circuitry of the controller and LCD. So just because the backlights are shining doesn’t tell you anything about the operability of the LCD itself.
News - What is it you say you do… |
about 3 years ago
Nate and Nada - you both have excellent and absolutely valid points. A critical part of an elevator pitch - heck of any human interaction for that matter - is knowing your audience.
Nada, your pitch is structured beautifully to target and attract a potential investor in the business, which is what most classic “elevator pitches” are designed to do - what they practice at Caltech and MIT and everywhere else someone hopes to hit it big with a new idea. If you find yourself in an elevator with a “suit” from a VC firm, this is the pitch you give. You talk branding, serving markets, and exponential growth.
On the other hand, if you find yourself on the sidewalk with a scruffy looking type with soldering iron burns on his or her fingers, this is more likely the audience where you want to go more with the original: “The big distributors sell anything and everything. We carry what you probably need."
It’s like tweaking your resume for different targets - you are not so much just distributing the exact same, standard story to everyone, but you flex the story you tell each time to match what you are trying to convey to that particular recipient…
You’ll want to put a command byte of 0x20 in there, after the 0x14, and before the 0x0C. This is needed to put the display back into its “basic” command set, so it will correctly recognize the 0x0C command byte that puts it into “normal” (not inverse) display mode.
Kuy - good info… A few comments:
(1) I confirm this intialization sequence works, with the clarification noted in #2 below.
(2) The second command byte (the 0xE0 shown above) is not arbitrary. It is 0x80, or'ed together with a 7-bit Vop value. I found my display to be somewhat sensitive to this value. At Vop=0xBF, my unit was initializing electronically, but had a blank display (or solid-black, I can’t remember now.) Anyway, I had to play with this value, and 0xB3 ended up working for me, so if you are initializing to this sequence and having trouble, try varying this parameter. The technical details of this parameter are explained in the datasheet, section 8.9, but really, you will just have to play with it.
(3) I didn’t find reset/init to be all that tricky, but it’s possibly because I’m powering the display unit from a port pin. That’s right, it only draws somewhere around a mA or less, so I just use an output-configured port pin to run the display VDD. (This lets me turn off the display easily when I want to go into low-power Sleep mode on my micro.) So I let my micro do it’s own reset sequence with all my port pins (including Display VDD, !Reset, and !SCE) at “0”, and when I’m ready, I set, in sequence:
VDD = 1
!SCE = 1
!Reset = 1
These end up coming in a 1 us per instruction sequence (running a PIC 18F at 4 MHz.)
Note the datasheet says reset can be low when VDD is applied, and then has to be at least a 100ns “low” pulse. So powering up VDD, then applying !SCE at 1 us and !Reset at 2 us meets that spec just fine. I have had perfectly consistent startup operation with this sequence.
(4) !SCE tied to ground - yes, you could, but I’ve had fine results framing each byte with the !SCE signal - there’s nothing wrong with that. Yes, framing a whole transaction is fine, too. Note the datasheet timing diagrams show that !SCE serves a reset function on the incoming serial shift register, so if you ever get a glitch in your serial transmission that gets the bit count off, respecting the !SCE timing (whether on byte- or transaction-basis) will automatically get the display controller’s serial receiver synchronized back up on the next byte or transaction.
(5) If you are using a PIC to run ths thing, and using the PIC’s USART or EUSART in a synchronous mode, be sure to note that the LCD controller expects the MSBit of each byte to be transmitted first on the serial line. The PIC 18F EUSART transmits the LSBit first. For now, I have lots of extra code space, so I’ve wasted a 256-byte section on a lookup table that reverses the bits in a byte. This way, I just write my initialization code normally, and I have a TransmitCommandByte() function that looks up every byte it sends so I don’t have to think about that.
Once I get to a final version (or at whatever point I need to conserve code space) I’ll just establish my final command sequencing, and hard-code in the bit-reversed values so I can get rid of that lookup table.
As a separate issue from the command bytes, all my graphic data are already created with the proper bit orientation, so I don’t have to look them up to do the reversal.
The Absolute Maximums section of a datasheet (also known as Limiting Values as in the Philips datasheet here) is only used to specify conditions that might cause permanent damage to a device, and should not be used to infer normal operating parameters.
Normal operating parameters are found in the DC Characteristics and AC Characteristics tables. Note that in DC Characteristics, the VDD2 is listed as min 2.7V and max 3.3V. This is the manufacturer’s specification for how to run the device to its specified performance.
Also note that logic levels in the DC Characteristics table are constrained to be between VSS and VDD.
So in summary:
DC/AC Characteristics tables tell you how to run the device in its normal operating range, to achieve manufacturer’s specified performance.
If you run outside this range, performance is not specified, and you’re on your own. (Maybe it won’t work at all, will work inconsistently, or maybe it will work but other specs will be off - it may draw more current, timing may be off, etc…)
Running outside the ranges listed in Absolute Maximums is likely to cause permanent damage.
In the datasheet, check Section 11, DC Characteristics. This table shows VDD2 (when used with internally generated VLCD) as min 2.7V and max 3.3V.
No public wish lists :(