Character Set for 3595
Here you can see the full ASCII character set displayed on the 3595 lcd. It was actually amazingly simple to get to this point from the previous “helloworld” firmware.
The most important change that was made is that I upgraded to an ATmega168 to solve my programming space problem. This chip will still operate at 3.3v which is the operating voltage of the LCD. The additional 14kb of programming space should give me plenty of room to grow. I would also like to dabble with SD card compatibility and this chip should allow me to do so (I’ve never looked into it so I may be wrong).
For the character set I borrowed the array and the function to read the characters from memory from a past project. I then wrote a function to handle advancing a “virtual cursor” after each character is written. This function handles wrapping to the next row when about to overflow as well as wrapping from the bottom to the top. The last thing was a function to parse the character information and write it on the screen.
I’ll provide more details in my next update.
odyssey through technology 
January 1, 2009 at 1:49 pm
Very cool! I’ve got an old Nokia 3595 also. I’ve already gotten a 3310 LCD working with an Atmega8L but it is monochrome. I noticed that your code in the previous post seems to ‘bitbang’ the in the LCD_Out function that you borrowed. The names of the pins look like it is probably a SPI interface. Have you thought about (or tried) switching this to use the built in SPI capability of AVR microcontrollers? For the Nokia 3310 LCD, I am using a library (written by someone else) that uses the AVR’s SPI and provides convenience functions for doing the display stuff. It would be great to have a similar library for this LCD.
Here is the Nokia 3310 library that I am using in case its source is helpful to you:
http://www.dharmanitech.com/search/label/3310%20LCD
One important thing to note about this 3310 library is that it currently draws directly to the screen. Some other libraries that I’ve seen have a buffer of the screen in RAM. Since you have to update a portion of the screen in a single write, the buffer in RAM allows you to modify only one pixel because you can get the previous value from the buffer, modify it, and write it back to the screen. The guy who wrote that library has not added it to that library yet.
January 7, 2009 at 8:42 pm
Thanks, I’ll have to check into that. I hadn’t thought about using the built-in SPI but it would probably speed things up quite a bit.
As far as building a buffer in ram, I’m not sure I have enough using the m168. I’d need to switch to a chip with more ram or with the ability to add external.