phofman

OK, I will do so when I finish prototyping my project in python and get back to rewriting modules for the MCU.

Thanks a lot, Joel. Would the GMOUSE_VFLG_CAL_EXTREMES flag go to #if GINPUT_MOUSE_MAX_CALIBRATION_ERROR on line https://git.ugfx.io/Tectu/uGFX/src/master/drivers/ginput/touch/ADS7843/gmouse_lld_ADS7843.c#L52 ? I can send a patch to the driver, if you want to accept it. The reason I asked is I could not find this parameter check in any of the existing drivers and that confused me. Ugfx (+chibios) works great and fast on my ILI9487 8-bit TFT + touch, all the demos. Thanks for the nice project.

Please, may I ask for your suggestion? I would like to avoid modifying stock ugfx. Thanks a lot in advance.

Hi, thanks a lot. I do not think that define is being used/queried anywhere within the ugfx source: pavel@x220 ~/workspace/ChibiOS_16.1.8/demos/STM32/MAPLEMINI-UGFX/ugfx $ rgrep GINPUT_MOUSE_MAX_CALIBRATION_ERROR * drivers/multiple/uGFXnetESP8266/ginput_lld_mouse_config.h: #define GINPUT_MOUSE_MAX_CALIBRATION_ERROR -1 drivers/multiple/uGFXnetESP8266/ginput_lld_mouse_config.h: #define GINPUT_MOUSE_MAX_CALIBRATION_ERROR 2 drivers/multiple/uGFXnet/ginput_lld_mouse_config.h: #define GINPUT_MOUSE_MAX_CALIBRATION_ERROR -1 drivers/multiple/uGFXnet/ginput_lld_mouse_config.h: #define GINPUT_MOUSE_MAX_CALIBRATION_ERROR 2 There is a post by Joel My driver is the very standard ADS7843. I do not see setting the GMOUSE_VFLG_CAL_EXTREMES flag anywhere in the source code either, only reading/checking: pavel@x220 ~/workspace/ChibiOS_16.1.8/demos/STM32/MAPLEMINI-UGFX/ugfx $ rgrep GMOUSE_VFLG_CAL_EXTREMES * drivers/ginput/touch/MCU/gmouse_lld_MCU.c: //GMOUSE_VFLG_DEFAULTFINGER|GMOUSE_VFLG_CAL_EXTREMES - Possible drivers/multiple/uGFXnetESP8266/gdisp_lld_uGFXnetESP8266.cpp: //GMOUSE_VFLG_CALIBRATE|GMOUSE_VFLG_CAL_EXTREMES|GMOUSE_VFLG_CAL_TEST|GMOUSE_VFLG_CAL_LOADFREE drivers/multiple/Win32/gdisp_lld_Win32.c: //GMOUSE_VFLG_CALIBRATE|GMOUSE_VFLG_CAL_EXTREMES|GMOUSE_VFLG_CAL_TEST|GMOUSE_VFLG_CAL_LOADFREE drivers/multiple/uGFXnet/gdisp_lld_uGFXnet.c: //GMOUSE_VFLG_CALIBRATE|GMOUSE_VFLG_CAL_EXTREMES|GMOUSE_VFLG_CAL_TEST|GMOUSE_VFLG_CAL_LOADFREE drivers/multiple/X/gdisp_lld_X.c: //GMOUSE_VFLG_CALIBRATE|GMOUSE_VFLG_CAL_EXTREMES|GMOUSE_VFLG_CAL_TEST|GMOUSE_VFLG_CAL_LOADFREE src/ginput/ginput_driver_mouse.h: #define GMOUSE_VFLG_CAL_EXTREMES 0x0020 // Use edge to edge calibration src/ginput/ginput_mouse.c: //if ((gmvmt(m)->d.flags & GMOUSE_VFLG_CAL_EXTREMES)) { I appreciate your help.

Hi, My cheap touch screen requires the extreme touch calibration for reasonable performance closer to the border. Please what is the recommended way to switch the initial calibration to the extreme version https://git.ugfx.io/Tectu/uGFX/src/master/src/ginput/ginput_mouse.c#L474 ? Please where is the recommended place to configure the GMOUSE_VFLG_CAL_EXTREMES flag to the GMouseVMT struct? I do not want to modify the library. May I ask for removing the old not valid configuration https://wiki.ugfx.io/index.php/Touchscreen_Calibration#Extreme_coordinates from the wiki? It is a bit confusing. Thanks a lot, Pavel.

Finally I managed to read the registers. The d3h reg reads 9487 which means ILI9487 - something between ILI9486 and ILI9488 with no datasheet available. According to discussion in https://forum.arduino.cc/index.php?topic=366304.msg3113020#msg3113020 the arduino ili9488 driver works just fine for this controller. I checked a few other registers, e.g. the complex Negative Gamma Control e1h and first 6 bytes are equal to default values of 9488 in the datasheet. Therefore I will modify the existing ugfx ILI9488 driver which also does not allow for 8bit mode (almost same as the existing ILI9481 driver).

I have tried for a few hours, not a single register read. I have to be doing something wrong since it should be readable https://forum.arduino.cc/index.php?topic=366304.msg2524865#msg2524865 . I will try to hook up my scope to see what it does, perhaps tomorrow

I will prepare the patch, after testing the register reading code. Please, will you rename the existing driver first, or should I include the rename in my patch set? Thanks.

ep.hobbyiest: The vendor has confirmed to me several times the display is actually using ILI9481. I asked him to fix the description, to no avail... He sent some code examples, presumably code for displaying the photos as shown on the product page. This time the driver file was called ILI9325.c, in directory called ILI9328 :-) But the init sequence in the file seemed to fit ILI9481 datasheet so he kind of convinced me it was ILI9481. Plus there is another seller with https://www.aliexpress.com/item/4-6-inch-HD-TFT-LCD-Touch-Screen-with-Adapter-Board-ILI9481-Drive-IC-480-272/32669045798.html which looks identical to me, for the same price. I want to implement reading registers to the driver and read the Device Code Read register 0xbh to see if it outputs correct ILI9481 device ID from the datasheet. Perhaps tonight...

inmarket, please how would you like the patch? I think the existing driver could be renamed to R61581 and I can send the working ILI9481 driver incl. support for 8bit transfer.

Yes, works great with the ili9481 init sequence :-)!

The combo works just fine :-) 480x272 screen fill takes about 110ms in 8bit mode with 72MHz STM32F103, enough for my purpose. Guys, thanks a lot. Now the real programming can begin...

Hi inmarket, I very much appreciate you help. This is what I found out. The code was kindly provided by Abhishek in commit https://git.ugfx.io/dongie/uGFX/commit/b2252bb7bede275461700db9c56b702a93a33982. Please note the ILI9481 or compatible. Abhishek describes his project on his blog https://theembeddedkitchen.net/author/abhishek/page/2 where he says R61581 datasheet http://www.allshore.com/pdf/Renesas_R61581.pdf shows exactly the codes found in the existing gdisp_lld_ILI9481.c - 8 parameters of register (ILI9481 has only six), first parameter of 0xc0 has options in bits 2:0, fitting the 0x03 value (unlike ILI9481 which has zeros there), register 0xc4 (not present in ILI9481). Clearly this is driver for R61581 which is slightly different to ILI9481. Honestly, this has helped a lot to me since now I know how to handle it. Thanks, Pavel.

I am working on init sequence - trying to reconcile the ugfx driver init sequence (very likely comes from a different device, some registers are not present in ILI9481, e.g. 0xc4) and the sequence supplied by the vendor. By the end of this week I hope to try running the LCD.

I am OK with the existing design of the drivers, the source code is self-explaining. I like the structure, no case statements for the individual TFT controllers as found in other less universal libraries. Since I have no prior experience with this LCD, I just needed to know how much I can "trust" the driver compared to other sources (esp. the widely-used UTFT). I will send a patch once I make it work (hopefully :-) ). Since my LCD resolution 480x272 is different to the default 480x320, I will try to incorporate this setup into the initialization sequence too. Thanks a lot for your help.