Hello, I've tried most of the combinations (I can't say I've tried them all) but none of them will work with the MKS-TFT35 3D printer control board. I use that board as a development system. Otherwise, the MKS-TFT35 has an STM32F407VET6 processor and an ILI9488 graphics controller. Has anyone managed to run GxTFT on that board ?
Hi @freetoair, welcome to the Displays section of the forum!
There is still a chance someone could give you an assertive answer.
But I have no idea how widely GxTFT is used. Therefore I can't answer this question.
It would be helpful if you provide links to the device in question. But Auntie Google helps, as I learnt from @david_prentice in my early days with Arduino and TFT displays.
https://www.google.com/search?q=MKS-TFT3
https://www.google.com/search?q=mks+tft35+datasheet
https://github.com/makerbase-mks/Datasheet/blob/master/English%20datasheet/MKS%20TFT%203.5%20V1.0DataSheet.pdf
https://www.aliexpress.com/item/32891320510.html
https://www.aliexpress.com/item/4000829014909.html?gatewayAdapt=glo2deu
https://github.com/makerbase-mks/MKS-TFT35-Firmware
https://github.com/makerbase-mks/MKS-TFT35-Firmware/blob/master/Drivers/STM32F4xx_MKS_Driver/Inc/mks_lcd.h
https://github.com/makerbase-mks/MKS-TFT35-Firmware/blob/master/Drivers/STM32F4xx_MKS_Driver/Src/mks_lcd.c
A quick look at the two source files reveals that FSMC is used by the firmware.
This means that the data lines are connected as given by the FSMC mapping.
The control lines CS and RS/DC could be found out looking at lcd.c, or from the schematics.
https://github.com/makerbase-mks/MKS-TFT-Hardware/tree/master/MKS%20TFT35/MKS%20TFT35%20V1.0_003
RS : PD12
CS : PD7
Most likely the selection of CS and RS differs from the FSMC drivers in GxTFT and would need an adapted driver class for GxTFT. I don't know if you can do this, but I leave further research to you.
Jean-Marc
GxIO_STM32F407VxT6_FSMC.cpp: RS is different:
// connector pins
// 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34
// CS RS WR RD RST D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 D10 D11 D12 D13 D14 D15 NC LIG 3.3 3.3 GND GND NC MISO MOSI TINT NC TCS SCK
// D7 D11 D5 D4 RST D14 D15 D0 D1 E7 E8 E9 E10 E11 E12 E13 E14 E15 D8 D9 D10 GND B15 3.3 3.3 GND GND 5V B2 C4 B1 NC C13 B0
HI, @ZinggJM thanks for your quick reply and effort to help me with GxTFT implementation on MKS-TFT. Namely, MKS-TFT35 is not something revolutionary in terms of hardware, everything is simply connected on one board and it looks the most like STM32F4Dicsovery + STM32F4DIS-BB + STM32F4DIS-LCD (obsolete). Fortunately the Makerbase guys decided to make the firmware and schematics open source, but the firmware has some parts that were probably left over during the writing of the program and are confusing when following the program execution flow. I've noticed that the LCD drivers initially check which LCD controller is on the particular board. I practically still don't know for sure which controller is on my board. So my question is does GxTFT have a feature that does this?
freetoair, regards.
Hi @freetoair, yes, GxTFT and its example GxTFT_graphicstest.ino reads from the controller and reports the ID on hardware that supports reading. This is the case for your board.
But it is the "hen and egg" kind of problem with your board. Reading is only possible with a driver that can "talk" to your hardware. You would need to adapt either the FSMC or the P16 driver for the "FSMC kind" of pin-mapping of this board.
Usually, I do this only for boards that I have and can test with. I suggest you try yourself, but if you need help, I could make a driver class for you to test with.
I consider ordering this board, but first my pending deliveries and pending orders need to have arrived.
Yes, that is logical. Nothing then I'll try to make a connection with the LCD controller and we'll see what happens next. I tried to follow the program in the debugger from the STM32Cube but so far I haven't followed the initialization flow carefully. Maybe there I will get information about which controller is on my board. Thanks for your support and greetings. And of course if there is any progress I will post it here, maybe someone else will get the idea to use this board as a development system.
freetoair, regards.
After several hours of trying, there is very little progress. I only managed to get the screen to turn on and off, but nothing else happens. These are the changes I made to the GxIO_STM32F407VxT6_FSMC.cpp file:
#define PD_DATA_BITS 0b1100011100000011
#define PD_CTRL_BITS 0b0001000010110000 // freetoair change !?!
#define PD_FSMC_BITS 0b1100111110110011
#define PD_AFR0_MASK 0xF0FF00FF
#define PD_AFR0_FSMC 0xC0CC00CC
#define PD_AFR1_MASK 0xFF00FFFF
#define PD_AFR1_FSMC 0xCC00CCCC
and :
GxIO_STM32F407VxT6_FSMC::GxIO_STM32F407VxT6_FSMC(bool bl_active_high)
{
_cs = PD7; // FSMC_NE1
_rs = PD12; // FSMC_A16 // freetoair change !?!
_rst = 0; // not available, driven from NRST
_wr = PD5; // FSMC_NWE
_rd = PD4; // FSMC_NOE
_bl = PA1;
_bl_active_high = bl_active_high;
}
this is done according to the schematic diagram of MKS_TFT. Does this make sense? For the other #defines, I wasn't sure what they meant, so I didn't even change them!
freetoair, regards.
But these need also be set accordingly!
Maybe this:
// TFT connector uses FSMC pins
// D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 D10 D11 D12 D13 D14 D15
// PD14 PD15 PD0 PD1 PE7 PE8 PE9 PE10 PE11 PE12 PE13 PE14 PE15 PD8 PD9 PD10
// connector pins
// 09 10 11 12 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37
// CS RS WR RD RST GND D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 D10 D11 D12 D13 D14 D15 LEDA LEDK1 LEDK2 LEDK3 GND3
// D7 D12 D5 D4 RST GND D14 D15 D0 D1 E7 E8 E9 E10 E11 E12 E13 E14 E15 D8 D9 D10 3.3 R R R GND
// D used : 15,14,..,12,..,10, 9, 8, 7,.., 5, 4,..,.., 1, 0, // 11
// D data : 15,14,..,..,..,10, 9, 8,..,..,..,..,..,.., 1, 0, // 7
// | | | | |
// E used : 15,14,13,12,11,10, 9, 8, 7,..,..,..,..,..,..,.., // 9
// E data : 15,14,13,12,11,10, 9, 8, 7,..,..,..,..,..,..,.., // 9
// | | | // Ruler on 8 & 16
#define PD_DATA_BITS 0b1100011100000011
#define PD_CTRL_BITS 0b0001000010110000 //
#define PD_FSMC_BITS 0b1101011110110011
#define PD_AFR0_MASK 0xF0FF00FF
#define PD_AFR0_FSMC 0xC0CC00CC
#define PD_AFR1_MASK 0xFF0F0FFF
#define PD_AFR1_FSMC 0xCC0C0CCC
// | | |
// PD_MODE_MASK 0q3303033330330033 // quaternary notation, 2bit per digit
// PD_MODE_FSMC 0q2202022220220022 //
// PD_OSPD_FSMC 0q1101011110110011 //
#define PD_MODE_MASK 0xF33FCF0F // all FMSC MODE bits
#define PD_MODE_FSMC 0xA22A8A0A // FMSC MODE values 10 alternate function
#define PD_OSPD_FSMC 0x51154505 // FMSC OSPEED values 01 10MHz
// | | |
#define PE_DATA_BITS 0b1111111110000000
#define PE_AFR0_MASK 0xF0000000
#define PE_AFR0_FSMC 0xC0000000
#define PE_AFR1_MASK 0xFFFFFFFF
#define PE_AFR1_FSMC 0xCCCCCCCC
// | | |
#define PE_MODE_MASK 0xFFFFC000 // all FMSC MODE bits
#define PE_MODE_FSMC 0xAAAA8000 // FMSC MODE values 10 alternate function
#define PE_OSPD_FSMC 0x55554000 // FMSC OSPEED values 01 10MHz
Added: Oops, address needs be changed as well:
#define CommandAccess FMC_REGION
#define DataAccess (FMC_REGION + 0x40000) // FSMC_A17
Unfortunately, even after these corrections, there is no progress. The screen just turns on and off in the same rhythm, and on the serial port it shows how it is doing tests. And that is all. I think I'll hold off on activating this display in the Arduino environment for now. Anyway thanks for your help and regards.
freetoair.
I'm back to MKS_TFT again. After so many unsuccessful attempts, the last thing is to check the real state of the schematic and board. And of course, a surprise (as usual with Chinese products). Namely, the FSMC BUS is connected as in the diagram, except for the RD line, which is simply not connected. Clearly, that line is not necessary for operation unless something is decided in the program based on data read from the LCD controller. So my question is, can this library drive the LCD controller without reading anything from it?
freetoair.
Yes.
GxTFT only reads from the display for diagnostic purposes, when commanded by the example or application to do so.
But without the feedback from reading, it may be very difficult to diagnose!
You could have posted diagnostic output, but without read capability it will be useless.
Solved!
When selecting the command register or the data register, if the line A17 (RS) is used, then it is:
#define CommandAccess FSMC_BANK1
//#define DataAccess (FSMC_BANK1 + 0x80000)
#define DataAccess (FSMC_BANK1 + 0x40000) // shift one place right !
And that is all ! Now it works great, even the speed tests are very good.
regards, freetoair.
Isn't this what I added?
I probably didn't pay attention to that part of the post !
In any case, thanks for your help and regards !
freetoair.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.