MKSTFT_Marlin_Touch
MKSTFT_Marlin_Touch copied to clipboard
darkspr1te
MKS TFT32_L V3.0 on the STM32F107VCT6 chip
I Dont have a V3 board but porting to it is not hard, if i have a fw binary for me even easier.
Now in the testing stage, and improvements. It will be ready soon. I didn't make a separate environment in Platformio.ini. Added the controller selection to the defined section (MKS_32_V1_4) in variants.h.
Interesting observation. With the use of the stock bootloader from MKS, LCD initialization in firmware can be disabled. The screen is initialized by bootloader when the screen is turned on.
Interesting observation. With the use of the stock bootloader from MKS, LCD initialization in firmware can be disabled. The screen is initialized by bootloader when the screen is turned on.
do you have the adress of that code? in the bootloader & and fw, would like to see what triggers
I do not have the code address, the observation is based on the fact that the firmware works with the LCD initialization disabled. That logically follows from the fact that bootloader uses output to the screen.
check if it does after power up, not just reset, i've reversed engineered the bootloader to find the initialization as it was different to all the others i found (it's hx8558 , confirmed via registry checks ) but didnt find it in the code in the mks official file. How ever we have init in both bootloader and in marlin touch so it covers all really. no harm in 'init'ing the screen again apart from code space, which is not yet a concern.
I was too optimistic when I spoke about the imminent availability of firmware for MKS TFT V3. There were problems with inverting the touchscreen on the x-axis And initializing the screen. Initialization codes from ILI9325 partially fit.
For proper operation of the touchscreen in the menu did so: TS_Get_Coordinates x = LCD_WIDTH-(Atp_x+B*tp_y+C)/K;
Currently not working, initializing the screen in firmware and rotate screen and calibrating the touchscreen. The interface is displayed correctly and responds correctly to touch.
The work is complicated by the fact that I do not have a personal v3 screen, testing is performed remotely by the screen owner.
In LCD_init.c , LCD_REG(0x36) on line 242 is the rotation registry, followed by data of 0x64 , see https://www.crystalfontz.com/controllers/Himax/HX8353-E/ for pdf and , section 5.2 for address counter, this changes the screens rotation , note thats for the H8558/mks 32v1.4 but the values are similar for other screens(eg reg 0x36 then data of X ), this register is also called MADCTL , if the bootloader does the init then you can read this value back to get the correct value, i patched read_lcd so it should work. another method is to do a bare bones file that reads the registers back and sends them to uart,
Also line 441 in void refresh_direction the setting from variant.h (#define HX8558) comes into play here as this "redo's" the rotation , so again we see reg(0x36) poked with a value. refresh_rotation is last init of this so when comes to rotation this is the value used last.
This is how it's done in UTFT module i patched as another example , LCD_Write_COM(0x36); if (orient==1) {LCD_Write_DATA(0x64);//rotate 180deg } else { LCD_Write_DATA(0xa4);//orientation } note that bit 6 goes 0 and bit 7 goes 1, this causes rotation, changing the others Flip the screen in other axis, so if you flip two bits you can end up with rotated then inverted screen. then it gets confusing.
Read back registers that I need for initialization that are already configured correctly is a very good idea. Thanks! On the controller in MKS TFT V3, the R01 R03 and R60 registers are used for this purpose instead of 0x36. The graphics output is also different
TS_Get_Coordinates LCD_WR_REG(0x50); LCD_WR_DATA(sx); LCD_WR_REG(0x52); LCD_WR_DATA(sy); LCD_WR_REG(0x51); LCD_WR_DATA(ex); LCD_WR_REG(0x53); LCD_WR_DATA(ey);
LCD_WR_REG(0x20);
LCD_WR_DATA(sx); LCD_WR_REG(0x21); LCD_WR_DATA(sy); LCD_WR_REG(0x22);
LCD_SetWindow(0, 0, LCD_WIDTH-1, LCD_HEIGHT-1); LCD_WR_REG(0x22); LCD_WR_DATA(color);
It is very similar to ILI9325 in registers, although initialization does not work from IT.
Now the picture is displayed normally. But the coordinates of the touch and screen do not match on the x axis. I fixed this for working with the menu, but not in touchscreen calibration. To tap a point on the right, I have to tap on the left, where the point would be if the screen was mirrored.
Ah, got it, the calibration code is ment to correct for x inversion ,not x/y swap though which is what it's maybe seeing, i would swap the refresh_direction values (the data sent to the lcd) and then LCD_WIDTH/LCD_HEIGHT values and then rotate the screen(or not) and confirm it's calibration,
i had same issue and thats what it turned out to be, the code supports 0 or 90" rotation, but i had it rotated 180 degree which flips X/Y when you try and fix it in the wrong place, for example fix it in the init code but not in setwindow which updates infoSettings.rotate_ui and other settings stored on system, is the user running with original boot loader ? is you putting reset.txt on flash to reinit the calibration from 0.
I could have code i've not pushed to git that "debugs the board" , it spits out xpt2056 data, lcd data to uart, dumps bootloader etc, we could whip something up to output raw data. do we have any pic's of the board ( i downloaded a bunch off net i'am adding to marlin touch folder for this purpose.
On a side note do you not want to push this direct to master (BTT source) , either my one on my repo and I can push them onto master or pull direct from BTT, https://github.com/bigtreetech/BIGTREETECH-TouchScreenFirmware
So to clarify we have :- LCD_W/H in variant.h infoSettings.rotate_ui ++ (we have default (reset.txt), stored(eeprom) and updated(lcd init sequence,menu ui change, calibration) changing this) and values sent back from touch chip, lcd init MADCTL values as well. cannot think of any part that would have further control on how the system interprets theses values
X0 = 0 and not X0= 0xff which is inverted value you're seeing (screen to touch rotated 180)
darkspr1te
Oh and another gotcha I had was 16 bit or 8 bit * 2 which caused me to bug hunt the touch/rotation side as i was displaying a image but with wrong colours, this lcd was 8 bit (gpio port E bit 0-15) so i needed to shift high 16-32 bits in first , it will be same on read out too. dont think this is your issue but worth mentioning for others doing ports. this is found in the lcd_init.h file(defined in variant.h thought but affected here).
One final thought, see https://github.com/darkspr1te/vscode_arduino_mkstft_flappyduino/tree/master/lib/UTFT/tft_drivers for a few init routines, you might find yours in there.
I will write here, for the darkspr1te/BIGTREETECH-TouchScreenFirmware branch. Since there is no MKS folder in the-Copy to SD Card root directory to update - Unified Menu Material theme directory. Images have to be taken from the tft28 folder, the logo.bmp file in it is a different size and is and appears distorted on the screen when loading when trying to stretch a small image to the full screen.
In the Printing menu, the file name in the information line is corrupted -show_GlobalInfo draws over it. Fix-Parametersettings.c ->void show_GlobalInfo(void)-> line 331 if (infoMenu.menu [infoMenu.cur] == menuMove | / infoMenu.menu [infoMenu.cur] == menuStatus | / infoMenu.menu [infoMenu.cur] == menuPrinting) return;
Test version with V1 V3 support, as the code does not have full TFT initialization. However, it works when using the MKS stock bootloader.
PS Read registers from TFT failed, LCD_ReadID instead of the register value returns the number of the register that I am reading.
Does anyone have a copy of V1/V3 bootloader? i can reverse the init sequence.
I am sure that the initialization of ILI9325 should be suitable. Unfortunately, I have no experience with TFT controllers. And I'm probably making the wrong settings. The registers are correct, but their values are incorrect. This is what I get with initialization from ILI9325. The reason for the image inversion is probably in the r61h register.
Here I am only interested in image distortion in the form of an interlaced image, while the image is not stable and flickers. I fixed the rotation of image elements.
Its work, for MKS TFT32 V1, V2, V3, V4 thiw 12864 emulation mode. https://github.com/Uz45/BIGTREETECH-TouchScreenFirmware/tree/BTT_256_MKSTFT32_V1_V2_V3_V4
What about MKS-TFT35 v1.0?
MKS TFT 32,28,24 uses stm32 F2xx F1xx processors and MKS TFT35 V1.0-STM32 F407 for it, you need to add a new core to the project. It is very expensive in terms of time, requires appropriate knowledge and the presence of a device for experiments. I think until BTT releases the device on F4 it is unlikely that they will port the firmware to TFT35.
What about MKS-TFT35 v1.0?
MKS TFT 32,28,24 uses stm32 F2xx F1xx processors and MKS TFT35 V1.0-STM32 F407 for it, you need to add a new core to the project. It is very expensive in terms of time, requires appropriate knowledge and the presence of a device for experiments. I think until BTT releases the device on F4 it is unlikely that they will port the firmware to TFT35.
MKSTFT35 V1 bootloader underway, will work port shortly after completion of bootloader. we have a willing subject with a f407vet and stlink . I cant give a timeline however but it is being worked on.
Good News Everyone, We have a almost working bootloader for MKSTFT35 V1 boards, the same code used to "enable the parts of the cpu" is the same code i need to add to BTT builds and Marline touch to enable those users to have a choice. I am tho asking if we could crowd source a real unit for me to keep up progress, once am done doing the bootloader and main port of Marlin touch my access to the device will be limited as my test user will be using the device, having one myself will ease that issue. Send me direct message if you wish to assist. Well, onto unknown code and Beyond !!
Even more good news, another user has posted the mkstft35 V1 bootloader, we have confirmed it works and can be flashed via serial https://github.com/makerbase-mks/MKS-TFT/issues/382#issuecomment-621665829
That's a good news, if you need help , I have also a MKSTFT35 V1, a flasher and PC running h24!
we have a discord running where we are actively working on the code right now, if you wish to help by testing our compiled bin files I can send you a discord invite by DM.
Ok, I am ready to test after 05.05.2020
On Thursday, April 30, 2020, 06:44:09 PM GMT+3, darkspr1te <[email protected]> wrote:
we have a discord running where we are actively working on the code right now, if you wish to help by testing our compiled bin files I can send you a discord invite by DM.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
Hi, I am trying to flash the bigtreetech fws on a MKS TFT32_L V3.0 and a MKS TFT35 V1.0 but it does not work, I have an inverted image on the TFT32 and no operation on the TFT35. I use the FWs on the official github, from 3 days ago. I tried to compile the fw of the TFT32, trying to play on the init of the lcd, without effect yet and I came across your post. have you made progress on your side?
Hi, I am trying to flash the bigtreetech fws on a MKS TFT32_L V3.0 and a MKS TFT35 V1.0 but it does not work, I have an inverted image on the TFT32 and no operation on the TFT35. I use the FWs on the official github, from 3 days ago. I tried to compile the fw of the TFT32, trying to play on the init of the lcd, without effect yet and I came across your post. have you made progress on your side?
Try it from this branch https://github.com/Uz45/BIGTREETECH-TouchScreenFirmware/tree/master_2020_12 This is an earlier version. Screen rotation in it works correctly. This applies to MKS TFT V3.0