The driver library is mostly written. I still need to write code for drawing dotted lines and doing white on black rectangle texture fills.
My 3310 PCB display is working - I haven't tested the buttons etc.
Spark fun have retired this display but it is still showing stock at some other places (ATM).
It seems to be replaced by the 5510 LCD http://www.sparkfun.com/products/10168
The 5510 is probably a better LCD - is is more expensive but has back-lighting and a solder-able connector. It should be fairly easy to modify my PCB for this display.
At about $10 this is 2/3 the price of the colour display so it has lost the appeal for budget projects. It would be nice to see stable supply on good value displays. I don't want to do a new design every time display are discontinued.
Hackaday have a good hack today for blackberry display - http://hackaday.com/2011/04/21/blackberry-lcd-reverse-engineering/ at 160*160 the extra pixels would be useful.
June 30'th 2010.
This is a small monochrome LCD 84x48 pixel display. The thing that caught my eye was that it was only $2.95US at Sparkfun (SF).
The down side is it has a transparent on-glass connector and no obvious source of matching connectors. One common way to connect this type of device in with a elastomeric connector. Even if we source such a connector we then need a suitable printed circuit board and ideally gold plated pads to suit. Unless someone produces a cheap ready made PCB (or other connector system) the true cost of using the display becomes unattractive. So the first issue is find a cheap and preferable easy way to make a connector.
Most of the pages I've found on using this device were by people who got the display from a phone and therefore had a connector to match it.
Connector attempt one.If you've used pin strips you will probably recognise the gold plated forks below. These are from the SIL (single in line) connectors/sockets which mate with the pins. If you buy long SIL sockets and cut/break them to size you usually end up releasing some of these in the process. They are also dead easy to remove from the housing - just pull them out by the tail. SF sell 40 way headers for $1.50US so my connect cost about 30 cent plus glue. My connector was from another supplier but I'd assume they are basically the same.
|A single fork in position over a on-glass conductor. The conductor is on the underside. The surface on the LCD viewing side is plain glass.|
The transparent conductor appears to be fairly hard and well bonded. There are lots of fine conductor tracks which are totally unprotected. The controller chip had small strip of black tape on the other side of the glass - presumable to keep bright light from affecting the chip operation. I removed it and will re-tape when I've finished.
The transparent conductor has a much higher resistance than normal metal tracks. The conductor may be Indium tin oxide but I don't really know. Probing the big patch of conductor with an ohm meter gave reading in the order of 100 ohms when the probes were maybe 5mm apart.
|Now all 8 forks in position. The legs have been pre-bent to make soldering easier later.|
The little forks have one point of contact on either side of the glass. They tend to swivel around those points when bumped.
|The forks are now glued in position to stabilized them. Note the epoxy is on the non-conductive surface.|
The tails of the pins were easily tinned with a normal soldering iron and look like they will take soldered wires without any trouble.
I don't have hardware or software to test the display so it will be a while before I know if the contacts work or not. t
There is a problem which seems to be similar to
A gotcha.I had a bug that took a long time to find - situation normal. Some LCD writes would cause the image to fade. It wasn't obvious how often this was happening because it faded slowly.
It turned out that the serial data line has to be low after transmitting the data. I had left the line as is after the last bit - so any sequence ending with a high bit caused the screen contrast to go very low.
July 8'th,A crude version of the basic graphic primitives are working.
Pixels, lines, filled rectangles, unfilled rectangles and text can now be drawn.
There is still much to do.
A present only black on white is supported and text must be placed at 8 bit boundaries in the Y direction.
At a minimum white on black needs to be supported and ideally dot patterns could be used for shaping.
For a generic applications text really needs to be positioned at any location.
There is also scope for allowing logical operations when drawing. For example a new object could either erase existing graphics in that same location or draw on top of them. You could also have exclusive "OR" operation to invert whatever is there already.
I plan to do white on black and possibly shade patterns but not logical operations.
Text will be pixel aligned.
I will also optimise some of the existing code to minimise communications from the AVR to the LCD.
Software.This display is quite different to drive compared to the Nokia colour LCD. With the colour display you set up a rectangular window in the display RAM and write a pixel stream to it. With he 3310 on the other hand you just write bytes. Each byte is a vertical column of pixels in one of six rows. This is great for doing six lines of 7*5pixel characters but not great if you want to do anything else. Most operations beg for a read-modify-write sequence but seeing you can't actually read the display RAM one needs to keep a copy of the display image in AVR RAM. Fortunately for this small display it only needs 504 bytes of RAM to buffer the entire display.
The code to draw graphic primitives and characters to arbitrary locations on the display will requires a fair bit of bit fiddling.
Primitives.I've tried to make the function as generic as possible. Some of the parameters are ignored or larger than need be in order to remain compatible with my existing colour display. I stopped using the term "LCD" in the functions called by the application because I may port the code to OLED or some other display technology.
The main functions are.....
void SendLcd(char type, char dat)
void ScreenXY(int x, int y)
void Rd_OR_Wt(char val)
void Rd_AND_Wt(char val)
void ScreenPixel(int x, int y, int color)
void ScreenLine(int x0, int y0, int x1, int y1, int color)
void ScreenRect(int x0, int y0, int x1, int y1, unsigned char fill, int color)
void ScreenFilledRect(int x0, int y0, int x1, int y1, int framecolor, int fillcolor)
void ScreenChar(char c, int x, int y, int size, int fColor, int bColor)
void ScreenStr(char *pString, int x, int y, int Size, int fColor, int bColor)
void SendLcd(char type, char dat)SendLcd send a command or data byte to the display via the serial interface. The serial function is software driver and doesn't use the SPI hardware. Using the hardware would make a big difference to the speed - so would coding this function in assembler.
It is not generally called directly by the application.
void ScreenInit(void)ScreenInit send the configuration sequence to the display. This includes things such as setting the contrast.
void ScreenXY(int x, int y)ScreenXY sets up the display for drawing to a particular location. It also calculates which byte of the local buffer is to be used.
This would rarely be used directly. It is called by other functions such as ScreenPixel.
void Rd_OR_Wt(char val)Rd_OR_Wt take a byte from the local buffer, "OR"s a byte val with it, sends it to the LCD and write a copy back into the buffer.
Not called directly.
void Rd_AND_Wt(char val)Rd_AND_Wt is like Rd_OR_Wt except it uses and "AND" instead of an "OR".
void ScreenPixel(int x, int y, int color)ScreenPixel sets one pixel on the display to either black or white.
It can be called directly but is mostly called by the ScreenLine function.
void ScreenLine(int x0, int y0, int x1, int y1, int color)ScreenLine draws lines on the display. Either black, white or (later) dot patterns.
void ScreenRect(int x0, int y0, int x1, int y1, unsigned char fill, int color)ScreenRect draws rectangles on the display. Either black, white or using an 8*8 bit pattern.
The boxes may be filled or not.
void ScreenFilledRect(int x0, int y0, int x1, int y1, int framecolor, int fillcolor)ScreenFilledRect just calls ScreenRect twice to draw a filled rectangle with a border.
|A example of boxes drawn using ScreenRect and ScreenFilledRect.|
void ScreenClear(void)ScreenClear clear the screen to all white. Black can easily be done using ScreenRect.
void ScreenChar(char c, int x, int y, int size, int fColor, int bColor)ScreenChar writes one character to the LCD in either black or white. The position is in pixels. The code knows how to straddle two physical rows of bytes.
Only 5*8 supported. The parameters "size" and "bColor" are ignored.
Rarely used directly. It is called by ScreenStr.
void ScreenStr(char *pString, int x, int y, int Size, int fColor, int bColor)ScreenStr writes a string to the LCD in either black or white.
Only 5*8 text supported. The parameters "size" and "bColor" are ignored.
14/april/2011Family problems have kept me away from this till now.
My 3310 PCB display is working - I haven't tested the buttons etc.
|The PCB is currently powered by the 3V3 serial adapter.|
The PCB has everything needed to drive the display including a mega328 micro. The PCB uses an arduino pro footprint so it should be possible to add shields or omit the micro and use the PCB as a shield.
|This is the eagle PCB layout.|
A 3310 project.See slowcooker .
Nokia 3310 display or PCD8544 projects.http://www.dharmanitech.com/search/label/3310%20LCD