Search Results

Search results 1-20 of 970.

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

  • STM32F746G-Discovery

    SEGGER - Schoenen - - emWin related

    Post

    HI, Of course, _cbCallback and _cbDialog are just names and you can choose them freely. But, the callback set for a dialog receives a WM_INIT_DIALOG message after all its dialog elements are created. This gives you the chance to configure the different elements. A callback function set for a single window gets a WM_CREATE message giving you the chance of reacting to it and creating further child windows or set up some data. You can react to WM_CREATE only if the pointer to the callback function …

  • STM32F429 button click

    SEGGER - Schoenen - - emWin related

    Post

    Hi, You have to read out the touch data from the touch controller and pass the read touch coordinates to emWin. Typically we do this in a dedicated task polling the touch data every 25ms. The interface and communication to the touch controller is user defined and not part of emWin. Attached is a touch configuration we use on a STM32F746 Discovery. You might use it as a reference. Regards, Sven

  • Hi, You could use our tool Bin2C.exe to convert a binary file into a c-array. This array can be compiled along with the other files in your project. For large fonts I recommend to xbf fonts. xbf fonts use some sort of a look up table to find a character in a font. This requires only two files accesses. With sif fonts emWin will search the complete font to find a character. Especially with large fonts it might take a while to find a character if the character is at the end of the font. The Bin2C …

  • Hi, Is GUI_Init() beeing called multiple times? You Do this in your appliaction. I know that in some ST examples GUI_Init() is getting called before MainTask(). Call it just once. Regards, Sven

  • Hi, Do you get out of GUI_Delay()? I could imagine that the timing related functions are not correctly implemented and GUI_Delay() waits forever. Search for GUI_X_Delay() and GUI_X_GetTime(). GUI_X_GetTime() has to return a 1ms tick, either provided by an OS or a HW timer with a period of 1ms. GUI_X_Delay() waits for the given amount of time either by calling an RTOS-delay-function or waiting vor a variable incremented by the 1ms timer. Regards, Sven

  • 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

    Post

    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

    Post

    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

    Post

    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