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.

Hi inmarket, thanks a lot for your reply. How about making clear distinction between the 8bit and 16bit write functions similar to that arduino library (write8, write16)? write_byte would accept 8bit argument (uint8_t) and write_word would accept the current uint16_t. It is up to the board_driver.h implementation if the write_word sends 16bits parallel, 2 x 8bits parallel (i.e. twice write_byte) or uses serial SPI. All register functions use the 8bit parameters, write_word/read_word would be used only in the 16bit (RGB565) hardware streaming (write_color, read_color). Please can you comment on the initialization parameters? I will test the parameters from the other libraries first as they seem "more correct" to me, based on the datasheet description.

I am working on integrating the inexpensive 4.63" LCD https://www.aliexpress.com/item/4-63-inch-16-9-272-480-TFT-screen-with-Resistance-touch-and-PCB-panel-LCM/32802272563.html with chibios on STM32F103, will report when finished.

Hi, I am working on integration of ILI9481-based LCD in 8bit with maple mini and chibios. IIUC, according to the driver datasheet http://www.ncsys.co.jp/webshop/GTV350MPZI04(ILI9481).pdf registers should be called in a sequence register ID + 1st parameter + 2nd parameter etc. Each parameter is only 8bit and takes only one transfer in both 16bit and 8bit modes. But the used write_data method used in the write_reg and write_reg2x16 methods https://git.ugfx.io/Tectu/uGFX/src/master/drivers/gdisp/ILI9481/gdisp_lld_ILI9481.c#L50 defined in my specific board_ili9481.h must make two transfers to transfer the 16bit parameter in 8bit mode. As a result the controller will send twice as many parameters which IMO is incorrect. I have not tested the code yet, perhaps it actually works. But I think the methods called after write_index should be something like write_byte, sending only single byte, allowing for the specific implementation in board_ili9481.h to distinguish between 16bit (write_data) and 8bit transfers (write_byte). I can modify the code and send a patch, just would like to know if it makes sense. Another question concerns the configuration parameters. According to the datasheet the C0h "Panel Driving Settings" param (page 103) is supposed to accept 6 parameters. However the ugfx driver sets 8 parameters https://git.ugfx.io/Tectu/uGFX/src/master/drivers/gdisp/ILI9481/gdisp_lld_ILI9481.c#L106 while the first 0x03 does not seem to fit the datasheet at all (zeros on position D1/D0), while other drivers usually specify 0x10 there https://github.com/MajenkoLibraries/DisplayCore/blob/master/Drivers/ILI9481/ILI9481.cpp#L232 or the UTFT library for ILI9481 specifies https://github.com/dgolda/UTFT/blob/master/tft_drivers/ili9481/initlcd.h#L18 This is my first project in STM32/ugfx/chibios and there are many unknown variables at stake. I would love to cut down on this one :-) Thank you very much for any suggestion or help. Best regards, Pavel.

Guys, thanks for your insight. I ordered the 480x272 https://www.aliexpress.com/item/4-63-inch-16-9-272-480-TFT-screen-with-Resistance-touch-and-PCB-panel-LCM/32802272563.html with presumably ILI9481 (already supported by uGFX) and 8bit interface. I will post some time measurements when I get to this part.

That linked 854x480 LCD has ILI9806 which is not added to uGFX yet but has a working driver for arduino environment. https://github.com/ZinggJM/GxTFT/blob/master/GxCTRL/GxCTRL_ILI9806/GxCTRL_ILI9806.cpp

inmarket, thanks for the hint. The result gets around 100-200ms in this case, which as you say should be ok. I will make a decision and go for one of the options.

Joel, I very much appreciate your help. Currently I am discussing the LCD details with the seller - it is not going easy, so far I have been given three different answers :-) I found a tested combination for reasonable price (https://www.aliexpress.com/item/5-0-inch-HD-IPS-TFT-LCD-module-resistance-touch-with-PCB-adapter-board-854-480/32666829945.html ,https://www.aliexpress.com/item/1pcs-STM32F103C8T6-ARM-STM32-Minimum-System-Development-Board-Module-For-arduino/32653883227.html ) with arduino driver available https://github.com/ZinggJM/GxTFT/blob/master/GxIO/GxIO_STM32F103C8T6_P16_TIKY/GxIO_STM32F103C8T6_P16_TIKY.h . But the LCD is high-resolution 854x470 which I am afraid will be too slow on ILI9806 without the rectangle fill acceleration (even though it runs over 16bit parallel) - somewhere I read about 300ms for screen fill which seems visually slow to me. Thanks a lot.

inmarket, thanks a lot for your important information. According to the LCD vendor (rather active chinese manufacturer/reseller ruija) the TFT is based on ILI9486. That chip is currently not supported by uGFX directly. The datasheet is freely available on internet http://www.displayfuture.com/Display/datasheet/controller/ILI9486L.pdf , would it be difficult to add to uGFX? Perhaps it is similar to the already supported ILI9488. I will ask about the interface support, IMO it is parallel 8bit (optimal for my case). Please what kind of interface is supported in the current ILI9488 driver? How can I configure assignment of the individual GPIOs? I very much appreciate your help.

Hello guys, thanks a lot for all your comments. This great community is why I would like to use the open source toolkit as opposed to the closed-source ones. To be specific - I am building a grown-up version of my player https://github.com/pavhofman/plabs-player/wiki where the display is dirt-cheap arduino mini + SPI TFT. This time I want to use touch screen with more complicated GUI (some radio buttons, perhaps virtual keyboard for text input). No video, maybe some small image icons, nothing moving. However vertical scrolling longer lists of tracks is needed. Display size around 5", resolution is not critical. Reasonably fast screen refresh (< 100ms?). Font aliasing would be nice. No production runs, single quantities. Since the project is specifically aimed at minimum cost (small $100s total), I am really looking at an economy solution. Please would parallel 8bit ILI9488 hooked to cheap non-FSMC STM32F103C (e.g. blue pill) cut the corner? Specifically I am looking at inexpensive but sufficiently large 4.6" touch screen https://www.aliexpress.com/store/product/4-63-inch-16-9-272-480-TFT-screen-with-Resistance-touch-and-PCB-panel-LCM/1726252_32802272563.html. Please what is the current status of hardware acceleration support for the ILI9488 or other controllers in uGFX? Actually I did not find any rectangle-fill function in its datasheet. Or do you think even for such simple task it is worth going for the more expensive SSD-based TFT with HW acceleration? Still I cannot find any HW-accel code for SSD1963 in https://git.ugfx.io/uGFX/uGFX/src/master/drivers/gdisp/SSD1963/gdisp_lld_SSD1963.c, do I have to complete it first? Please what is more convenient - HW acceleration controller (actually supported by the existing driver) with plain 8bit or even SPI interface or no acceleration (likely the current status?) with fast but more expensive ($10 more) FSMC interface? Please do not take the questions about HW acceleration support as a complaint, I am just trying to learn current situation and find a reasonable solution (even if it involved me having to add the missing code to uGFX based on some other supported controller (I am a newbie in coding TFT drivers :-) ). Thanks a lot for your insight.

It think this post is important https://community.ugfx.io/topic/552-need-help-with-il9341-and-ugfx/?do=findComment&comment=3925 - perhaps I should get a FSMC-capable STM32 board and use TFT with the SSD1963 controller.