• State Resolved
  • Locked Locked
  • Replies 14 replies
  • Subscribers 31 subscribers
  • Views 1725 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C123GH6PM: ssd2119 driver in grlib

VARAD NITIN GOKHALE
Prodigy 140 points
Part Number: TM4C123GH6PM

Hello all,

I am trying to understand the driver source code for SSD2119 provided in the graphics library. I am, at the same time, scanning through the SSD2119 data sheet provided by solomon systech.

www.kentecdisplay.com/.../SSD2119_1.4.pdf

Can anybody tell me the reason for setting/resetting the WR pin thrice instead of just once in functions like WriteCommandGPIO, WriteDataGPIO etc? The comments say it's done to adjust timing, but according to the datasheet, the set-up and hold times for data lines wrt write pulse is just 5 ns whereas, after probing the WR pin on oscilloscope the pin is low for 360ns, so one instruction is more than enough to meet requirements, or is there a different reason / my understanding is incorrect?

Also, can anyone suggest a good source for 8080 parallel interface? The datasheet I am referring is very obscure/grammatically incorrect.

Thanks!

  • 0
    TI__Guru**** 244400 points
    Hello Varad

    Which TivaWare are you referring to for the source files?
  • 0 in reply to Amit Ashara
    Prodigy 140 points
    Hi Amit,
    I am referring to Tivaware 2.1.2.111
  • 0
    Guru 47900 points

    VARAD NITIN GOKHALE said:
    can anyone suggest a good source for 8080 parallel interface?

    Google comes to mind - yet should that fail - firm/I have past Intel data-books which surely detail.

    As I recall - 8080 interface's essence was:

    • 8 bit, bi-directional, data bus
    • both /RD & /WR strobes
    • /CS control line
    • (maybe) 1 or 2 address lines

    Often yours & similar ICs accept either "8080 or 6800" style (older) interfaces.

    The 6800 is reflected above but for the "change" of /RD & /WR to a single R/W signal and the addition of an "E" strobe.   (and that's the source of the "E" required by Text Lcds...)

  • 0 in reply to VARAD NITIN GOKHALE
    TI__Guru**** 244400 points
    Hello Varad

    We have already phased out the parallel 8080 implementation in TivaWare 2.1.3 with a serial implementation as the board is not supported any more from the 3rd party.

    TM4C129x is the choice for parallel 8080 interface (BGA devices have a dedicated peripheral for LCD's)
  • 0 in reply to Amit Ashara
    Prodigy 140 points
    Amit,

    That is alright. But I have already made good progress with the earlier parallel 8080 version in hardware and even the application s/w is almost complete and working. I just need to know how and why the driver works and I will am good. I need to know in case manufacturing changes happen in the future and I need to slightly tweak the driver.

    Thanks.
  • 0 in reply to VARAD NITIN GOKHALE
    TI__Guru**** 244400 points
    Hello Varad

    I believe that since it is a 8-bit interface, the upper 8 and lower 8 bits of data to be written is being stepped into the code by means of the toggle and it seems to be a wrong comment.
  • 0 in reply to Amit Ashara
    Prodigy 140 points

    Hi Amit,

    That's right. The upper and lower bits of data are put on the data bus, but the WR line is forced low thrice. Any insight as to why that is done? To pad timing is a good reason, but timing is proper even when the instruction is written only once. Is there something I am missing? Here's the snippet. 

    static void

    WriteDataGPIO(uint16_t usData)

    {

    //

       // Write the most significant byte of the data to the bus.

       //

       SET_LCD_DATA(usData >> 8);

    HWREG(LCD_CS_BASE + GPIO_O_DATA + (LCD_CS_PIN << 2)) = 0;

       //

       // Assert the write enable signal.  Do this three times to ensure that we

       // meet the display timing requirements (20nS per instruction at 50MHz

       // means we need to ensure at least 3 instructions between edges on WR)

       //

       HWREG(LCD_WR_BASE + GPIO_O_DATA + (LCD_WR_PIN << 2)) = 0;

       HWREG(LCD_WR_BASE + GPIO_O_DATA + (LCD_WR_PIN << 2)) = 0;    //WHY THRICE??

       HWREG(LCD_WR_BASE + GPIO_O_DATA + (LCD_WR_PIN << 2)) = 0;

       //

       // Deassert the write enable signal.

       //

       HWREG(LCD_WR_BASE + GPIO_O_DATA + (LCD_WR_PIN << 2)) = LCD_WR_PIN;  WHY NOT THRICE HERE?

       //

       // Write the least significant byte of the data to the bus.

       //

       SET_LCD_DATA(usData);

       //

       // Assert the write enable signal.

       //

       HWREG(LCD_WR_BASE + GPIO_O_DATA + (LCD_WR_PIN << 2)) = 0;        //WHY THRICE??

       HWREG(LCD_WR_BASE + GPIO_O_DATA + (LCD_WR_PIN << 2)) = 0;

       HWREG(LCD_WR_BASE + GPIO_O_DATA + (LCD_WR_PIN << 2)) = 0;

       //

       // Deassert the write enable signal.

       //

       HWREG(LCD_WR_BASE + GPIO_O_DATA + (LCD_WR_PIN << 2)) = LCD_WR_PIN;    //WHY THRICE??

       HWREG(LCD_WR_BASE + GPIO_O_DATA + (LCD_WR_PIN << 2)) = LCD_WR_PIN;

       HWREG(LCD_WR_BASE + GPIO_O_DATA + (LCD_WR_PIN << 2)) = LCD_WR_PIN;

    HWREG(LCD_CS_BASE + GPIO_O_DATA + (LCD_CS_PIN << 2)) = LCD_CS_PIN;

    }

  • 0 in reply to VARAD NITIN GOKHALE
    TI__Guru**** 244400 points
    Hello Varad

    Our code bases seem to different (in construction). Following is the same code from TivaWare 2.1.2.111 Kentec drivers

    static void
    WriteDataGPIO(uint16_t ui16Data)
    {
    //
    // Write the most significant byte of the data to the bus.
    //
    SET_LCD_DATA(ui16Data >> 8);
    SysCtlDelay(3);

    //
    // Pull CS Low.
    //
    HWREG(LCD_CS_PIN_REG) = 0;
    SysCtlDelay(3);

    //
    // Assert the write enable signal.
    // Delay for at least 60nS (at 120 Mhz) to meet Display timing.
    //
    HWREG(LCD_WR_PIN_REG) = 0;
    SysCtlDelay(3);

    //
    // Deassert the write enable signal.
    //
    HWREG(LCD_WR_PIN_REG) = 0xFF;
    SysCtlDelay(3);

    //
    // Write the least significant byte of the data to the bus.
    //
    SET_LCD_DATA(ui16Data);
    SysCtlDelay(3);

    //
    // Assert the write enable signal.
    // Delay for at least 60nS (at 120 Mhz) to meet Display timing.
    //
    HWREG(LCD_WR_PIN_REG) = 0;
    SysCtlDelay(3);

    //
    // Deassert the write enable signal.
    //
    HWREG(LCD_WR_PIN_REG) = 0xFF;
    SysCtlDelay(3);

    //
    // Deassert the chip select pin.
    //
    HWREG(LCD_CS_PIN_REG) = 0xFF;
    SysCtlDelay(3);
    }

    I cannot say for sure why the same port operation is applied thrice or why a delay is applied (in my code base), except to meet setup hold time viz-a-viz the change of the latching or enable signal. I do agree it is too high w.r.t to the specification of the SSD2119. But without knowing why this existed in the first place, any clarification on removal would be improper on our side. On top of that since these method of bit banding has been phased out in favor of serial ports for TM4C123x and parallel port for TM4C129x, I am not sure if I can assist you here.

    However if the SSD2119 specification is clear on the setup hold paramters for the controller, it should be safe to assume that execution of the optimized code may be OK.
  • 0 in reply to Amit Ashara
    Prodigy 140 points
    Hi Amit,
    Thanks for answering the question. Looks like I was using the driver from "Lab10" of TivaWare Workshop, hence the different construction. Maybe I will get in touch with the vendor to try and clarify the issue. Is there a specific reason customers like me should be aware of for phasing out the bit banding method in favor of others?
    Thanks
  • 0 in reply to VARAD NITIN GOKHALE
    TI__Guru**** 244400 points
    Hello Varad

    Bit banded method works, but may not be suitable for every type of display, especially the lower cost rater displays which avoid a frame buffer but require high data throughput. So yes, scalability is one aspect I can think of when price v/s performance cost point is to be considered.
  • 0 in reply to Amit Ashara
    Prodigy 140 points
    I see. Looks like SSD2119 has what they call a "GDDRAM". Is it in essence the same thing as a frame buffer? When I probed the signals, I didn't see the MCU writing continuously to the screen.
  • 0 in reply to VARAD NITIN GOKHALE
    TI__Guru**** 244400 points
    Hello Varad

    I am not sure about the controller itself, but the display panel specifications for Kentec with SSD2119 supports an internal frame buffer. That offloads the MCU from continuous refresh. However such displays are more expensive than regular raster panels.
  • 0 in reply to Amit Ashara
    Guru 47900 points
    Appears that although sought - and answered - the request for 8080 info has been demoted.
  • 0 in reply to cb1
    Prodigy 140 points

    Hi cb1,

    It isn't demoted. I was browsing the web to see if I get explicit protocol information for 8080 interface like there's available for SPI or I2C. I haven't found any so far, but I got the "essence".

    Thanks