Search Results

Hi, When drawing AA shapes emWin needs to read the background to mix it with the semi transparent foreground pixels of the AA shapes. Quote from Mark_C: “If I set a number higher than 1 on GUI_AA_SetFactor() the program will execute the ReadM8_A1 function and will get stuck on a HardFault after its execution. Same happens to GUI_AA_DrawPolygon. ” So, it crashes when the programm returns from LcdReadDataMultiple() and is within emWin code again? Or does it crash while within one of the read funct…

Hi, Please try to use the one for the M7. It should work without any issues. Regards, Sven

Hi, I suppose that there is something wrong with the touch implementation. Please check the routine which passes the touch input to emWin. I have found an example within an older cube package (1.4.0) for the STM32H747I Disco. The function which passes the touch to emWin is called BSP_Pointer_Update(). On the first glance it looks ok, but I can't check this on hardware. I would check if the parameters passed to GUI_TOUCH_StoreStateEx() are correct, especially the "Pressed" member of the GUI_PID_S…

Hi, Yes, it is not clear on this point. We will add a description. Regards, Sven

Hi, Yes, the animation gets deleted automatically after it reaches the end. GUI_ANIM_StartEx(hAnim, 1, NULL); would cause the animation to be processed one time and beeing deleted after it. Regards, Sven

Hello, Quote from stalinSEGGER: “The event callback for push button is triggered but immediately it is crashing. ” So you have set a custom callback for the button? Can you post the code? Where exactly does it crash (any function call)? Regards, Sven

Hi, Good to know that it is working with the cache enabled. Not sure about the differences in regards of reading. With the cach enabled emWin does not need to read from the LCD controller, but reads from the cache instead. I suppose that something like the byte order of the hardware reading routines is not correct. Enabling the cache will speed up the drawing process in most cases, too. First the data will be send only once and in one large block to the LCD controller. emWin will send only the s…

Hi Andy, I suppose that the read function set for the GUIDRV_FlexColor is not working properly. You could check this by filling the screen with a color and read it back with GUI_GetPixelIndex(). For example, fill the screen with GUI_RED and read back the first pixel at 0|0. GUI_GetPixelIndex() should return 0xF800 (with GUICC_M565). Another solution might be to use a cached version of the driver. This way it doesn't need to read from the LCD controller but reads the pixel data from the cache. Of…

Hi, It's hard to say what is causing this behavior. Can you send me the code which shows how you create both windows (including the callback function and anything else which is required to draw both windows)? Regards, Sven

Hi, Not sure why this happens. Can you post your code or a small example which shows how to reproduce the behavior. Regards, Sven

Hi Mark, The LCD_X_8080 functions, do they use bit banging (toggling the IO pins of the MCU) or do these functions use a dedicated hardware module (e.g. a 8080 module on the MCU)? Bit banging is pretty slow and will cause a visible build up on the screen. I recommend to use a hardware module for this. Please note, it is not necessary to use an 8080 interface with this driver. You could also use SPI for example. Of course, this depends on the available interfaces of the LCD controller. Regards, S…

Hi, try to call GUI_Exec() after hiding the IMAGE widget. This should cause the background to be redrawn. Regards, Sven

Hi, You have two options, either wait until NXP releases the next emWin version or you purchase an emWin source code upgrade. We offer a special discount for user of emWin provided by some silicon vendors. The source code upgrade includes frequent releases and support from the developers emWin. More information about the source code upgrade can be found here: segger.com/products/user-inter…win/emwin-source-upgrade/ Regards, Sven

Hi, Your configuration file looks good so far. You might want to try another read function. Please refer to the API description of GUIDRV_FlexColor_SetReadFunc66709_B16() in the emWin user manual. You should also check your write functions. It can be possible that the LCD controller expects the data in another order. Regards, Sven

Hi, It depends on the LCD driver you are using where the pixel data is stored. If you are using the GUIDRV_Lin driver the data is stored within the framebuffer which gets not allocated from "aMemory". The framebuffer typically gets allocated within the LCDConf.c and is not done by emWin. If you are using another driver, e.g. the GUIDRV_FlexColor driver, a buffer of one line gets allocated from "aMemory". In case you are using the GUIDRV_FlexColor driver with a cache enabled a complete screen get…

Hi, Hard to say what's going wrong here. I suggest to double check your routines for writing and reading data, set in the PortAPI struct. Please try the code below. C Source Code (25 lines)The output should like on screenshot attached (simulation). Best regards, Sven

Hi, emWin is written in ANSI C and is completely independent of any toolchains, compilers, architectures, etc.. I suppose that this issue results in the way the library was build. Unfortunately, SEGGER is not responsible for building the libraries provided by the silicon vendors. I suggest to contact NXP in this case. Quote from lsrbigfoot: “I guess the real question is, does emWin library source (used to build .a library file) have globals with non-zero initializations? ” No, there are no non-z…

Hi, it depends on the interface type. The functions you have listed are sending only 8 bits at once. Other interface may send 16 or 32 bits at once and would have to implement and set the other function pointers. Regards, Sven

Hi, Unfortunately, I can not say what exactly Cypress does ship to their customers. If you purchase the Source Code Upgrade of emWin (with a special discount) you will have access to the full version of the Bitmap and of course to the source code of emWin. segger.com/products/user-inter…win/emwin-source-upgrade/ You can check out the Bitmap Converter Demo, it has no functional limitation, but you are not allowed to use it in a comercial product. segger.com/downloads/emwin/ Regards, Sven

Hi, emWin is completely independent of any hardware and any third party software. Also, there is no license check of CRC init within emWin. The libraries you are using are generated by STM , so I can not say if they build in some sort of license check (although they shouldn't). Maybe you should try to contact STM. Regards, Sven