GC9A01 Compatability

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • GC9A01 Compatability

      Does emWIN work with the GC9A01 Driver? I am switching from a parallel screen to a 4-line SPI screen that uses the GC9A01 controller but so far have had no luck. I am using GUIDRV_FLEXCOLOR_F66709 with GUIDRV_FLEXCOLOR_M16C1B8 because there is no read operation supported with the GC9A01.

    • Hi,


      JackO wrote:

      Does emWIN work with the GC9A01 Driver?

      Never had one of these controllers on my desk, but according to the data sheet it should work.

      It seems the commands of the GC9A01 are compatible with GUIDRV_FLEXCOLOR_F66709 and GUIDRV_FLEXCOLOR_F66720.

      GUIDRV_FLEXCOLOR_M16C1B8 should be correct, too.

      A cache is required, as there are no read operations possible (you already figured this out).

      I'm not entirely sure how it behaves with read functions being set. So, maybe you have to set a couple of dummy functions which simply return 0.

      Regards,
      Sven
      Please read the forum rules before posting.

      Keep in mind, this is *not* a support forum.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/
      Or you can contact us via e-mail.

    • Hi Sven,

      I spent a few weeks debugging my code and trying to figure out what was wrong. I found a decent number of other changes I had to make but still no success. With the cache enabled, the screen was displaying a bunch of random garbage. After probing up the SPI lines I found that the data being sent was the same as the data at the VRAM address 0x0000000.

      I have no clue as to why emWIN would read from this location. Was I supposed to set the address for VRAM? VRAM is not mentioned for the FLEXCOLOR driver in the datasheet I have been referencing so I am not sure how to fix that.

      Last week I disabled the cache, so set to GUIDRV_FLEXCOLOR_M16C0B8, and made dummy read functions for the read functions below. With this configuration I am running into no hard faults, and it is displaying correctly. I think that I am able to get away with this since the screen I am using has 129.6 Kbytes of on-chip display ram but I am unsure. 1.28inch Round LCD Display Module, 65K RGB Colors, 240×240 Resolution, SPI Interface (waveshare.com)


      Side Note: I am using 8-bit transfers and noticed that commands were being sent incorrectly for the driver. Every time I send a command myself it would work fine. Using emWIN, when sending a command, it would send 8 0's and then the correct 8-bit command. The root of this issue is in the guidrv_flexcolor_Func66709 file. The _setreg_B8 function seems to be taking in the 8 bits, casting it to a 16-bit int, and then sending the command. This results in the subsequent 0's and then the correct command. I just commented out a line of code and recompiled the library to fix the issue but wasn't sure if there was another solution to this. Could just be that the drivers aren't explicitly meant for GC9A01. Another really simple solution was to check if the command being sent was "00" and then to not send it but I didn't like that one, though it did work.
      My Questions to you:
      1. Do you see there being complications with using dummy read functions and no cache, even though reading from the display is not supported?
      2. If I were to re-enable cache, how would I configure it correctly?
      3. Do you think I will notice much of a performance increase by using 16-bit transfers instead of 8-bit?
      Images

      • read_functions.png

        16.55 kB, 1,049×91, viewed 189 times