nquantum Posted January 24, 2017 Report Share Posted January 24, 2017 Or maybe I need check my systick equal 1ms or not? Something to do with systick? I never check it yet. I only check DSI clock, LTDC clock Link to comment Share on other sites More sharing options...
nquantum Posted January 25, 2017 Report Share Posted January 25, 2017 By the way can I ask stupid question? Since resolution of TFT is 800x480 (widthxheight) So if drawing I can do is from 0,0 to width-1,height-1 am I right? Meaning 0,0 to 799,479 If 0,0 to 800,480 then resolution will be 801x481pixels... If correct I think I can make it already. Link to comment Share on other sites More sharing options...
inmarket Posted January 25, 2017 Report Share Posted January 25, 2017 You are right. A 800x480 display will have coordinates from 0,0 to 799,479. Link to comment Share on other sites More sharing options...
nquantum Posted January 26, 2017 Report Share Posted January 26, 2017 (edited) I can make it work like in picture. Thank to Maytham that I edited from him. And Joel Bodenmann , inmarket for suggestion. I add: undef Red, undef Green, undef Blue in board file , add DSI_HandleTypeDef hdsi_eval , declare uint32_t lcd_x_size and uint32_t lcd_y_size , clock LTDC in board file RCC->PLLSAICFGR = (STM32_PLLSAIN_VALUE << 6) | (STM32_PLLSAIR_VALUE << 28) | (STM32_PLLSAIQ_VALUE << 24); RCC->DCKCFGR = (RCC->DCKCFGR & ~RCC_DCKCFGR_PLLSAIDIVR) | STM32_PLLSAIR_POST; RCC->CR |= RCC_CR_PLLSAION; and DSI_PHY_TimerTypeDef PhyTimings; /* Configure DSI PHY HS2LP and LP2HS timings */ PhyTimings.ClockLaneHS2LPTime = 35; PhyTimings.ClockLaneLP2HSTime = 35; PhyTimings.DataLaneHS2LPTime = 35; PhyTimings.DataLaneLP2HSTime = 35; PhyTimings.DataLaneMaxReadTime = 0; PhyTimings.StopWaitTime = 10; HAL_DSI_ConfigPhyTimer(&hdsi_eval, &PhyTimings); and strange thing is LcdClock = 30000 instead 27429 then it work!? No offset anymore. I think it something to do with sync-timing number or the calculating-code thing inside. If I use exact number 27429 as I set LCD clock to that , it will offset display. Once I give value more to 3000 issue seem to disappear. I track down the code in debug. This LcdClock is relate to calculate timing of parameter in LTDC so I think it cause it. this is main gdispDrawLine(0, 0, width-1, 0, White); //show up gdispDrawLine(0, height-1, width-1, height-1, White); //show down gdispDrawLine(0, 0, 0, height-1, White); //show left gdispDrawLine(width-1, 0, width-1, height-1, White); //show right If you guy have time try to test my files. And please comment. Now I going to try and play with touchscreen. (PS. I work with Eclipse and GNU ARM wit baremetal what tools you guy use to work in ARM? Text editor and Makefile? ) board_STM32LTDC.h gdisp_lld_STM32LTDC.c Edited January 26, 2017 by nquantum Link to comment Share on other sites More sharing options...
Joel Bodenmann Posted January 26, 2017 Report Share Posted January 26, 2017 Great work at getting this working, @nquantum!!! We will definitely have a look at your work soon and report back to you. Unfortunately I don't think that that will happen before next week. In the meantime: Don't hesitate to ask if you have any other questions. We are really happy to help wherever we can. In this case we just don't have any knowledge or experience on that DSI/MIPI interface so we weren't of much help so far Link to comment Share on other sites More sharing options...
nquantum Posted January 28, 2017 Report Share Posted January 28, 2017 (edited) Welcome. Joel. Just let me know. So that I can improve. Now I going to make touch panel to work in this board. By start with board file and c file of Maytham. I got hardfault error in 2 of demo-program but 1 test-driver is working. I will track down to it. Reading from wiki page tell me that calibration will show each time power-on or initial ugfx right? For demo-programs I try there is no calibration appear. Can I call function from runtime? Or do I need to implement the function myself? (Meaning is there a calibration function already exist ready to call?) Edited January 28, 2017 by nquantum Link to comment Share on other sites More sharing options...
Joel Bodenmann Posted January 28, 2017 Report Share Posted January 28, 2017 Some touchscreen controllers (usually all that support capacitive touchscreens) support self-calibration. If the µGFX driver supports that then there's usually a configuration option in the corresponding board file. If self-calibration is enabled, the calibration screen won't show up. Other than that there's the interface that allows storing and loading calibration data which also allows bypassing the manual calibration screen. But there is no need to handle that if you're writing a touch driver - everything is done inside of the GINPUT module and as long as the user hasn't enabled that interface/feature in the configuration file nothing happens anyway. A tipp: /demos/tools/touch_driver_test is a good program to use in order to test whether your driver performs well. Link to comment Share on other sites More sharing options...
nquantum Posted January 29, 2017 Report Share Posted January 29, 2017 Problem with hardfault. Still don't know why? I use RAW32. I try with: /demos/tools/touch_calibration_brabber /demo/tools/touch_driver_test /demo/tools/touch_raw_readings All can compile without error. The touch_calibration_brabber and touch_raw_readings got HardFault exception at same line : m = (GMouse *)gdriverGetInstance(GDRIVER_TYPE_MOUSE, 0); For touch_driver_test can run without HardFault on that problem line with previous 2. But when I try to delete the rest of program start from this line to the end, in another word retain code only beginning until this line just for test/isolate problem. Then I get HardFault! Just same file only I delete the rest then HardFault come!? How can this be? Where the problem come from? I try to step into those line , it seem before hardfault , compiler can't see the value of type. So after this line: if (pd->vmt->type == type) { it jump to hardfault. But touch_driver_test when it run compiler seem to see value of type like the picture below. But I don't know when I just delete the rest of program can try compile then the 3 picture , no longer can see value of type. The driver seem to work even not yet full range since I get reading value show in touch_driver_test. Only problem is about the hardfault. What cause of this? How to solve? Link to comment Share on other sites More sharing options...
inmarket Posted January 29, 2017 Report Share Posted January 29, 2017 Run the threading demo program just to make sure that threading is working correctly. You may need to change the printf's in that demo to something that works on your debug platform or even just replace it with a led flash. Link to comment Share on other sites More sharing options...
nquantum Posted January 30, 2017 Report Share Posted January 30, 2017 (edited) I run demos\modules\gos\threads : If both threads then it hardfault (I place trace_printf in location of hardfault call routine) SEGGER J-Link GDB Server V6.12f - Terminal output channel thread 1 thread 2 thread main HardFault! If none thread then no problem SEGGER J-Link GDB Server V6.12f - Terminal output channel thread main thread main thread main thread main thread main If either 1 thread then also no problem SEGGER J-Link GDB Server V6.12f - Terminal output channel thread 1 thread main thread 1 thread 1 thread main thread 1 SEGGER J-Link GDB Server V6.12f - Terminal output channel thread 2 thread main thread 2 thread main thread 2 thread 2 thread main So that meaning of this? Thread don't work properly? Cause of this is? RAW32 have problem? Systick setting have problem? I guess that is relate to demo/tools/touch_raw_reading right? But how come demo/tools/touch_driver_test ? Edited January 30, 2017 by nquantum Link to comment Share on other sites More sharing options...
Joel Bodenmann Posted January 30, 2017 Report Share Posted January 30, 2017 As long as the threading demo (/demos/modules/GOS/threads) is not working properly there is no need to continue looking any further. The GINPUT module uses a GTIMER which uses threads and that's why you're hitting a problem. Can you please tell us exactly what compiler and what version of µGFX you're using? The RAW32 thread handling stuff got improved a few weeks ago. Make sure that you're on the latest stable release and/or the latest master branch of the development repository (just to give it a try). There have been quite a few reports of issues with RAW32 lately. Unfortunately, we couldn't find a pattern yet (eg. whether it's a specific platform, a specific compiler, or a specific combination of the two). Using the forum search you'll find things like this: So please do the things suggested in this forum post and let us know about the results. Link to comment Share on other sites More sharing options...
inmarket Posted January 30, 2017 Report Share Posted January 30, 2017 If you are using GCC or the Keil/ARMCC compiler try setting one of the GFX_CPU options (the appropriate one of course). Link to comment Share on other sites More sharing options...
Joel Bodenmann Posted January 30, 2017 Report Share Posted January 30, 2017 48 minutes ago, inmarket said: If you are using GCC or the Keil/ARMCC compiler try setting one of the GFX_CPU options (the appropriate one of course). Keep in mind that GFX_OS_USE_KEIL is not necessarily the correct setting when using Keil µVision. That setting is used when using the Keil RTX (CMSIS compatible) RTOS. It's possible to use any underlying system such as FreeRTOS or even just running baremetal in a Keil µVision project. The GFX_COMPILER and GFX_CPU macros are the ones you want to worry about in this case. Link to comment Share on other sites More sharing options...
nquantum Posted January 30, 2017 Report Share Posted January 30, 2017 Thank for quick respond! I use GNU ARM Embedded Toolchain 5-2016-q3-update , or 5.4.1 20160919 to be exactly. With Eclipse. For uGFX I use master branch download zip file from https://git.ugfx.io/uGFX/uGFX even I just try download while ago. Still same result I told you Hardfault on two thread (no thread or 1 thread there is no hardfault) Quote If you are using GCC or the Keil/ARMCC compiler try setting one of the GFX_CPU options (the appropriate one of course). Quote 9 hours ago, inmarket said: If you are using GCC or the Keil/ARMCC compiler try setting one of the GFX_CPU options (the appropriate one of course). Keep in mind that GFX_OS_USE_KEIL is not necessarily the correct setting when using Keil µVision. That setting is used when using the Keil RTX (CMSIS compatible) RTOS. It's possible to use any underlying system such as FreeRTOS or even just running baremetal in a Keil µVision project. The GFX_COMPILER and GFX_CPU macros are the ones you want to worry about in this case. For this I will try and also search into forum also. And I will let you know. To be clear. This issue is coming from threading thing in RAW32 right? Meaning if I try switch Chibi os or freeRtos then it might no problem about this? I'm new to both RTOS so sooner or later I will try that. Maybe I start with freeRTOS 1st since there is more document and last time I try ChibiStudio I got a lot of error to fix and hunt. For now I try to stick and solve RAW32 1st. Link to comment Share on other sites More sharing options...
nquantum Posted January 30, 2017 Report Share Posted January 30, 2017 I've read the book about stm32/freertos don't know something to do with RAW32 or not. Since I also use stm32 and also systick Link to comment Share on other sites More sharing options...
inmarket Posted January 30, 2017 Report Share Posted January 30, 2017 You will need to download the master repository version of uGFX. I don't know how current the zip download is. If you are on windows the program sourcetree is a very good free visual git tool. There should be no need to change the operating system as your compiler is a version of GCC and is therefore well supported for RAW32. What you probably will need to do is set that GFX_CPU setting appropriately. Link to comment Share on other sites More sharing options...
nquantum Posted January 31, 2017 Report Share Posted January 31, 2017 Thread solved! Thank you for your real detail. (how can you spot problem so quick!?) I try sourcetree and master repository already. Great even it not solve this problem. However set the GFX_CPU to GFX_CPU_CORTEX_M4_FP in gfxconfig.h does solve problem. Now thread working. Then I go back and try GINPUT again and it work now! Wow! I not yet touch GFX_COMPILER but it seem to work well now. gmouse_lld_FT6x06_board.h Come with self-calibration #define GMOUSE_FT6x06_SELF_CALIBRATE FALSE//TRUE when it set to true. Out put from demos/tools/touch_raw_reading resolution is limited 644-798 / 0-58 but once I set self-calibration to false then it seem to be 800 / 480 same as display. I will check into detail. Also when self-calibration is false , calibration display-page is apear after power-on/ugfx logo. Only it calibration failed every time I do calibrate even slow/long press touch. I going to see it. Link to comment Share on other sites More sharing options...
Joel Bodenmann Posted January 31, 2017 Report Share Posted January 31, 2017 Great to hear that you got it working! The issues you're having with the touch controller are definitely only related to the driver / board file. It doesn't surprise me that the driver has a few issues as we never got to test it ourselves - it got contributed by a guy that we never heard from again. We'd highly appreciate it if you could investigate and fix it. The issue with the failing touchscreen calibration will most likely be related to the high resolution of the display. The last of the four points that you will press (the one in the middle) is to check the accuracy of the calibration processes. There's a setting that allows setting the maximum number of pixels that the calculated touch coordinates can be away from the actual hair cross on the display. These settings are GMOUSE_FT6x06_FINGER_CALIBRATE_ERROR and GMOUSE_FT6x06_PEN_CALIBRATE_ERROR and should be part of the board file. Try increasing those values. Link to comment Share on other sites More sharing options...
nquantum Posted February 2, 2017 Report Share Posted February 2, 2017 (edited) I have some question. Okay GMOUSE_FT6x06_PEN_CALIBRATE_ERROR, GMOUSE_FT6x06_FINGER_CALIBRATE_ERROR 1. I've increase GMOUSE_FT6x06_PEN_CALIBRATE_ERROR value when I use finger in touch calibration now it pass. But try with GMOUSE_FT6x06_FINGER_CALIBRATE_ERROR is not. So question is how ugfx know I use finger or pen? In GINPUT? In what file/function it make decision? I try to find but not found. Or it is decide in board driver file? 2. In driver GINPUT I've check detail about read x,y,z is it okay to only XH, YH register? No need XL, YL? /* Get the X, Y, Z values */ pdr->x = (coord_t)(read_word(m, FT6x06_TOUCH1_XH) & 0x0fff); pdr->y = (coord_t)read_word(m, FT6x06_TOUCH1_YH); pdr->z = 1; Even it work well but I see in datasheet there is XH,YH for 4MSB bit and XL,YL for 8LSB bit. No need to get that value? Or it is enough already to get only XH,YH register? And yet also FT5x06, FT6x06, FT5336 in ugfx/drivers/ginput/touch seem to be like this also (read from XH,YH). Also in XH bit 7-4 is for other thing not position also YH bit7-4. There no need to mask those and ugfx can understand? Yes driver I test it almost work well now only I check for detail and check in the auto-calibration but these question are still in my curiosity. Edited February 2, 2017 by nquantum Link to comment Share on other sites More sharing options...
nquantum Posted February 2, 2017 Report Share Posted February 2, 2017 Quote 2. In driver GINPUT I've check detail about read x,y,z is it okay to only XH, YH register? No need XL, YL? /* Get the X, Y, Z values */ pdr->x = (coord_t)(read_word(m, FT6x06_TOUCH1_XH) & 0x0fff); pdr->y = (coord_t)read_word(m, FT6x06_TOUCH1_YH); pdr->z = 1; Even it work well but I see in datasheet there is XH,YH for 4MSB bit and XL,YL for 8LSB bit. No need to get that value? Or it is enough already to get only XH,YH register? And yet also FT5x06, FT6x06, FT5336 in ugfx/drivers/ginput/touch seem to be like this also (read from XH,YH). Also in XH bit 7-4 is for other thing not position also YH bit7-4. There no need to mask those and ugfx can understand? I think I get it the reason to call read_word , another function than read_byte coz this will take care of the coordination. Link to comment Share on other sites More sharing options...
Joel Bodenmann Posted February 2, 2017 Report Share Posted February 2, 2017 7 hours ago, nquantum said: 1. I've increase GMOUSE_FT6x06_PEN_CALIBRATE_ERROR value when I use finger in touch calibration now it pass. But try with GMOUSE_FT6x06_FINGER_CALIBRATE_ERROR is not. So question is how ugfx know I use finger or pen? In GINPUT? In what file/function it make decision? I try to find but not found. Or it is decide in board driver file? You can switch between pen and finger mode by using ginputSetFingerMode() (documentation). Furthermore, the flags field of the driver VMT can tell whether the driver is by default in finger or pen mode by using the GMOUSE_FLG_FINGERMODE flag. 7 hours ago, nquantum said: Even it work well but I see in datasheet there is XH,YH for 4MSB bit and XL,YL for 8LSB bit. No need to get that value? Or it is enough already to get only XH,YH register? I don't remember the details on top of my head but as you mentioned in your second we use read_word() instead of read_byte() which will not only grab the XH register. As mentioned previously that driver is pretty crusty and it's very likely that it needs some improvement. We'd be very happy if you could contribute back your updated driver & board file for the discovery board. 7 hours ago, nquantum said: Yes driver I test it almost work well now only I check for detail and check in the auto-calibration but these question are still in my curiosity. You did a great job at getting this board working! We appreciate your endurance on this a lot! Keep up the great work! This and next week it will be almost impossible for us to get anything else done but the week after that we'll have a look at your drivers & board files Link to comment Share on other sites More sharing options...
nquantum Posted February 4, 2017 Report Share Posted February 4, 2017 (edited) Okay thank Now I see that PEN/FINGER. Been busy these days. Now I can use auto-calibrate from ST FT6x06 without problem. Have to say there is hard to find detail in datasheet even hard to find data sheet/application note. Only get little strange: test demos/tools/touch_raw_readings they seem to skip calibration 4-spot touch when power on unlike others demos but that okay. The initial display after uGFX screen show x = 2048, y = 0, z = 1 meaning MSB 12th bit in x is set. Just like someone touch. But there isn't. Once I press any place then it show number of place as normal for example x = 125 ,y = 111 ,z = 1 and back to x = 0, y = 0, z = 0 then no touch. Every time like this so not random issue. Still find what cause this. From what I test I seem like nature of controller since position reading work as normal, also writing. Still look into it more. Do u think of anything? Edited February 4, 2017 by nquantum Link to comment Share on other sites More sharing options...
nquantum Posted February 4, 2017 Report Share Posted February 4, 2017 Take a break: A pic with create from uGFX Studio. Look nice :-) No action code for touch-button event yet (still learning) :-) Link to comment Share on other sites More sharing options...
Joel Bodenmann Posted February 4, 2017 Report Share Posted February 4, 2017 5 hours ago, nquantum said: test demos/tools/touch_raw_readings they seem to skip calibration 4-spot touch when power on unlike others demos but that okay. That is intentional. We want to get the raw reading (as the demo/tool name suggests). 1 hour ago, nquantum said: Take a break: A pic with create from uGFX Studio. Look nice :-) Very nice, great work! Can you tell us what kind of performance you get out of the display? What's the maximum refresh speed you get with your driver/board file? Link to comment Share on other sites More sharing options...
inmarket Posted February 4, 2017 Report Share Posted February 4, 2017 With regard to the nontouch values, when the surface is not being touched the values are often indeterminate or random depending on the controller hardware. This is of no significance however as the surface is not actually being touched. Many controllers however also return random or bad values while the sirface is still touched but in the process of the touch lifting. This is much more serioys and the mouse driver has special code to overcome these sorts of problems. Another common problem is that controllers that use an external pin to indicate a touch status often have bugs where they in some conditions simply refuse to deassert the pin requiring a full power down to fix. For that and other similar problems we by default never use the status on those pins. Besides, our z value handling code is much more reliable than the firmware un most touch controllers in determining a proper touched status. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now