Search Results

Hi When working on another problem I noticed what may be a bug in the LCD driver (LTDC)? Size is being set using the position variables. See below and attached file. It is not (I don't think) causing me a problem. Just mentioned it as it may be an error and I know you guys are fastidious at getting stuff right. p.s.if you happen to have a newer version of this file I'd be happy to receive! It may fix the v.1.2.0 /v1.3.0 MDK-MW-Graphics problem I am experiencing. And if that newer version had the…

Hi, I wanted to update that, now, this is possible: the emWin which ships with MDK-Pro now supports AppWizard. Thanks Segger and Keil! Mark

So, closing this out, too. Some of the emWin lib options are in the relevant GUConf.h which is in the \Include folder complimentary to that \lib pack. It does not list which color_conversions are included. Which is a pity as that'd be nice to know. It also does not show if HW acceleration is built into the \lib (I read, from the documentation, that this is \lib compile-time?). In time I'm sure I'll find out that something else is limited in the build, too. On the plus side - there is now a relea…

OK, so here is what I have found: 1.3.0 is built with #define GUI_USE_ARGB 1, whilst 1.2.0 is built with #define GUI_USE_ARGB 0 I did not dig back but suspect earlier libs had 0, too. My LTDC driver was not compensating for this but I'd have expected only a color difference, not mono. I have a hunch that this build difference may not include, in the lib, some color_conversions resulting in mono in VRAM? Anyway, I'm just posting to close this out. Mark

Some additional testing using different MDK MW-Graphics Releases (first number is the MDK reference): 1.3.0 (6.32.3): does not work, monochrome only 1.2.0 (6.30.1): works fine, get colour 1.1.0 : works 1.0.1 : works Thanks

Hi I've a simple Hello World project. When I use an old (STemWin) 532 library i get colour yet when I use the (MDK-MW) 632 I am only getting monochrome. This is happening at the "paint" level; When I look at the VRAM I see that only 0xFF / 0x00 are being written to layer memory. Code is: Source Code (18 lines) From my LTDC driver: #define COLOR_CONVERSION_0 GUICC_M4444I #define BYTE_PER_PIXEL_0 2 #define DISPLAY_DRIVER_0 GUIDRV_LIN_16 DMA2D is enabled (but, as said, none of the problem is at the…

Hi Is there a place where the build options in the library included with MDK are detailed? I have looked through the folders and whilst I find release notes etc. I do not find the build options. I know you are thorough and I expect that, somewhere, there is a ReadMe which compliments the lib build. My next Post explains why I got to this point but this issues stands alone. Thanks Mark

Thank you Florian. I decided it may be best to ask if there is a M4F.lib available? It would save a lot of linking issues as it would directly replace the STemWin build. If not, I understand. Thank you Mark

Hi I've added AppWizard created source to an existing base project but it fails at APPW_CreateRoot. Am wondering if you can let me know if this is compatible with my base project? AW output is attached (simulation folder removed: too big) Other: - MDK-Community - FreeRTOS - STemWin532 (used as library from ST, not from within the MDK Environment) - GUIConf allocates 1.5M to emWin - STM32F429 + LTDC M565 - 320 x 240 - GUIConf is called from my GUI_Init - emWin runs fine before I get to AW MainTas…

Hi Nino Thanks for your notes. I have revisited this and it (still) does not work. I have taken a few different approaches and documented two - see attached PDF. I have checked and the STM32CubeProgrammer (reported by GDB) is 2.10. Yes, GDB connects. I am using STLINK-V3SET. Firmware is latest. I removed the V3SET isolation board: still have the same issues. Thanks Mark

Hi I'm trying to evaluate S-ES and hitting a problem when I attempt to debug using my STLink (V3, latest firmware). Am wondering if anyone can assist? Pre-empting the obvious comment (!) I would say that buying J-Link to be able to evaluate the IDE is not feasible. Attached are: a. batch file for GDB start (I execute the batch file then Connect to the GDB then start a debug session) b. debug log from GDB c. PC / registers at the end of load / start of debug session: all are 0xa05f0001 d. debug s…

Hi I've been profiling various emWin parts of some projects, trying to work out what core function is taking what time. I appear to have a bit of a bottleneck with text and I'm wondering if anyone, including Segger, has any comments on the time taken to draw a character? I am finding that it is generally taking around 0.2ms/character on a 168MHz STM32F4 (GUICC_M565 -> GUIDRV_LIN_16). Of course, it varies with font,text mode, etc but it is always centreing around 0.2ms/char. I have checked with a…

Hi I\m bumping this with some more information. I have spent a day or two trying to work out what is going on/come up with a work around. It turns out it is not the self-invalidating nature of the hWins that it the root of the problem. It is just, it seems, something at the heart of emWin's WM/rendering. I find that hard to say as I do know how thorough you are. But it feels like it. See attached image: a keyboard. The background is an hwin onto which I have added (WM_CreateWindowAsChild) some 4…

Hi ...just to add that I moved GUI_PNG_Draw such that is is handled by the _cb (WM_USER_DATA). It works fine from there, too. It is just a direct call from the same thread, in same function as hWin was allocated that seems to fail. Given that it works fine from WM_USER_DATA I am semi-happy. Only semi- as I am still a little concerned I have just moved the problem to some other place or day. Thanks Mark

Hi I'm getting a HardFault when I load a PNG as part of my window create code. I do not get this crash if I do one of these: 1. move the PNG load to that window's WM_PAINT handler 2. avoid thread-release in the create() function by changing the thread priority (RTX5) to my highest before calling the PNG_Draw (I then set it back to my emWin normal) 3. use JPEG (my loader func handles both, proving out my core functionality and localizing this to something odd with GUI_PNG_Draw) I tried a simple o…

Hi I have (had) a window with 50 child-windows (each a data label). Double-buffering would not work as the paint time was just taking too long. Performance was very poor and my processor was being fully loaded. Each child-window has its own timer to perform its own data check and refresh (if required). What I have tracked down (and now read in the manual) is that each WM_Invalidate() of a child window causes the parent window to undergo a full refresh. I do not understand why as the child-window…

Hi Sven, Sorry for the delay in responding. I have been travelling. Both layers are the same size (800x480). I understand the issue of transparency when the emWin library is stacking objects or layers and will have a look at this again. Maybe I am misunderstanding the use of VRAM switching for layers in the mb1046-style driver for the 32F429I as I did not think transparency is an issue for the two hardware (vram) layers implemented. I thought they got painted no-matter-what as the vram is RGB in…

Hi I've been using two layers on STM32F4 with the configuration for both layers #define LTDC_X_COLORCONVERION GUICC_M8888I #define LTDC_X_DISPLAYDRIVER GUIDRV_LIN_32 Layers are in SDRAM, each in its own bank. Screen is 800x480. My LTDC frame refresh is low using this configuration so I tried a change to this #define LTDC_X_COLORCONVERION GUICC_M565 #define LTDC_X_DISPLAYDRIVER GUIDRV_LIN_16 However, now my background layer does not show. The primary layer shows correctly. I have not changed any …

Hi Sven Thanks, info helps. I will rework GUI_X_ to suit. It wasn't complaint, more comment to get the answer you have given and say that the stock-code supplied by Keil throws this issue. Regards Mark

Hi I'm getting RTX crash, seemingly due to emWin's use of a 1ms osTimer. I'm wondering if you have comment/workaround without making my emWin thread the highest priority which may result in other issues. Is there a way of re-defining the emWin core to work on a 10 or 20ms tick rather than the 1ms? I have found that this probably works. I think I can do this by changing GUI_X_RTE and then re-scale my WM_TIMER durations but I wonder if there is a more centralised method? Problem is in these circum…