Interfacing the Nokia Display

The Nokia LCD replacement screen for the 6610i and its variants is a beast, but it's full colour, cheap and very impressive when displaying all kinds of information. This text will show how to write a plug-in for the display and make a simple oscilloscope.

Resources & The Display

There is no shortage of information on the net about interfacing these displays, the display used for this example is the Philips type with the orange/brown coloured PCB. There are some major hurdles to overcome when using this display:

  1. 1) The connector is miniscule, it is just possible to solder wires onto it, this took me days to do.
  2. The LED back light requires about 6V to illuminate, it will NOT illuminate with 5V
  3. The display works on 3V3 logic, this is not a problem for the PIC32

To overcome the problems above the BV4141 PCB can be purchased from www.byvac.com It has a connector for the display and also a step up power supply that will power the display back light from 5V.

  • Nokia Display tutorial by Jams Lynch
  • Epson datasheet EPSON-S1D15G00_REV1_0.pdf
  • Phillips datasheet PHILIPS-lds176_spec.pdf
  • Phillips PCF8833 datasheet philips-PCF8833_1.pdf
  • Two ZIP files in the downloads section

Plug-In

image of scope output scope image with colours

The above image was photographed form the actual display showing a low frequency square wave fed into analogue channel 1. In the second image, red has been used for anything above half voltage and green for anything below. The images look much better in real life as these displays do not photograph well.

The display can actually be made to function just using Basic alone but, mainly because of the unusual SPI requirements it is very slow and so the plug-in feature of PIC32-Basic comes to the rescue.

SPI-9

Unusually the PIC32 is only capable of 8 and 32 bit SPI transmission and reception, unusually because other 32bit processors such as the ARM can handle any number of bits (up to 32) in hardware. For this display it is significant because it uses a NINE bit package, this means that for the PIC32, or any other PIC that I know of, one of the bits has to be sent using software. The display accepts two kinds of SPI packets, a command and a data packet. The command packet has the first bit sent set low and the data has the first bit set high.

To implement this on the PIC, the SPI hardware has to be switched off, the first bit clocked in (high or low depending on command or data) and then the rest of the 8 bits sent with the hardware switched on.

int spi9(int data)
{
unsigned char j;
    // cs low
    CSL=CS_MASK; // clear, set low

    // turn off spi
    SPI1CONCLR=0x8000;

    // send bit 9
    if(data & 0x100) PORTFSET=0x8; // data high
    else PORTFCLR=0x8; // spi data low

    asm("nop");
    PORTFSET=0x40; // spi clock high
    for(j=0;j<3;j++);
    PORTFCLR=0x40; // spi clock low

    // spi back on
    SPI1CONSET=0x8000; // send data to spi
    SPI1BUF = (data & 0xff); // write to buffer for TX
    while( !SPI1STATbits.SPIRBF); // wait transfer complete

     // cs high
    CSH=CS_MASK;

    return SPI1BUF;
}

The above code will accept a 9 bit value and send the 9th bit out first using software, the delay loop for the clock can be adjusted so that it matches the clock rate for the SPI hardware. It doesn't NEED to match but it can be reduced for optimising the speed. This function can be called form Basic using the plug-in technique, this alone considerably speeds up the Basic interface.

int pi_spi_com(GPS *s)
{
    return spi9((s->i[0] & 0xff));
}
//------------------------------------------------------------------------------
int pi_spi_dat(GPS *s)
{
    return spi9((s->i[0] | 0x100));
}

Above is how the two functions to send commands and data to the display from Basic have been implemented, note that the data command has had the 9th bit set high. To use this from Basic a ccall would be made:

ccall(SPI_CMD, int 0x2d)

Where 'SPI_CMD' would be the absolute address of the 'spi_com(GPS *s)' function frond form the .map file.

Physical Connections

The display, using the BV4141 can be directly connected to the BV511 with no additional components needed.

connection diagram

SPI1 interface is used and the power is obtained form one of the 3V3 power connectors, the the BV4141 is not used then power to the LED back light will also need to be provided.

Software

To keep things as simple as possible only a very basic interface is provided. There are two choices of zip file. One will work directly with the MPLAB and the other uses PS Pad as the IDE. The reason for using PS Pad is that the makefile can be used to create the binary file that is required after the hex file has been created, it is easy to forget this part when using MPLAB. If using the MPLAB version, after recompiling double click on 'to_bin.cmd' which will run the convertor and create a new binary file. The MPLAB version produces 'plug-in.bin' and the PSP version produces 'pi.bin'

To try it out carry out the following steps:

  1. Unzip either the MPLAB or the PSP file
  2. plugin to 0 // the 'plug_in.bin' file [see note 1]
  3. Load 'scope.bas' using the 'tload' command
  4. Type ds_init
  5. type scope(10, 0, 0xff, 0xff)

[1] This command most of the time requires a reset before use.

The above list should get a very basic line, place a finger near the analogue channel 0 (JP3-16) and you should see a scope like display approximation to a sign wave. Press any key to stop the scope function which is an endless loop.

Further

The current state for the software is purposely embryonic, that is to say at the very early experimental stages. It may be of interest to look at some strategies that could be used for creating a proper oscilloscope.

My first attempt was to light up 132 pixels in a line, the y value of the pixel being calculated from the input of the ADC. At the start of each line the display would be cleared to the background colour. This produced a display that worked but was composed of just dots and was difficult to see.

The second attempt was the same but instead of clearing the whole display just one column was cleared, this produced the same result as the first attempt.

It was noticeable that while the horizontal portion of the line looked like a line the vertical part needed the dots joining up and so the third attempt, and the one presented, did this by lighting a column from the last y point to the present y point.

Had I the time the next attempt would be to capture a whole line 131 bytes and then present this to the display. It is clear that updating the display at each change is a very slow (comparatively) process and in practice can display about 100Hz comfortably. Actually this is quite impressive considering that to do this the display is written to literally 1000's of times. Just capturing data to RAM would mean that a full line could be captured in approximately 120uS depending on how the ADC was set up, this is quite a respectable time base. Once captured the results could be displayed using say 2 pixels instead of one for a clearer display.