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.

Interface MSP430FG4618 with Sharp LQ043T1DG01 TFT-LCD display.

Other Parts Discussed in Thread: MSP430FG4618, LM3S1968

Hello E2E community.

     I am trying to drive a 480 x 270 LCD with the MSP430FG4618.  I have found an algorithm for the touch screen part, but I cannot find any support for the display aspect of the software.  Because the LCD requires a 24 bit word for color, I have accepted the fact that I am going to have to use bit banging to send that amount of information.  I am coming to the forum to see if anyone has had any success with this process.  I was also hoping to find if someone may have a software driver for sharing or purchase.  At this time I am restricted to using the MSP430, but I may be able to switch controllers if I absolutely cannot make the MSP430 work.  Thank you in advance for any reply.



  • First, the display is officially announced as discontinued. So I really wouldn't start a new project with it.

    Then it is surely not the type of display to be used with an MSP processor. Except if you jsut want to use the MSP as dumb data-forwarder.

    Ther eis no need for bit-banging. You can assign three of the MSPs ports to the R, G and B 8-bit data lines. Write the separate 8 bit data for each color to the three ports and then toggle the transfer signal. Of course there is no 24bit data port that can be written to with a 24 bit value write operation.

    The basic processing of the interface is as follows:

    You need:

    • 3 ports with 8 bit connected to the 2*8 lines for R, G and B color data.
    • 1 port pin (on a 4th port) connected to HSYNC
    • 1 port pin connected to VSYNC
    • 1 port pin connected to CK (clock)
    • 1 port pin connected to DISP.

    Proceed as follows:

    1. pull VSYNC low
    2. pull HSYNC low and release it at least once. Obey the minimum os/off timings
    3. release HSYNC
    4. pull HSYNC low and release it three times
    5. pull CK low and release it three times (obey the minimum timing)
    6. now you can write the RGB data for the to peft pixel to the three data ports
    7. pull CK low and release it
    8. write the three bytes for the next pixel
    9. pull CK low and release it
    10. repeat from 8 until you have sent 480 pixels.
    11. pull CK low and release it two more times.
    12. pull HSYNC low and release it to start the second row.
    13. repeat from 5 until you have sent all 240 rows. This is 270*480*4 = 380kB of data (!!!)
    14. pull HSYNC down three more times and release it, then goto 1 for the next screen update.

    The DISP signal needs to be pulled down as long as the voltages are not settled and needs to be released before the above sequence starts.

    Because of the mass of data required for driving this kind of display, I doubt there is a library for the MSP. The plain screen update will take over a second, not counting any calculation of the data to be written. And there seems to be no way to directly alter something on screen (for 'writing' on it based on X/Y coordinates.) All the data needs to be passed from top left to bottom right completely. So you have to assemble it beforehand. And the MSP definitely has not enough ram to do so. Even if you would only pass 0xffffff or 0x000000 (plain B/W, 1 bit storage per pixel) to the display, you'd still require 16k of ram for storing the image. Which is all that even the biggest MSPs offer.

  • Thanks for the reply.  I did not consider the fact that all of the display data would have to be loaded in RAM every time a change to the display was made.  I was hoping there was a way to only update the affected area on the display.  I am considering using gray scale instead of the full 16 million colors.  I am afraid that the display will still require the full 24 bit word.  As far as using this display, my hands are tied.  This is for a school project and our budget is very limited.  I may however be able to use a different MCU, even if its sole purpose is to drive this LCD.  Would you have any recommendations for a certain hardware component that would be able to communicate more efficiently with this display?  Anything that would cut back on the amount of software would be a huge load off my shoulders.  Again, thank you for the reply.


  • Hey Bugs,

    Thanks for the suggestions.  These display setups look like they would do the job with no problem, and would definitely make my job that much easier.  The problem however is that they are all pretty expensive.  I had to pull teeth to get the $70 discontinued display I have now.  What do you think about switching to a Stellaris processor?  I looked at the LM3S1651.  It has all the required hardware specs, but my main concern is with programming.  Does the Stellaris use C code through IAR like the MSP430s, or do I need to program in assembly (which I am not very confident in doing)?  I am very familiar with the MSP MCUs, so my main concern is how similar are the MSP and the Stellaris as far as programming them?




  • Hi Drew,

    well, the programming language is up to you! You can program the Stellaris devices in assembly and/or C (or both).

    The problem is, you will need to have a new IDE for working with Stellaris (in case of IAR). When using (at least) the microcontroller edition of CCS (Code Composer Studio) support for Stellaris is included! You can also apply for a 30 days test license (and re-new them by another 90-days) for working with these devices.

    Well, if you don't need the extra processing power for your application, then there's no need to switch over to Stellaris. I mentioned them, because there is a nice driver library available which speeds up your 'display' development (GUI, HMI design or whatever you'll call it).


  • Hey Bugs,

    I am thinking about switching now mainly for the driver library, like you said it will make the GUI development a much easier task, especially considering that I may have to write my own library for the MSP seeing as I have been unsuccessful in my attempts to find any.  I also figured I needed to switch because of the limitations of the RAM in the MSP and not so much the processing power.  The reply I got from Jens said that I would require a minimum of 16k of RAM just for a black or white screen which is all of the RAM the MSP has.  A classmate of mine suggested I try to integrate a dedicated stick of RAM with the MSP, but I figured that if the processor itself had enough on-board RAM that would make hardware and software development that much easier.  I am however assuming the 32k of RAM on the Stellaris MCU I am looking at is sufficient enough to update the display in color, I may just get one with the max 96k of RAM just to be safe.  The bottom line is that I am less worried about using the right tool for the job than I am about finishing the job, ie.  I have no problem driving a finish nail with a sledge hammer.  Another benefit of using the Stellaris is to aid my transition to a 32 bit MCU, putting on my big boy pants one leg at a time!

    Thanks Bugs,


  • There's another approach that can make things easier in terms of resources and handling. It is, however, a different approach I (not only I) used for printing on the GEOS OS.

    There everything to be shown was not immediately printed to screen (and forgotten) but kept in a graphics string (actually containing typogrphic commands, drawing commands etc.). These strings were very short (e.g. 5 bytes for 'draw line from current location to' command, destination X and destination Y coordinate). This chain of commands was used to draw on the screen, but also for printing.

    The key was that when printing, a 'full screen' of the printer was 300x300DPI *8*12" = 8Mpixels. Way too much for the memory of an XT or AT ystem and even 386er systems didn't have that much memory, not to speak of the ram reequired for the OS itself and the application.

    They solfed it by defining just a 'window' on the printer of a few lines height. Then the drawing chain was performed over this window, clipping everything outside. This window was written to the printer, cleared, 'moved' virtually down and the procedure continued.

    You could do the same for this display: Just reserve a buffer for one single line, which will fit into 1.5k (even full color). Then 'draw' the image to a virtual screen, keeping only pixels that are drawn in the current line. Then transfer this line to the display, clear it and repeat for the next line. This will allow you to handle almost any screen size with a few kb ram - at the expense of updating speed.

    If something is to be drawn, jsut add the drawing command to the cached command list. (A clear command will of course simply clear the list)

    THis approach even allows erasing something from screen that has overwritten something else. Simply remove the command from the command list and on next update it will appear but what was drawn before (and previously overwritten) will be there again. This way, even popup windows or pulldown menues are easy to handle.

    Due to the complexity of this task, I would still dedicate a separate processor to the screen handling. Doing the screen update and have an application running on the same processor isn't a nice thing.

  • Hi,

    as already mentioned: I don't think that you will be able to interface/access this 4.3in TFT to the MSP430!

    Well, it's not TI, but maybe it's worth to have a look at it: (4.3in TFT from Ampire), or (uses 4.3in Sharp TFT)

    The Renesas RX features a EXDMA, which is a DMA from external memory (frame buffer RAM) to external memory (TFT display). The external DMA needs nearly no intervention of the CPU leaving around 90% of the processing power available to the application.


  • Hey guys,

    Thanks again for all of the feedback.  I think what I may try to do is to use the LM3S1968 Eval Kit to drive the display and handle the application.  The application part of this project is not very intense, a real time clock with alarm function and a wireless interface with a remote weather station.  Without a doubt the hardest part is going to be developing a GUI and driving that discontinued display.  Do you foresee any problems with me trying to drive a display of that size with the Eval Kit I mentioned before?



**Attention** This is a public forum