Search Results

Search results 1-20 of 764.

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

  • Hi, Not sure what is causing this behavior. First I would double check the touch and make sure that there is only one up event for every down event. Do you also get a press message before the second release? Are the values of the pMsg member the same? pMsg->hWin - receiver of the message pMsg->hWinSrc - sender of the message pMsg->Data.v/p - union with additional data, not always used pMsg->MsgId - obviously always the same Check if the members have always the same values. If e.g. hWinSrc change…


    SEGGER - Schoenen - - emWin related


    Hi, This sounds strange. Did you cheecked if your touch input is working properly? If you create a simple button, does it react on touch? C Source Code (7 lines)Regards, Sven

  • 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


    SEGGER - Schoenen - - emWin related


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


    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…