Precompiled STEMWIN + unsupported SSD2119

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

    • Precompiled STEMWIN + unsupported SSD2119

      Hi,

      I am trying to use the st precompiled stemwin on an stm32f4 but with an SSD2119 controller.
      This is controller not selectable in the cubemx SW, though SSD1355 is. If I toggle between the SSD1355 and ST7735 (a controller i used successfully in the past with stemwin) there is no difference in generated code so I was hoping I could get away with the SSD2119 :)

      Alas, it does not work, and one problem I am aware of so far is that stemwin will try to set up the drawing area using the ST7735 caset, raset and ramrw registers 0x2a, 0x2b and 0x2c
      The mechanism to do something similar on the SSD2199 is completely different (involving other registers such as 0x48 , 0x49).

      Now I am a bit confused because there are some older threads on this forum where ppl use stemwin on an SSD2119 (eg Problems with drawing speed)

      The only way i can think of now is to try detect caset/raset/ramrw accesses into the corresponding SSD2119 equivalents.
      Or am I missing something here ?

      And would it be possible to get an overview of all the registers stemwin tries to write and that I would need to remap this way ?
      Or is stemwin only setting these registers at the start for the full screen and can I get away with just stubbing these calls if I set the memory area to the full display in my own SSD2199 specific init code ?
      (second post in Precompiled library with STM32F4 and ssd1289 controller kind of implies that)

      Thanks,
      Bram

      The post was edited 1 time, last by BramPeeters: Fixed name of the controller ().

    • Hi,

      both controller are supported by the GUIDRV_FlexColor driver.

      When setting up the driver you have to use GUIDRV_FLEXCOLOR_F66714 for the SSD2119 and GUIDRV_FLEXCOLOR_F66709 for the SSD1355/ST7735.

      Basically, that's all. YOu might have to adapt the read and write routines set in the device API structure.

      Regards,
      Sven