Search Results

Hi, The GUI_SetRefreshHook() function is what I wanted to suggest. Try something like this: C Source Code (16 lines) The driver needs to use a cache. When using the Window Manager you have to do nothing else, it will take care of locking/unlocking the cache. If not using the Window Manager you can use LCD_ControlCache(LCD_CC_LOCK) and LCD_ControlCache(LCD_CC_UNLOCK) before and after a drawing operation. Do NOT use WM_MULTIBUF_Enable() in your application. This would disable the locking mechanism…

Hi, please try to use the animation module of emWin instead of the motion support. Regards, Sven

Hi, please try to "unoptimize" the GIF as described under link below: segger.com/doc/UM03001_emWin.html#IMAGE_SetGIF Regards, Sven

Hi, The test screen looks almost good. See attached on how it should look like. After drawing the red, green and blue rectangles and the strings a large rectangle gets drawn with invert mode. If this is not being displayed properly it is most likely that the read function is not working right. If it is not possible to read from the display (for what reason ever) it is mandatory to use display cache. To invert the colors emWin needs to read the pxel data and write it inverted back to the LCD. Wit…

Hi, Please try the code below. It draws a test pattern on the display. C Source Code (25 lines) Can you send me a photo of the output? Best regards, Sven

Hi, Are you referring to the size of the generated c-file or the xbf-file? The size of the c-file doesn't say anything about the size on the target. I just gave it a try and the generated xbf-file has a size of ~20KB with the following code point ranges: 0x0000 - 0x007F 0x0100 - 0x017F 0x0180 - 0x024F The size of the font is 24 pixel. Of course, it depends pretty much on the font itself how much data are included in the file. The size of the xbf-file is the size it takes on the hardware. Which f…

Hi, Regarding multiple character drawing, can you send me your LCDConf.c (I guess NXP names it emwin_support.c). So, I can take a look into it. Not sure what might cause this behavior, yet. Quote from Suresh: “Is this enough to run Appwizard Application? ” 16K is not that much memory... Typically we recommend to have at least 130K available. Regards, Sven

Hi, When using memory devices for windows/widgets emWin will draw the bitmaps at first into the memory devices. Once this is done the memory device will be displayed at once. If you are using no memory devices you might experience a visual build up of the image because they will be drawn line wise. This will result in a flickering effect. The most efficient way to avoid this would be either multi buffering (GUIDRV_Lin) or a cache (almost any other driver, e.g. GUIDRV_FlexColor). If you don't hav…

Hi, Unfortunately, it is not possible to use fonts created with the the Font Converter in the AppWizard. If you create/modify a ttf font and install it under Windows you would be able to use this font within the AppWizard. Not sure if there exist free tools for this available in the web, but I could imagine they do. BTW, I recommend to create an 'extended' font with the Font Converter. The 'standard' fonts will waste memory since they will store also empty pixels. Regards, Sven

Hi, Quote from bio_med: “Also, when the image is touched, it clears the entire scree. ” This shouldn't happen at all. For now I have no idea why this happens on your end. You could try to catch the touch events of the IMAGE widget and do nothing, like: C Source Code (13 lines) Although, this shouldn't cause such a behavior, you could also try to remove these calls: C Source Code (4 lines)When using multibuffering there is little to no reason of using automatic memory devices. This will produce o…

Hi, Not sure why you see the second image in the background, but when removing the transparency flag of the image you should make sure you paint the entire widget area. In the callback functions of the image widgets you draw only the BMPs. The Service BMP is smaller than the widget and there will be some undefined space left. I could imagine that this undefined area will show any kind of artifact (on my end it was simply black). Try something like: C Source Code (13 lines) Best regards, Sven

Hi, Do you have some code which shows how to reproduce it? Regards, Sven

Hi, both controller are supported by the GUIDRV_FlexColor driver. When setting up the driver you have to use GUIDRV_FLEXCOLOR_F66714 for the SSD2119 and GUIDRV_FLEXCOLOR_F66709 for the SSD1355/ST7735. Basically, that's all. YOu might have to adapt the read and write routines set in the device API structure. Regards, Sven

Hi, If you are using the GUIDRV_Lin driver you should use multi buffering to avoid tearing effects. If you are not using the GUIDRV_Lin driver simply select a cached version of your driver (it's indicated by a 'C' or 'C1' in the driver name or driver mode). Regards, Sven

Hi, supported color mode of the driver can be found here. GUIDRV_FLEXCOLOR_F66709 does not support 18bpp. It might be necessary to set a different read function. Check out the description of GUIDRV_FlexColor_SetReadFunc66709(). You can also set a custom read function with LCD_SetDevFunc(). Attached is an example configuration. Regards, Sven

Hi, Are the function GUI_X_Delay() and GUI_X_GetTime() are properly implemented? Attached is are some examples to be used with FreeRTOS/embOS or without RTOS. For the non-ROTS variant you have to set up a hardware timer wich increments OS_TimeMS every ms. EDIT: Forgot the attachment. Regards, Sven

Hi, Yes, your summary is correct. Please note that you might want to also adapt the function which passes touch input to emWin. I think BOARD_TouchPoll() it is called in the NXP examples. You can also set up multiple driver instances and link/unlink them on runtime. This allows you to rotate on runtime just with another driver. Regards, Sven

Hi, it seems the function LCD_X_Config() in the file emwin_support.c is not aware of the driver orientation. Try to exchange the LCD_X_Config() by the one below: C Source Code (16 lines)Best regards, Sven

Hi, my colleague told me that we actually have such a function. I wasn't aware of that. Simply call the following function in LCD_X_Config(): C Source Code (1 line) The UpdateLCD() function looks like: C Source Code (6 lines)The LCD_CC_LOCK command is send after the Window Manager has drawn the last invalid window. It is important that you do NOT use any multibuffering API when using GUI_SetControlHook(). So remove any calls of WM_MULTIBUF_Enable(), GUI_MULTIBUF_Begin()/GUI_MULTIBUF_End() and GU…

Hi, No unfortunately there is no such function. You could try something like: C Source Code (6 lines) The disadvantage is that GUI_Exec() returns also with 1 if emWin has processed other things than drawing like timer or touch input. Another solution might be to use the multi buffering API. In the function LCD_X_Config() you set the VRAM address like this: C Source Code (17 lines)Now emWin "thinks" it has to buffers to be used for multibuffering. and will send the LCD_X_SHOWBUFFER command to the…