Search Results

Search results 1-20 of 965.

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • Hi, the GUIDRV_FlexColor driver for the ILI9488 does not support an 18 bit interface. It supports only 8 and 16 bit interfaces. Regards, Sven

  • Widget within a widget

    SEGGER - Schoenen - - emWin related


    Hi, Attached is a very basic example. The first dialog gets created and starts a timer. Once the timer expires the dialog deletes itself and create the second screen. Regards, Sven

  • SSD1963 in 8-bit Mode

    SEGGER - Schoenen - - emWin related


    Hi, It's hard to say what is going wrong. You have to set some function to write data to LCD controller. Do you get into them? Within GUI_Init() emWin fills the LCD with black, this would mean you get to a specific point without hardfault. You are using a non cache version of the driver, did you set read functions? This is required when using a driver without cache. How much memory did you spend emWin? Try to increase the memory passed to GUI_ALLOC_AssignMemory(). Do you have enough stack? Regar…

  • Hi, Attached is a short example. The reason on side is most likely related to the GIF. Try to open the GIF with GIMP (or any other image editor tool) and un-optimize the GIF. Most GIFs are saved optimzed which means they store only the difference to the previous image. Unfortunately, this results in a strange output when only a sub image gets drawn. Regards, Sven

  • Hi, Per default the WINDOW widget and the simple WM-window do not manage IDs. Add the following to your window callback: C Source Code (3 lines)Regards, Sven

  • Hi, thanks, I*ll give it a try. Quote from Andy_AN2: “Unfortunately I am unable to provide you a demo example. What hardware should I use? ” I meant something like a single-file-example which show how you serialize the screen and save it. Not a complete project. Anyhow, I think the information you have provided are sufficient. Regards, Sven

  • Hi, this can have multiple reasons. It looks like the GUI memory gets overwritten at some point. Or the SDRAM is not working correctly. Can you post the rest of the dialog? Do get into the case WM_INIT_DIALOG within _cbDialog()? Regards, Sven

  • Hi, can you send me an example which shos how to reproduce the behavior? Also your configuration file (LCDConf.c/.h GUIConf.c/.h) would be interesting. Regards, Sven

  • Hi, Indeed, without the source code this gets pretty hard to debug. Unfortunately, I have not a real idea why it stops working. Does the client still sends framebuffer update requests? The server sends data only on request. Which client are you using? Regards, Sven

  • Hi, I gave it a try and it is working fine. Which version of emWin are you using? It might be that there was bug in an older version and is fixed now. Try to get access to a more recent version. Regards, Sven

  • Hi, Unfortunately, the GUIDRV_BitPlains driver doesn't support this function. We will add this in a future version of emWin. For now you have to store the framebuffer addresse on your own and write a little function to access it from somewhere in your application. Regards, Sven

  • Hi, The first choice on a STM32F7 should be GUIDRV_LIN_32. With this driver you will experience the best performance. The reason is that with 32bpp no conversion is required from the internal format emWin works with (32bpp) and the framebuffer format. Of course, the framebuffer needs to be configured for 32bpp and it will require more RAM. I wouldn't expect a rotated driver faster than one with default orientation. What kind of bitmap are you displaying? Can you send me the bitmap? Is the hardwa…

  • Hi, the GUIBuilder should wrap color values with a macro like: GUI_MAKE_COLOR(0x000000FF) // Red This macor converts the given ABGR value into the proper byte order. Regards, Sven

  • Hi, I think this is related to GUI_EnableAlpha(). Between V5.44 and V5.50 where some changes regarding the alpha module and this behavior should be fixed. Unfortunately, there is not much you can do about it, except of using a memory device or a bitmap for the background. Regarding GUI_USE_ARGB, I highly recommend to use a library compiled with GUI_USE_ARGB 1. This has the best performance on STM32 devices. Regards, Sven

  • WM_SetUntouchable

    SEGGER - Schoenen - - emWin related


    Hi, OK, now I got it, I guess. Try this: C Source Code (151 lines) In WM_INIT_DIALOG of _cbDerivedDialog() I create another window which is transparent. This window will catch the input outside _cbDerivedDialog() and do nothing with it. After creating this window make sure that all dialogs which should still receive input are on top (at least over the transparent window). Regards, Sven

  • Hi, I changed the line for setting the color in _LISTWHEEL_Draw() into C Source Code (1 line)and it is working. Depending on the color format emWin uses internally, the alpha bits can be 0x00 or 0xFF for opaque. If the library is compiled with GUI_USE_ARGB 1 an alpha channel with 0xFF means opaque. If it is compiled with GUI_USE_ARGB 0 the bits are inverted (0x00 is opaque). When GUI_USE_ARGB is set to 1 GUI_GREEN is defined as 0xFF00FF00. 0xFF00FF00 ORed with 0x80000000 is still 0xFF00FF00 resu…

  • Hi, I can't say if this is related to the font. I don't have the font. Is it possible to send me the font? If this is a free font, where can I download it? Regards, Sven

  • Hi, please don't open threads with the same topic/question multiple times. Regards, Sven

  • WM_SetUntouchable

    SEGGER - Schoenen - - emWin related


    Hi, If I get you right you want to make sure that the initial dialog (the one with _cbDialog) don't receive input when the derived dialog is created (_cbDerivedDialog), right? To achieve that you can simply make the derived dialog modal: C Source Code (27 lines)Regards, Sven

  • Hi, I can't reproduce the behavior. With the code below I can display the string with a red background ending pretty much directly with the last character. I had to adapt the GUI_RECT because it didn't fit on my screen. C Source Code (16 lines)Are you using a stock font of emWin or a font created with the Font Converter? Regards, Sven