Support for TFT and touch screen - need feedback and testing

[jmz52]

TFT screens with optional touch panel can be used to control Marlin Low-level IO uses DMA for background data transfer to TFT screen to minimize impact on Marlin's performance.

Current low-level IO implementation is for HAL STM32 and MCU STM32F1 only. SPI implementation lacks STM32F4 initialization code. FSMC implementation STM32F4 initialization code and (temporary) hardcoded to Zx specific. Implementation for STM32F4 and FSMC on VE chips will follow.

Implemented Marlin_UI class for 320x240 screen. Can be used with or without rotary encoder. Support UBL or advanced pause is not implemented yet.

Tested on MKS Robin v2.4 with TFT v2.0 (ST7789v controller)

Earlier builds were tested on EZT-T1 and SKR Mini v1.1 with 128x128 (st7735 controller) but UI 128x128 became outdated due to changes made during touch support development. UI 128x128 implementation will be uploaded once code is updated.

SPI IO required dedicated hardware SPI interface wich can't be shared with SD card. Should be OK to use same SPI for TFT screen and touch panel.

Build environment for MKS Robin - https://github.com/MarlinFirmware/Configurations/pull/114 https://github.com/jmz52/Configurations/tree/mks_robin_hal_stm32/config/examples/Mks/Robin_HAL_STM32

[jmz52]

@ETE-Design, MKS TFT or MKS Robin TFT? MKS TFT is smart screen with it's own MCU and firmware. It is connected to main board via COM port. This code is not applicable to MKS or BTT smart screens. MKS Robin TFT does not have it's own MCU and depends on main board (MKS Robin). These screens are supported.

[dandantsui]

@jmz52 I use a MKS_Robin with TFT on my printer. Happy to test out if you need.

[enry68]

Compliments !!! I whish to try to port your work on the Anycubic Trigorilla Pro board with colours TFT. What about it ? Do you think is it possible ? Thank you and again compliments for your job. Enrico.

[hobiseven]

As long as you have enough flash ( 64kb) and ram (20ko+) and a fast spi with dma or better a 16 bit Port with dma that will work. Note for 8bit avr that will be a challenge... works so far on stm32f103 . Due should be fine so as lpc1768.

[enry68]

Trigorilla Pro has 32bit processor ...

[hobiseven]

Then you need to adapt the Hal and get 3 basic functions ported: display flush callback, touch callback ( might be exactly the same as the one implemented) and the custom timer for lvgl. That s all! Lvgl documentation has a good porting guide all is explainned

[enry68]

Then you need to adapt the Hal and get 3 basic functions ported: display flush callback, touch callback ( might be exactly the same as the one implemented) and the custom timer for lvgl. That s all! Lvgl documentation has a good porting guide all is explainned

Thank you very much!

[jmz52]

@enry68 jus to make sure there is no misunderstanding. There are two different implementation of TFT UI.

Backported MKS UI for 480x320 TFT screens - https://github.com/MarlinFirmware/Marlin/pull/18071 Developed for STM32F1xx MCUs (HAL STM32F1) Based on LVGL library.

Implementation of native Marlin menu system for 320x240 TFT screens - https://github.com/MarlinFirmware/Marlin/pull/18130. Developed for new HAL STM32 and tested on STM32F1 and STM32F4 MCUs. Does node use external libraries in current implementation.

If I recall correctly the Trigorilla Pro board is based on STM32F103Zx MCU with TFT screen connected to FSMC interface. Do you have pinmap for your board?

[enry68]

@enry68 jus to make sure there is no misunderstanding. There are two different implementation of TFT UI.

Backported MKS UI for 480x320 TFT screens - #18071 Developed for STM32F1xx MCUs (HAL STM32F1) Based on LVGL library.

Implementation of native Marlin menu system for 320x240 TFT screens - #18130. Developed for new HAL STM32 and tested on STM32F1 and STM32F4 MCUs. Does node use external libraries in current implementation.

If I recall correctly the Trigorilla Pro board is based on STM32F103Zx MCU with TFT screen connected to FSMC interface. Do you have pinmap for your board?

Ciao, and thank you very very much! Yes I've extracted the pinout from the schematics and compared it with MKS Robin (pro). I've made and excell file with this table. Can you help me for the implementation ? Is it possible to attach here the excel file ?

I try anyway to insert here:

TRIGORILLA DISPLAY PINOUT

1	3.3V
2	N.C.
3	N.C.
4	N.C.
5	GND
6	PD15
7	PD14
8	PD0
9	PD1
10	PD7
11	PD11
12	PD5
13	PD4
14	PD13
15	PE7
16	PE12
17	PE13
18	N.C.
19	PE14
20	PE15
21	PD8
22	PD9
23	PD10
24	PB6
25	PA6
26	PA7
27	BOOT0
28	PA5
29	PF11
30	PE8
31	PE9
32	PE10
33	GND
34	GND
35	GND
36	N.C.
37	N.C.
38	3.3V
39	3.3V
40	3.3V

MKS ROBIN DISPLAY PINOUT

1	3.3V
2	GND
3	PD14
4	PD15
5	PD0
6	PD1
7	PE7
8	PE8
9	PE9
10	PE10
11	PE11
12	PE12
13	PE13
14	PE14
15	PE15
16	PD8
17	PD9
18	PD10
19	PD7
20	PD11
21	PD5
22	PD4
23	PC6
24	PD13
25	PB14
26	X
27	PB15
28	PC5
29	PB13
30	VCC
31	PA7
32	GND

[enry68]

TrigorillaPro-MKSNano.xlsx

Done!

[jmz52]

@enry68 Is you board supported in Marlin? If not you need complete pinout to make a pins definition file - heaters, thermistors, endstops, stepper motors, UART(s). You need to get Marlin running on your board before you add new code to use TFT screen. Also do you know if your board's bootloader uses firmware encryption?

[jmz52]

@dandantsui you can get latest code from https://github.com/jmz52/Marlin/tree/tft_and_touch_screen and add following build environment to platformio.ini file

[env:mks_robin_stm32]
extends          = common_stm32
board            = genericSTM32F103ZE
board_build.core = stm32
board_build.variant = MARLIN_F103Zx
board_build.ldscript = ldscript.ld
board_build.offset = 0x7000
board_build.firmware = Robin.bin
build_flags       = ${common_stm32.build_flags}
 -DTRANSFER_CLOCK_DIV=8 -DHAVE_HWSERIAL3
 -DHAL_SRAM_MODULE_ENABLED -DHAL_SD_MODULE_ENABLED
 -DHAS_GRAPHICAL_TFT -DHAS_FSMC_TFT -DTFT_320x240 -DTOUCH_SCREEN
 -DULTIPANEL -DLCD_HEIGHT=6 -DNO_LCD_REINIT
build_unflags     = ${common_stm32.build_unflags} -DUSBCON -DUSBD_USE_CDC
extra_scripts     = pre:buildroot/share/PlatformIO/scripts/generic_create_variant.py
  buildroot/share/PlatformIO/scripts/stm32_bootloader.py
  buildroot/share/PlatformIO/scripts/mks_encrypt.py
lib_deps =

And you need to disable #define FSMC_GRAPHICAL_TFT and #define TOUCH_BUTTONS in Configuration.h file

Two more things. You need to disable BEEPER_PIN on pins file and add TFT and touch pins definition

//#define BEEPER_PIN         PC13
#define LED_PIN            PB2

#define TFT_RESET_PIN      PF6
#define TFT_BACKLIGHT_PIN  PG11
#define TFT_CS_PIN         PG12  // NE4
#define TFT_RS_PIN         PF0   // A0

#define TOUCH_CS_PIN     PB1   // SPI2_NSS
#define TOUCH_SCK_PIN    PB13  // SPI2_SCK
#define TOUCH_MISO_PIN   PB14  // SPI2_MISO
#define TOUCH_MOSI_PIN   PB15  // SPI2_MOSI
#define TOUCH_INT_PIN    -1

[enry68]

@enry68 Is you board supported in Marlin? If not you need complete pinout to make a pins definition file - heaters, thermistors, endstops, stepper motors, UART(s). You need to get Marlin running on your board before you add new code to use TFT screen. Also do you know if your board's bootloader uses firmware encryption?

Yes, I've tested already Marlin 2.0.5 with display and touch(the slow and monocromatic version) . I don't know if my bootloader uses FW encryption (I suppose no). To load Marlin FW in the past I've anyway used ST-Link. Thank you very much for your support.

[jmz52]

@enry68 please attach your Configuration.h, Configuration_adv.h, pins file platformio.ini file with your build environment.

[enry68]

@jmz52 Thanks very much Alexander. I've used this environment: https://github.com/SXHXC/Marlin-Anycubic-Predator-Trigorilla-PRO

Can this be usefull ? I suppose there are all files that you asked me.

[enry68]

@jmz52 Hi Alexander did you have read the files? Mine are the same because I've used that great work.

[davidtgbe]

Hi Alexander, I'm going to try to adapt your great work for use with Anet ET4 which has 8 bit FSMC interface with a ST7789V tft mcu (https://github.com/davidtgbe/Marlin). Any hint or clue would be appreciated because I'm not very experienced with STM32 and marlin :)

By now, I think I would have to change FSM init to use 8 bit data...

Thanks!

PINS: P1_1_LCD_9_CSX => PD7 P1_2_LCD_11_WRX => PD5 P1_3_TOUCH15/CS => PB2 P1_4_TOUCH_14_DIN => PE5 P1_5_TOUCH_12_DOUT => PE4 P1_6_TOUCH_16_DCLK => PB0 P1_7_TOUCH11/PENIRQ => PB1 P1_8_LCD_12_RDX => PD4 P1_9 => GND P1_10 => 3.3V

P2_1_LCD_15_RESX => PE6 P2_2_LCD_10_DCX => PD13 P2_3_LCD_26_DB9 => PD15 P2_4_LCD_25_DB8 => PD14 P2_5_LCD_28_DB11 => PD1 P2_6_LCD_27_DB10 => PD0 P2_7_LCD_30_DB13 => PE8 P2_8_LCD_29_DB12 => PE7 P2_9_LCD_32_DB15 => PE10 P2_10_LCD_31_DB14 => PE9

[jmz52]

@dandantsui I've updated code in https://github.com/jmz52/Marlin/tree/tft_and_touch_screen There is a new build environment for MKS Robin that supports new UI - mks_robin_stm32. You need to enable two parameters in Configuration.h file 'TFT_320x240' and 'TOUCH_SCREEN' and compile using new build environment.

[jmz52]

@enry68 I've checked that repository and code there should be sufficient to create new build environment for Trigorilla Pro board. However the TFT screen you have is 480x320 while current UI implementation is for 320x240 screen. I will get back to Trigorilla Pro build environment once I get my new 480x320 SPI screen working.

[jmz52]

@davidtgbe if I recall correctly FSMC reconfiguration to 8 bit will not be sufficient - there are places in code that operate with pixels (2 bytes) and logic there expects 16 bit data transfers. I would at least expect problem with bigendian and littelendian color format.

[jmz52]

@tpruvot, @hobiseven I've updated code and build environment for Alfawise U20 - https://github.com/jmz52/Marlin/tree/Alfawise_U20

Build environments in platformio.ini are [env:STM32F103VE_longer_stm32] and [env:STM32F103VE_longer_stm32_no_bootloader]

Compiled firmware for bootloader and for ST-Link Once again - watch the heaters. Open-drain gpio output is yet to be tested with HAL STM32.

[jmz52]

Beware the MSP3520 module! MSP3520 does not support 16-bit colors in SPI mode. Module uses 18-bit color mode which is 50% slower (3 bytes per pixel instead of 2) and require additional compute power to "unpack" 16-bit color to 18-bit before sending to display. It looks like this TFT screen uses ILI9486 controller rather than ILI9488. TFT UI implementation uses 16-bit colors and does not support MSP3520 module and/or ILI9486 in SPI mode.

[xC0000005]

If we were using SPI flash, the process which packs the assets for SPI flash could do the conversion. But I agree, 18bpp is less than ideal. 33% overhead for two more bits.

On Jun 25, 2020, at 10:19 PM, Alexander Gavrilenko notifications@github.com wrote:

 Beware the MSP3520 module! MSP3520 does not support 16-bit colors in SPI mode. Module uses 18-bit color mode which is 50% slower (3 bytes per pixel instead of 2) and require additional compute power to "unpack" 16-bit color to 18-bit before sending to display. It looks like this TFT screen uses ILI9486 controller rather than ILI9488. TFT UI implementation uses 16-bit colors and does not support MSP3520 module and/or ILI9486 in SPI mode.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[jmz52]

Implemented Marlin_UI class for 480x320 screen. Reminder - do NOT buy this TFT module. It is not supported by Marlin.

[mapfde]

Here is the code running on Lerdge-S with its 480x320 screen:

[xC0000005]

Confirmed it also runs fine on Lerdge K. So all three have working LCDs with this code. The K board uses all three SPI devices, though, so that will require some work.

On Jun 26, 2020, at 4:52 PM, Magnus Pfeffer notifications@github.com wrote:

 Here is the code running on Lerdge-S with its 480x320 screen:

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[davidtgbe]

@davidtgbe if I recall correctly FSMC reconfiguration to 8 bit will not be sufficient - there are places in code that operate with pixels (2 bytes) and logic there expects 16 bit data transfers. I would at least expect problem with bigendian and littelendian color format.

Changed FSMC to 8 bits and, as you well said I'm having problems with colors. I suppose that half of pixel info is not transmitting... So, I've also changed DMA transfers to 8 bits, and doubled counter as below:

--- DMA SETUP --- DMAtx.Init.PeriphDataAlignment = DMA_PDATAALIGN_BYTE; DMAtx.Init.MemDataAlignment = DMA_MDATAALIGN_BYTE; ....

void TFT_FSMC::TransmitDMA(uint32_t MemoryIncrease, uint16_t *Data, uint16_t Count) ... DMAtx.Instance->NDTR = (Count*2); DMAtx.Instance->PAR = (uint32_t)Data; DMAtx.Instance->M0AR = (uint32_t)&(LCD->RAM);

But no luck... colors are still incorrect.

[xC0000005]

What did you set the IM mode to in your init sequence?

On Jul 2, 2020, at 3:21 PM, davidtgbe notifications@github.com wrote:

@davidtgbe https://github.com/davidtgbe if I recall correctly FSMC reconfiguration to 8 bit will not be sufficient - there are places in code that operate with pixels (2 bytes) and logic there expects 16 bit data transfers. I would at least expect problem with bigendian and littelendian color format.

Changed FSMC to 8 bits and, as you well said I'm having problems with colors. I suppose that half of pixel info is not transmitting... So, I've also changed DMA transfers to 8 bits, and doubled counter as below:

DMAtx.Init.PeriphDataAlignment = DMA_PDATAALIGN_BYTE; DMAtx.Init.MemDataAlignment = DMA_MDATAALIGN_BYTE; `

DMAtx.Instance->NDTR = (Count*2); DMAtx.Instance->PAR = (uint32_t)Data; DMAtx.Instance->M0AR = (uint32_t)&(LCD->RAM);

But no luck... colors are still incorrect.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/18129#issuecomment-653243278, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHVGS4LJAHNRTW3YU4BBZHDRZUB5JANCNFSM4NL5RISQ.

[xC0000005]

Never mind. I think those pins are soldered to configure, not an init sequence thing. When SPI flash is working as an image source, you could do a bit-depth conversion on all the images to be 8 bit, but it’s not going to be a simple init thing. Sorry.

On Jul 2, 2020, at 3:30 PM, JC Nelson authorjcnelson@gmail.com wrote:

What did you set the IM mode to in your init sequence?

On Jul 2, 2020, at 3:21 PM, davidtgbe <notifications@github.com mailto:notifications@github.com> wrote:

@davidtgbe https://github.com/davidtgbe if I recall correctly FSMC reconfiguration to 8 bit will not be sufficient - there are places in code that operate with pixels (2 bytes) and logic there expects 16 bit data transfers. I would at least expect problem with bigendian and littelendian color format.

Changed FSMC to 8 bits and, as you well said I'm having problems with colors. I suppose that half of pixel info is not transmitting... So, I've also changed DMA transfers to 8 bits, and doubled counter as below:

DMAtx.Init.PeriphDataAlignment = DMA_PDATAALIGN_BYTE; DMAtx.Init.MemDataAlignment = DMA_MDATAALIGN_BYTE; `

DMAtx.Instance->NDTR = (Count*2); DMAtx.Instance->PAR = (uint32_t)Data; DMAtx.Instance->M0AR = (uint32_t)&(LCD->RAM);

But no luck... colors are still incorrect.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/18129#issuecomment-653243278, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHVGS4LJAHNRTW3YU4BBZHDRZUB5JANCNFSM4NL5RISQ.

[davidtgbe]

Never mind. I think those pins are soldered to configure, not an init sequence thing. When SPI flash is working as an image source, you could do a bit-depth conversion on all the images to be 8 bit, but it’s not going to be a simple init thing. Sorry.

Correct J.C, IM pins are soldered to use 8080-I 8bit / 16bit pixel interface. My theory was that if I receive a buffer with the pixels to be printed, and they are printed OK using the FSMC/DMA 16bit wide:

[half_word_pixel1] [half_word_pixel2] ...

I could simply double DMA transactions splitting data on 8bit chunks and setting up a 8 bit FSMC/DMA.

[1st_byte_pixel1] [2nd_byte_pixel1] [2nd_byte_pixel2] ...

as shown in ST7789 Manual page 71.

But, clearly I'm missing something because graphics structure are ok, but colors are not. May be I have to swap pixel bytes...

[xC0000005]

Hmm. There’s a lookup table even in 16 bit mode. If Anet released their code, you ould try swapping in their init sequence. If they didn’t, and you have their firmware, point me to it and I’ll extract the sequence to see if they’re setting some sort of color lookup/correction (Lerdge does this, and we have to use the same sequence or the colors are way off).

On Jul 2, 2020, at 3:56 PM, davidtgbe notifications@github.com wrote:

Never mind. I think those pins are soldered to configure, not an init sequence thing. When SPI flash is working as an image source, you could do a bit-depth conversion on all the images to be 8 bit, but it’s not going to be a simple init thing. Sorry. … <x-msg://13/#> On Jul 2, 2020, at 3:30 PM, JC Nelson @.> wrote: What did you set the IM mode to in your init sequence? > On Jul 2, 2020, at 3:21 PM, davidtgbe @. @.**>> wrote: > > > @davidtgbe https://github.com/davidtgbe https://github.com/davidtgbe https://github.com/davidtgbe if I recall correctly FSMC reconfiguration to 8 bit will not be sufficient - there are places in code that operate with pixels (2 bytes) and logic there expects 16 bit data transfers. > I would at least expect problem with bigendian and littelendian color format. > > Changed FSMC to 8 bits and, as you well said I'm having problems with colors. I suppose that half of pixel info is not transmitting... > So, I've also changed DMA transfers to 8 bits, and doubled counter as below: > > DMAtx.Init.PeriphDataAlignment = DMA_PDATAALIGN_BYTE; > DMAtx.Init.MemDataAlignment = DMA_MDATAALIGN_BYTE; ` > > DMAtx.Instance->NDTR = (Count2); DMAtx.Instance->PAR = (uint32_t)Data; DMAtx.Instance->M0AR = (uint32_t)&(LCD->RAM); > > But no luck... colors are still incorrect. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub <#18129 (comment) https://github.com/MarlinFirmware/Marlin/issues/18129#issuecomment-653243278>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHVGS4LJAHNRTW3YU4BBZHDRZUB5JANCNFSM4NL5RISQ https://github.com/notifications/unsubscribe-auth/AHVGS4LJAHNRTW3YU4BBZHDRZUB5JANCNFSM4NL5RISQ. >

Correct J.C, IM pins are soldered to use 8080-I 8bit / 16bit pixel interface. My theory was that if I receive a buffer with the pixels to be printed, and they are printed OK using the FSMC/DMA 16bit wide: [half_word_pixel1] [half_word_pixel2] ... I could simply double DMA transactions splitting data on 8bit chunks and setting up a 8 bit FSMC/DMA. [1st_byte_pixel1] [2nd_byte_pixel1] [2nd_byte_pixel2] as in https: //www.newhavendisplay .com / appnotes / datasheets / LCDs / ST7789V.pdf -> page 71.

But, clearly I'm missing something because graphics structure are ok, but colors are not. May be I have to swap pixel bytes...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/18129#issuecomment-653252208, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHVGS4LVNKP6VMRYHKZAAJTRZUGAXANCNFSM4NL5RISQ.

[davidtgbe]

Hmm. There’s a lookup table even in 16 bit mode. If Anet released their code, you ould try swapping in their init sequence. If they didn’t, and you have their firmware, point me to it and I’ll extract the sequence to see if they’re setting some sort of color lookup/correction (Lerdge does this, and we have to use the same sequence or the colors are way off).

Anet releasing their code is not an option I'm afraid... That's why I'm trying to adapt ET4 stock MB and TFT to Marlin -> ET4 Marlin Project (because of that, and because I like this kind of challenges :).

You can find the firmware here And, just in case... Bootloader

[xC0000005]

Ok, I found their init sequence. Looking into it.

On Jul 2, 2020, at 4:14 PM, davidtgbe notifications@github.com wrote:

Hmm. There’s a lookup table even in 16 bit mode. If Anet released their code, you ould try swapping in their init sequence. If they didn’t, and you have their firmware, point me to it and I’ll extract the sequence to see if they’re setting some sort of color lookup/correction (Lerdge does this, and we have to use the same sequence or the colors are way off). … <x-msg://16/#> On Jul 2, 2020, at 3:56 PM, davidtgbe @.*> wrote: Never mind. I think those pins are soldered to configure, not an init sequence thing. When SPI flash is working as an image source, you could do a bit-depth conversion on all the images to be 8 bit, but it’s not going to be a simple init thing. Sorry. … x-msg://13/# On Jul 2, 2020, at 3:30 PM, JC Nelson @.> wrote: What did you set the IM mode to in your init sequence? > On Jul 2, 2020, at 3:21 PM, davidtgbe @. @.>> wrote: > > > @davidtgbe https://github.com/davidtgbe https://github.com/davidtgbe https://github.com/davidtgbe https://github.com/davidtgbe https://github.com/davidtgbe https://github.com/davidtgbe https://github.com/davidtgbe if I recall correctly FSMC reconfiguration to 8 bit will not be sufficient - there are places in code that operate with pixels (2 bytes) and logic there expects 16 bit data transfers. > I would at least expect problem with bigendian and littelendian color format. > > Changed FSMC to 8 bits and, as you well said I'm having problems with colors. I suppose that half of pixel info is not transmitting... > So, I've also changed DMA transfers to 8 bits, and doubled counter as below: > > DMAtx.Init.PeriphDataAlignment = DMA_PDATAALIGN_BYTE; > DMAtx.Init.MemDataAlignment = DMA_MDATAALIGN_BYTE; ` > > DMAtx.Instance->NDTR = (Count2); DMAtx.Instance->PAR = (uint32_t)Data; DMAtx.Instance->M0AR = (uint32_t)&(LCD->RAM); > > But no luck... colors are still incorrect. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub <#18129 https://github.com/MarlinFirmware/Marlin/issues/18129 (comment) <#18129 (comment) https://github.com/MarlinFirmware/Marlin/issues/18129#issuecomment-653243278>>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHVGS4LJAHNRTW3YU4BBZHDRZUB5JANCNFSM4NL5RISQ https://github.com/notifications/unsubscribe-auth/AHVGS4LJAHNRTW3YU4BBZHDRZUB5JANCNFSM4NL5RISQ https://github.com/notifications/unsubscribe-auth/AHVGS4LJAHNRTW3YU4BBZHDRZUB5JANCNFSM4NL5RISQ https://github.com/notifications/unsubscribe-auth/AHVGS4LJAHNRTW3YU4BBZHDRZUB5JANCNFSM4NL5RISQ. > Correct J.C, IM pins are soldered to use 8080-I 8bit / 16bit pixel interface. My theory was that if I receive a buffer with the pixels to be printed, and they are printed OK using the FSMC/DMA 16bit wide: [half_word_pixel1] [half_word_pixel2] ... I could simply double DMA transactions splitting data on 8bit chunks and setting up a 8 bit FSMC/DMA. [1st_byte_pixel1] [2nd_byte_pixel1] [2nd_byte_pixel2] as in https: //www.newhavendisplay http://www.newhavendisplay/ .com / appnotes / datasheets / LCDs / ST7789V.pdf -> page 71. But, clearly I'm missing something because graphics structure are ok, but colors are not. May be I have to swap pixel bytes... — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#18129 (comment) https://github.com/MarlinFirmware/Marlin/issues/18129#issuecomment-653252208>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHVGS4LVNKP6VMRYHKZAAJTRZUGAXANCNFSM4NL5RISQ https://github.com/notifications/unsubscribe-auth/AHVGS4LVNKP6VMRYHKZAAJTRZUGAXANCNFSM4NL5RISQ.

Anet releasing their code is not an option I'm afraid... That's why I'm trying to adapt ET4 stock MB and TFT to Marlin [ET4 Marlin Project] (https://github.com/davidtgbe/Marlin https://github.com/davidtgbe/Marlin) (because of that, and because I like this kind of challenges :).

You can find the firmware here https://drive.google.com/drive/folders/1KglkG9_UpFS8_kTtJllMCzQQ9R2Fh4k8 And, just in case... Bootloader https://drive.google.com/drive/folders/1ldgTugSnqlpxja3Y5MAou7OHc3I7l-Mw — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/18129#issuecomment-653256206, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHVGS4IZDIQKB5X6364X3HLRZUID5ANCNFSM4NL5RISQ.

[xC0000005]

I dont’ have time to extract this, but what you can do is overwrite your ST7789v.h escape sequence. Any value that was passed to the register, use ESC_REG(value) on, anything that was written to ram, break down into bytes and just glob on.

If it works, you can look up the register names and see what’s different or build a specific init sequence (similar to what I had to do for Lerdge). I couldn’t find an easy way to dump this as text, sorry. (there’s two lines of overlap so you can be sure you entered the right data.

On Jul 2, 2020, at 4:28 PM, JC Nelson authorjcnelson@gmail.com wrote:

Ok, I found their init sequence. Looking into it.

On Jul 2, 2020, at 4:14 PM, davidtgbe <notifications@github.com mailto:notifications@github.com> wrote:

Hmm. There’s a lookup table even in 16 bit mode. If Anet released their code, you ould try swapping in their init sequence. If they didn’t, and you have their firmware, point me to it and I’ll extract the sequence to see if they’re setting some sort of color lookup/correction (Lerdge does this, and we have to use the same sequence or the colors are way off). … <x-msg://16/#> On Jul 2, 2020, at 3:56 PM, davidtgbe @.*> wrote: Never mind. I think those pins are soldered to configure, not an init sequence thing. When SPI flash is working as an image source, you could do a bit-depth conversion on all the images to be 8 bit, but it’s not going to be a simple init thing. Sorry. … x-msg://13/# <x-msg://13/#> On Jul 2, 2020, at 3:30 PM, JC Nelson @.> wrote: What did you set the IM mode to in your init sequence? > On Jul 2, 2020, at 3:21 PM, davidtgbe @. @.>> wrote: > > > @davidtgbe https://github.com/davidtgbe https://github.com/davidtgbe https://github.com/davidtgbe https://github.com/davidtgbe https://github.com/davidtgbe https://github.com/davidtgbe https://github.com/davidtgbe if I recall correctly FSMC reconfiguration to 8 bit will not be sufficient - there are places in code that operate with pixels (2 bytes) and logic there expects 16 bit data transfers. > I would at least expect problem with bigendian and littelendian color format. > > Changed FSMC to 8 bits and, as you well said I'm having problems with colors. I suppose that half of pixel info is not transmitting... > So, I've also changed DMA transfers to 8 bits, and doubled counter as below: > > DMAtx.Init.PeriphDataAlignment = DMA_PDATAALIGN_BYTE; > DMAtx.Init.MemDataAlignment = DMA_MDATAALIGN_BYTE; ` > > DMAtx.Instance->NDTR = (Count2); DMAtx.Instance->PAR = (uint32_t)Data; DMAtx.Instance->M0AR = (uint32_t)&(LCD->RAM); > > But no luck... colors are still incorrect. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub <#18129 https://github.com/MarlinFirmware/Marlin/issues/18129 (comment) <#18129 (comment) https://github.com/MarlinFirmware/Marlin/issues/18129#issuecomment-653243278>>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHVGS4LJAHNRTW3YU4BBZHDRZUB5JANCNFSM4NL5RISQ https://github.com/notifications/unsubscribe-auth/AHVGS4LJAHNRTW3YU4BBZHDRZUB5JANCNFSM4NL5RISQ https://github.com/notifications/unsubscribe-auth/AHVGS4LJAHNRTW3YU4BBZHDRZUB5JANCNFSM4NL5RISQ https://github.com/notifications/unsubscribe-auth/AHVGS4LJAHNRTW3YU4BBZHDRZUB5JANCNFSM4NL5RISQ. > Correct J.C, IM pins are soldered to use 8080-I 8bit / 16bit pixel interface. My theory was that if I receive a buffer with the pixels to be printed, and they are printed OK using the FSMC/DMA 16bit wide: [half_word_pixel1] [half_word_pixel2] ... I could simply double DMA transactions splitting data on 8bit chunks and setting up a 8 bit FSMC/DMA. [1st_byte_pixel1] [2nd_byte_pixel1] [2nd_byte_pixel2] as in https: //www.newhavendisplay http://www.newhavendisplay/ .com / appnotes / datasheets / LCDs / ST7789V.pdf -> page 71. But, clearly I'm missing something because graphics structure are ok, but colors are not. May be I have to swap pixel bytes... — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#18129 (comment) https://github.com/MarlinFirmware/Marlin/issues/18129#issuecomment-653252208>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHVGS4LVNKP6VMRYHKZAAJTRZUGAXANCNFSM4NL5RISQ https://github.com/notifications/unsubscribe-auth/AHVGS4LVNKP6VMRYHKZAAJTRZUGAXANCNFSM4NL5RISQ.

Anet releasing their code is not an option I'm afraid... That's why I'm trying to adapt ET4 stock MB and TFT to Marlin [ET4 Marlin Project] (https://github.com/davidtgbe/Marlin https://github.com/davidtgbe/Marlin) (because of that, and because I like this kind of challenges :).

You can find the firmware here https://drive.google.com/drive/folders/1KglkG9_UpFS8_kTtJllMCzQQ9R2Fh4k8 And, just in case... Bootloader https://drive.google.com/drive/folders/1ldgTugSnqlpxja3Y5MAou7OHc3I7l-Mw — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/18129#issuecomment-653256206, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHVGS4IZDIQKB5X6364X3HLRZUID5ANCNFSM4NL5RISQ.

[davidtgbe]

Ok, thank you very much. To be sure... You are suggesting what exactly; extract myself the Init seq from firmware (could guess, but, don't know how), using a logic analyzer to capture Init seq from stock firmware... Or may be you forgot to attach on your previous post some dump from stock firmware that I could use to overwrite my st7789v.h?

[xC0000005]

I attached the screenshots showing you the sequence but apparently they didn't go through. If you have an email address I'll send them to you.

[xC0000005]

Here, @davidtgbe. I don't know that this will fix your problem, but I do know that boards like dlion work the same way you've proposed - they transmit 16byte pixels by sending it 8 bits at a time.

[jmz52]

@davidtgbe I expect to get my FSMC display with configurable 16/8 bit interface next week. Then I'll be able to run some tests to see if there is an elegant solution for bytes order problem.

For now I can only suggest you to try simple bytes reordering. It will not help with16-bit image used on bootscreen, but rest on UI should be ok.

In file tft_queue.cpp add macro definition #define littleBIG(color) ((color >> 8) | (color << 8)) and change following lines:

In function void TFT_Queue::fill(uint16_t x, uint16_t y, uint16_t width, uint16_t height, uint16_t color) replace task_parameters->color = color; with task_parameters->color = littleBIG(color);

In functions void TFT_Queue::set_background(uint16_t color) void TFT_Queue::add_text(uint16_t x, uint16_t y, uint16_t color, uint8_t *string, uint16_t maxWidth) void TFT_Queue::add_bar(uint16_t x, uint16_t y, uint16_t width, uint16_t height, uint16_t color) void TFT_Queue::add_rectangle(uint16_t x, uint16_t y, uint16_t width, uint16_t height, uint16_t color) replace parameters->color = color; with parameters->color = littleBIG(color);

In function void TFT_Queue::add_image(int16_t x, int16_t y, MarlinImage image, uint16_t *colors) replace *color++ = *colors++; with *color++ = littleBIG(*colors++);

[davidtgbe]

I think It's working now, with true colors, using above Alexander's solution (swapping pixel byte order). What is really weird is that it is working with 8 bit FSMC/16 bit DMA. Images are not displaying correctly, as Alexander pointed. I suppose those images are hardcoded and displayed directly and thats why are shown so.

Glad to hear you are working on a 8 bit FSMC version. If you need someone for testing, here I am.

Thanks Alexander and J.C.!

[jmz52]

@davidtgbe These images use run-time generated palette. Did you change the colors assignment in void TFT_Queue::add_image(int16_t x, int16_t y, MarlinImage image, uint16_t *colors) function? *color++ = *colors++; should be replaced with with *color++ = littleBIG(*colors++);

[davidtgbe]

Yes. This is my tft_queue.cpp

tft_queue.cpp.txt

[jmz52]

@davidtgbe My mistake - with littleBIG macro substitution the *color++ is processed twice. You need to replace

  while (number_of_color--) {
    *color++ = littleBIG(*colors++);
  }

with

  uint16_t tmp;
  while (number_of_color--) {
    tmp = *colors++;
    *color++ = littleBIG(tmp);
  }

[davidtgbe]

Now works perfect :) Thanks Alexander, great work.

[davidtgbe]

Another byte swapping to fix images (bootscreen): In canvas.cpp, function void CANVAS::AddImage(int16_t x, int16_t y, MarlinImage image, uint16_t *colors)

  // HIGHCOLOR - 16 bits per pixel

  for (int16_t i = 0; i < image_height; i++) {
    int16_t line = y + i;
    if (line >= startLine && line < endLine) {
      uint16_t *pixel = buffer + x + (line - startLine) * width;
      for (int16_t j = 0; j < image_width; j++) {
        if ((x + j >= 0) && (x + j < width)) *pixel = littleBIG(*data);
        pixel++;
        data++;
      }
    }
    else
      data += image_width;
  }

[jmz52]

@davidtgbe Problem with this solution is that it needs to process each byte which it quite CPU consuming. Right now 16-bit image is only used for bootscreen, so it is not a big deal to have slow bootscreen display. This operation might be too expensive when 16-bit images will be used in regular UI.

It would be better to have images encoded for 8-bit interface when they are part of firmware or transcode them when uploading to SPI flash.

[xC0000005]

I agree with this - whatever prepares the images or uploads them should do color conversion. At run time, it’s a straight blit.

On Jul 13, 2020, at 11:29 AM, Alexander Gavrilenko notifications@github.com wrote:

@davidtgbe https://github.com/davidtgbe Problem with this solution is that it needs to process each byte which it quite CPU consuming. Right now 16-bit image is only used for bootscreen, so it is not a big deal to have slow bootscreen display. This operation might be too expensive when 16-bit images will be used in regular UI.

It would be better to have images encoded for 8-bit interface when they are part of firmware or transcode them when uploading to SPI flash.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/18129#issuecomment-657719972, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHVGS4NHM3F6OPMRBJUXC43R3NHATANCNFSM4NL5RISQ.

[jmz52]

I've got my hand on 480x320 screen with ST7796 controller and configured it to run in SPI mode. While not as fast as with 16-bits parallel interface it is not a terribly slow. I would say it is quite comfortable to use.

[looxonline]

I've got my hand on 480x320 screen with ST7796 controller and configured it to run in SPI mode. While not as fast as with 16-bits parallel interface it is not a terribly slow. I would say it is quite comfortable to use.

Did you use one SPI bus for the TFT and the touch?

[jmz52]

Shared hardware SPI for TFT and touch is supported but right now I am using hardware SPI for TFT and software SPI for touch. I need to resolder number of wires to connect touch to hardware SPI used by TFT.

[mattdog01]

Hello Folks, I have been trying to get a MKS TFT v1.1 touch screen working on the current Nighty Download but it seems that files and folders are missing that need to be added to get things working. (I'm very sorry, but I am still trying to learn how Marlin files work.) Is there a place where I can download a version of Marlin with all the files and folders inplace? I get recurring errors that I don't seem to be able to resolve.

I use this in PlatformIO.ini [platformio] src_dir = Marlin boards_dir = buildroot/share/PlatformIO/boards default_envs = mks_robin_stm32 include_dir = Marlin

I select mks_robin_stm32 and then build.

I get this error. Error: Invalid 'e:\Marlin Firmware\Marlin-bugfix-2.0.x\platformio.ini' (project configuration file): 'No option 'arduinoststm32_ver' in section: 'common'' The terminal process terminated with exit code: 1

If I try to use mks_robin in default_envs AND in the mks_robin then build it will compile but I loose touch screen function.

I have set the correct screen calibration in both Configuration.h and in xpt2046.h

define XPT2046_X_CALIBRATION -11792

define XPT2046_Y_CALIBRATION 8947

define XPT2046_X_OFFSET 342

define XPT2046_Y_OFFSET -19

I would like to be able to do this without needing help every time but I'm just not there yet it seams. Is there someplace that I can go to look for help or to read about this process of configuring Marlin to work on my machine. Marlin new releases never work unless I copy over folders or files from some of the work you have done here but today I am stumped and can't get my machine working again. I don't seem to be able to get help via the forums out there. I know this is not a forum to ask questions but I come here because you are all so knowledgeable about this stuff. Is there a better way or place to get help?

thanks, Matt