Search Results

Search results 1-20 of 753.

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

  • Hi, The dist driver should exactly do what you want. Here is a snippet from a LCDConf.c used for two UC1611 controller. First the GUIDRV_DIST driver gets created for layer 0. And the two 'real' drivers are getting created for layer -1. Later on they are getting added to the dist driver. C Source Code (89 lines)This was made for the GUIDRV_SPAGE driver but should work also with the GUIDRV_FlexColor driver. EDIT: Once set up the two displays are getting handled as one big screen. Regards, Sven

  • Hi, I gave it a try and checked it with version 5.38 of emWin. The BMPs are getting dipslayed properly. Maybe there is an issue with the filesystem? Please try the example attached. There I draw the screen.bmp slightly different. I converted into a c-array and compile into the application. This way you don't have a FS in between. Regards, Sven

  • Hi, I'm afraid but without knowing which emWin functions you are calling within WM_PAINT I can't really say why you get the error. Basically this error message gets only thrown for three emWin functions, WM_DeleteWindow(), WM_SelectWindow() and WM_Update(). You can also step through your WM_PAINT event and try to find out which emWin function causes the error. Regards, Sven

  • Hi, Are you sure that you don't overwrite some of the GUI memory? Maybe a conflict between frame buffer and GUI memory (just a guess). Which device are you using? Quote: “Is this a bug in the library (we are using STemWin540_CM7_GCC.a but also tried the other libs)? ” For now we are not aware of any issues with displaying text. Regards, Sven

  • Hi, You can use the DMA in the write function for multiple bytes (GUI_PORT_API structure member: pfWriteM8_A1). Just use the DMA to send the data bytes. Rotation is also possible with GUI_SetOrientation(). Please note that this method requires some additional memory because we create a rotation device in the background. Most LCD controllers support rotation and we recommend to use rotation by the LCD controller. In most cases this is way faster. Regards, Sven

  • Hi, On my end the BMPs are getting displayed correctly. You can find the emWin version in GUI_Version.h. Can you also post your LCD configuration (I guess it's named support_emwin.c)? Regards, Sven

  • Hi, Which version of emWin are you using? What kind of BMP are you trying to display? Does it work with another BMP (e.g. instead 16bit a 24bit BMP)? Regards, Sven

  • Hi, Hard to say what is causing this effect. Do you use a cache for the GUIDRV_FlexColor driver? This would allow to read the pixeldata from memory on MCU side. This way you could try to isolate the cause of this issue. Did you tried our GUIDRV_FlexColor implementation for the ST7789? Regards, Sven

  • Emwin License

    SEGGER - Schoenen - - emWin related

    Post

    Hi, The free versions which are offered by the silicon vendors (like NXP or Renesas) do not have any technical limitation. The technical limitation is that you don't have access to the soure code which might make it harder for you to debug your application. The only real limitation is the licensing. With the free versions you are bound to a specific device or a device family. Under this link you will find a price list for the different emWin version (the difference is the number of features avai…

  • Hi, WM_IsCompletelyCovered() returns 1 if the window is completely covered by another window. WM_IsCompletelyVisible() returns 1 if no part of the window is covered by another window. WM_IsVisible() returns 1 if the window is not hidden, even if the window is completely coverd. It will return 0 if you hide it (by calling WM_HideWindow()). Regards, Sven

  • Hi, You can simply use the callback function of the back ground window (_cbBk) and perform the drawing operations within the WM_PAINT. Another way would be to create a window with WM_CreateWindowAsChild(), don't forget to set a callback function, and perform the drawings in this callback functions WM_PAINT event. Quote: “ I'm still having difficulties wrapping my head around how to make WM "know" about my drawing operations. ” It's not rellay knowing, just perform drawing operations only within …

  • stemwin for stm32f407

    SEGGER - Schoenen - - emWin related

    Post

    Hi, I have to correct myself, there is a project available for an STM32F407. Under the linke below you will find several downloads for the STM32F40G Eval board. Among other a project for Embedded Studio. segger.com/evaluate-our-softwa…tronics/st-stm3240g-eval/ Regards, Sven

  • Hi, Which version of emWin are you using? Which driver are you using? If you are using a driver for an indirect interface (e.g. GUIDRV_FlexColor) please check if the function for reading are working properly. Regards, Sven

  • stemwin for stm32f407

    SEGGER - Schoenen - - emWin related

    Post

    Hi, Unfortunately, I don't have such a project. Try to use one of the other example projects for a slightly different MCU and do the required modifications. Regards, Sven

  • Drag touch on buttons

    SEGGER - Schoenen - - emWin related

    Post

    Hi, Try to call BUTTON_SetReactOnLevel(). This will cause the buttons to send click messages only when the down event occurs in the button area. Regards, Sven

  • Hi, From emWin side there is not much you can do. emWin just uses the data passed to it. I suggest to debounce the touch input before passing it to emWin. This way you can filter out those values which are causing the issues. Regards, Sven

  • Hi, Things are broken because the Window Manager doesn't "know" about your drawing operations. The Window Manager expects any drawing operations within a WM_PAINT event. The best would be to not draw in MainTask. Move the drawings to a window. This window could also be the desktop window, just draw in the callback set for WM_HBKWIN. Like: C Source Code (23 lines)Or you create a dedicated window which gets created/displayed after the dialog has been deleted. Regards, Sven

  • Dialog background

    SEGGER - Schoenen - - emWin related

    Post

    Hi, Yes, without an overwritten WM_PAINT event you can call WINDOW_SetBkColor(). But you can also react on WM_PAINT in the dialogs callback function and call GUI_SetBkColor() and GUI_Clear(). The WM_PRE_PAINT message shouldn't be used for drawing operations. This message (as well as WM_POST_PAINT) is just for preparing the paint event. Regards, Sven

  • Hi, Hard to say, occurs the release within the button area? If you move the input out of the button area while keeping it pressed the button won't get a release message. It gets the release only if it happens within its area. With little buttons on a screen with an imprecise touch this can happen quite quickly. Give it a try and test it with a big button. Does it always get a release? If it doesn't, check the touch implementation. It is important to pass the unpressed state (Pressed member of GU…

  • Hi, WM_DisableWindow() will only disable the window/widget with the given handle. So, you have to disable all buttons manually. If you assign the IDs for these buttons successively you can iterate over the button IDs to disable them. 1. Set capture might work. But this depends on your application. 2. This will work. But also any other widget/window won't get input. I would use WM_DisableWindow(). Here is a short example: C Source Code (143 lines)EDIT: Did a mistake in the example. Fixed. Regards…