• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 30 subscribers
  • Views 2670 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.

RA8875 tft controller driver lib

Kyriakos Pavlidis
Intellectual 260 points

i have a 7" tft module with RA8875 controller (spi protocol).

I am new with ti launchpads and i have a tm4c123glx and a tm4c1294.

I checked grlib and i need to ask if there is a driver library for RA8875 controller like there is with the kentech display?

  • 0
    TI__Guru**** 244400 points

    Hello Kyriakos,

    We do not have a driver library for RA8875 controller as part of TIVAWare.

    Regards

    Amit

  • 0 in reply to Amit Ashara
    Intellectual 260 points

    Is there any third party library? in order to use the rest of the grlib? Or should i fix it alone, cause i am not sure what are the functions that need to be implemented for this driver in order to work with the rest of the grlib and the widget. Any help will be wonderful. 

  • 0 in reply to Kyriakos Pavlidis
    Guru 47900 points

    That RA8875 TFT Controller is rather unique due to its SPI data port and several, automated, screen-handling functions which (attempt) to overcome the (usual) delays imposed by serial vs. parallel data transfers.  Suspect that it's a bit too new for (real) 3rd party ports to have arrived.

    In the past - vendor's Dave W. would usually speak to the "ease" of creating a unique/custom display driver - which left the great bulk of the Stellaris Graphic Library intact.  Believe this remains your best/easiest/quickest direction today.

    That graphic library performs its processing magic upon your data, images, and fonts - and at its, "back end" presents the processed data upon an 8 bit, MCU gpio port - accompanied by several strobes/level signals - resident upon a 2nd gpio port.  It may be that those strobes/levels may remain unchanged (good review of RA8875 data required) but surely you'll have to prepare the (past) processed, 8 bit, parallel data for transmission (now) via SPI. 

    It's normal that data must first be presented - and meet set-up/hold specs - prior to the arrival of any required strobes/level signals.  Its unknown now if the existing graphic library will violate RA8875 signal requirements due to the (relatively) late arrival of the 8 bit (data bus) - now via SPI.  (I'd suspect this)  Work-around would modify the past graphic driver lib so that the strobes/levels (again on a separate parallel, MCU port) would arrive after the SPI data has arrived & stabilized.

    This should encompass the essence - devil always, "in the details."

    There is always some danger in user acceptance of a pixel-rich display "bossed about" by a serial interface.  Slower than expected CLS (screen clears) and 16 bit (or greater) large, color images may raise concern.  The IC does make some effort to automate key processes - but w/out full analysis & live evaluation - it's difficult to pass judgement.

    An alternative "big-screen" TFT Controller is SSD1963 - which accommodates a 16 bit data bus - thus is guaranteed to provide faster screen clears and image updates...

    For completeness - image handling is the province of bigger, more powerful ARM MCUs.  (i.e. A and/or R family)  Cell phones and (especially) Tablets are likely to "run rings around" any vendor's M4 coupled to a serial-driven,TFT controller.  And - like it or not - that "tablet" performance standard is what (your) creation will be measured against...

    [edit] upon engaging a few more brain cells - withdrawn is the CLS limitation - advanced earlier.  Concern still runs high in this TFT chip's ability to render irregular pixel graphics (i.e. a color photo) at a reasonable rate - bogged down as it is by SPI interface.  Suspect that any screen draw involving substantial MCU -> TFT IC data transfers will be painfully slow...