Search Results

Search results 1-20 of 762.

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

  • Hi, the best color mode would be GUICC_M8888I - ARGB. This one offers the best performance since there is no conversion required. Inernally emWin computes with 32bit colors, so when drawing to the framebuffer the colro have to be converted to 16bit. But with 16 bit it is M565. In this case it doesn't really matter whether if the GUI_USE_ARGB flag is set or not. The output gets always converted to the chosen color format (M565 or 565). But I would recommend to use a library (or compile the code) …

  • Hi, Yes, this should be doable. You might take a look into the LCDConf.c we use for the STM32F4/7. The way it goes should be similar. Regards, Sven

  • Hi, This is a perfect example for a usecase of memory devices. Try the code below, I guess that is what you want. The problem is that emWin will write the transparent pixels (the string) to the background which leads to fully transparent pixel in the frame buffer, it does not mix the color. Due to this the result is a black pixel. With the memory device the pixels will also set to fully transparent, but when drawing the memory device it does not touch the background when setting fully transparen…

  • Hi, This one should never become public and has changed since it was created. The demo with the light bulbs also does not exist any more. But I have found an ancient version in the catacombs of my hard disk. I can't guarantee that it will run but you can grab what you need out of it. Regards, Sven

  • CHECKBOX

    SEGGER - Schoenen - - emWin related

    Post

    Hi, try this: C Source Code (130 lines) Regards, Sven

  • Hello Chen, We are not aware of any issues with auto devices. Unfortunately, I do not know how you make use of the devices so it's hard to say what is going wrong here (a simple application which shows how to reproduce the issue is always a good idea). In general it shouldn't be necessary to have more than one auto device. The device checks which area is 'dirty' and only this area gets updated. I don't understand why there should be more than one devices. Attached is an example for the usage of …

  • Hi, Unfrotunately, I can't tell when the next version of emWin will be released. Also please note that we are not responsible for the release of the libraries provided by the silicon vendors. To keep updated to the latest version of emWin you could buy a source code upgrade which includes a discount (compared to a general emWin purchase). This way you will have always access to the latest version of emWin. segger.com/products/user-inter…win/emwin-source-upgrade/ To get rid of the leading zeros y…

  • Hi, You are right. For now you can set a the SKINFLEX_POROPS also for another state, e.g. SPINBOX_SKINFLEX_PI_ENABLED. I have fixed this and it will be available with the next emWin release. Regards, Sven

  • Hi, Thanks for pointing this one out. We will fix this behavior. In the meanwhile you can use the workaround below. You have to set a custom callback for the DRAOPDOWN widget and react on WM_KEY. If the selection is disabled set a new selection. Set the callback below with WM_SetCallback(hDropdown, _cbDropdown); C Source Code (35 lines) Regards, Sven

  • 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 …