• Pic® Basic


  • A Video Driver for the Nokia 3310 and 5110 Graphic LCDs

    Introduction

    Back in 2010 Gabriel-Florin Mihaila (Gabi) wrote a fully featured display driver for the Nokia 3310 graphic LCD. Gabi’s original work was developed for use with theń Amicus 18 compiler and, at that time, would seem to have worked equally well with the standard 8-bit version of the Proton compiler.

    Since then the Proton compiler has developed and changed considerably. Consequently Gabi’s driver no longer works in its original form. This article briefly outlines what needed to be done to get the original driver to work with the latest version of Proton (3.5.6.4 at the time of writing).

    Gabi has kindly consented to the modified version of his work being published on this forum. The relevant files may be found at the bottom of this article.


    Getting Gabi’s Driver going with Proton

    This section of the article looks at the issues involved in getting Gabi’s original driver going with the latest version of Proton. It is appreciated that this will not be of interest to some readers. If this is the case, then it is suggested that the reader skips to the next section - Using Gabi’s 3310/5110 Driver.

    The first issue which came to light was that the driver files, as downloaded from the Amicus 18 site, would not compile. The reason for this failure was immediately apparent and was as a consequence of changes made to the Proton compiler in late October 2012 (3.5.5.4). With this release the word “Declare” was made mandatory for all declares except Xtal and Device.

    Thus changing LCD_Type = Graphic” to “Declare LCD_Type = Graphic” cured the problem.


    On successful compilation the resulting hex file was uploaded to a PIC18F25K22 chip and a Nokia 5110 display connected. The result....





    Obviously, this is not what was hoped for. As can be seen, the screen text seems to be fine, but the graphics are something of a mess. Again the question arose as to what changes had been made to Proton which could affect the displayed graphics. If the code was compiled using Amicus, then what seemed to be perfect results were produced. Another search of the “What’s New” file which accompanies each compiler release revealed something interesting. In February 2012 the way in which the DWORD variable type behaved was changed. With earlier releases on Proton, and with the current release of Amicus, DWORD was signed. In releases of Proton from February 2012 onward, DWORD variables were no longer signed and had to be changed to SDWORD if negative values were to be stored.

    A hunt through Gabi’s code revealed two variables, errFill and err, which needed to hold negative values. These were duly changed from DWORD to SDWORD types. The result was a much improved display.






    Success? Not quite. Look at the bottom right-hand corner of the display. Part of the rectangle drawn around the edge of the screen is missing. Looking through Gabi’s code didn’t suggest any obvious reason for this happening. It certainly didn’t seem present when the software was originally released. However, when both the Amicus version and the modified version of the code were compared, the same fault existed. Following much experimentation it was found that resending the first byte of the video buffer cured the problem. After the addition of a few lines of code to do this at the bottom of the refreshMEM_SUB subroutine, the result was.....





    The reason why this additional code is necessary is not entirely clear and could be down to some minor difference in the 3310 and 5110 displays. More investigation is needed here.


    Using Gabi’s 3310/5110 Driver

    The first thing that a potential user of this software needs to aware of is that something more substantial then a ‘16F628 is going to be needed. The driver video buffer requires a relatively large amount of RAM, some 504 bytes. Additionally, because all the fonts are stored in program memory, the smaller PICs with limited program memory are not usable. Both the 18F25K20 and 18F25K22 are examples of chips that are suitable.

    A further point to note is that the driver makes use of the chip Master Synchronous Serial Port (MSSP). Consequently the clock (Nokia_CLK) and Data (Nokia_SDA) must be attached to the relevant pins on the PIC used. PortC.3 and PortC.5 in this case.

    If you are unfamiliar with Gabi’s original driver, the demonstration program supplied in the download is well worth studying. Not only does it provide a good indication of the capabilities of the driver, but shows how it’s to be used.

    A look through the driver code itself is also a worthwhile exercise. There’s a lot in it, not all of which is shown in the demonstration program.

    Finally, I would like to thank Gabi for not only making his driver available to the community in general, but also allowing me to tweak and publish his work.

    A video of Gabi’s driver in action can be viewed by following the link below.
    A link to the driver files can be found below.
  • Recent Activity

    See_Mos-247

    Mysterious PORTB problem

    Thread Starter: xldaedalus

    I'm using Proton+ to develop firmware for a product with switches. The MCU is an 18F26K22. Most of the switches reside on PORTB. I am NOT using a...

    See_Mos Today, 14:44 Go to last post
    Mellbreak-21950

    Watchdog timer

    Thread Starter: joesaliba

    I have a code that basically looks for four input and four outputs, depends on various timing and input conditions. I use interrupt and some delays...

    Mellbreak Today, 11:30 Go to last post