I am working on initializing the LCD. I don't have much luck getting my code to initializing the LCD reliably. My experience tells me that if I cannot obtain official info, I should do the hard work myself than to rely on unreliable 3rd party sources..
LCD have specific parameters, so what better place than directly reverse engineering from the player itself.
Probing SPI from the LCD pads |
Delay after /Reset deasserted to initialization sequence |
I have captured the following LCD initialization command sequence.
LCD Init code |
E2: Reset
A2: Set bias = 1/9
A0: Seg direction - LC[0] = 0
C8: Col direction - LC[1] = 1
26: Resistor ratio = 6
2F: Power control: Boost, Reg, Follower
40: Set Scroll Line = 0
A0: Seg direction - LC[0] = 0
AF: Set Display Enable
81, 02: Contrast = 02 - They probably change the contrast to a bit higher after the bitmap is loaded.This is the data rate for initialization command.
SPI data rate |
Delay after init commands |
Each of the lines started with the command sequence
1x: Set Column Addrand followed by the bitmap.
0x: Set Column Addr
Bx: Set Page Addr
Here is a quick test using my Nokia 5110 LCD routine. I am using 9Mbps. I have yet to add in the proper delays.
LCD controller is uc1701, Datasheet (UC1701.pdf)
I find one gotcha that evaded me for most of the afternoon. I got clued in when my display stopped showing garbage when I cranked the data rate up to 36Mbps. (The part is rated for 33MHz.)
I have forgotten that SPI has a (single byte) buffer. If I need to switch between data and command mode, I have to wait for the current transfer to finish. That's what the while loop does.
I'll keep the SPI data rate at 9Mbps so that I can use a slower GPIO slew rate (10MHz) for to minimize signal quality issues as the flex circuit on the LCD module doesn't have a ground plane.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.