Announcement

Collapse
No announcement yet.

uLCD-28PT(GFX)

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • uLCD-28PT(GFX)

    I am looking at using the uLCD-28PT(GFX) with one of these:

    http://www.ftdichip.com/Products/ICs/FT2232H.htm

    which will translate bytes of pixel data being sent over USB into an 8-bit parallel data stream I can read through the GPIO Bus and then write out to the LCDs GRAM using 'disp_WrGRAM()'

    ...does this seem feasible? are there any examples that will help with this?

  • #2


    Why are you thinking of doing this?



    (If you think it is going to be much faster than existing serial using a MB5 / CE5 I don't think it will be as you will be coding everything in 4DGL which will be slower than 'Native')
    Mark

    Comment


    • #3


      How could an up to 8 or 10 Mbyte/Sec parallel transfer not be faster than up to 3M baud (375 Kbyte/Sec) serial transfer?
      And the 'coding' could be as simple as:

      1. read an 8-bit colour value from the GPIO Bus using 'bus_Read()'

      2. translate the 8-bit colour into 16-bit using 'gfx_332to565()'
      (or
      2. read another 8 bits to make up the 16-bit colour - whichever is the faster option)

      3. write the 16-bit colour to GRAM using 'disp_WrGRAM()'

      ...and rinse and repeat - is there something I am missing about this?

      Comment


      • #4


        How could an up to 8 or 10 Mbyte/Sec parallel transfer not be faster than up to 3M baud (375 Kbyte/Sec) serial transfer?
        Granted it would be faster if you were writing a program to do that in assembler or C directly on a microcontroller, however, there is no internal 4DGL function to do a direct transfer from GPIO bus to GRAM, therefore
        the code overheads of a 4DGL code loop to control the process would consume considerable time, limiting the throughput to (say) 50,000 pixels/second.
        (and thats a really rough guess without setting it up and actually trying it).
        Regards,
        Dave

        Comment


        • #5


          Looks like it might be more straightforward to leave the PICASO out altogether and just directly connect the D0-D15 Bus and RD / WR strobe pins of the FT2232H and the LCDs Driver IC together and run it that way instead?

          Comment


          • #6


            Yeah looks feasible, most of the time you will be just blitting 16bit data, and theres plenty of spare pins to do the other control lines,
            not sure what your overheads will be though generating the WR pulses and register control sequences.
            I'm not that well up on the FT2232 but if you can somehow automate the WR pin pulse automatically when
            data is presented to one of the buses your half way home to getting a reasonably fast transfer.
            Regards,
            Dave

            Comment


            • #7


              That would be faster.



              Still don't know what you are aiming to do with it.



              But assuming you could add all the required commands AND order the pixel bytes accordingly you could get get some sort of video going that way.



              Anything more complex and, well, that's what Picaso is for.
              Mark

              Comment

              Working...
              X