Search Results

Have you verified that your underlying hardware is working first? ie board <-> LCD? (I'm working on a project now using an STM32H7 CPU, and before even thinking about integrating ewWin, I first worked through some of ST Micro's LCD examples in the FW pkg to get basic LCD display working) ie this looks like the FW package you probably have for CubeMX for that processor? STM32Cube_FW_F4_V1.24.0\Projects\STM32469I_EVAL\Examples\LCD_DSI.... Now the 'msp' config, ie GPIO pin assignments in their exam…

Hi All, Just wanted to update this, as I had to go down this road to setup some background colors for buttons, as my setup has many of them, and I did NOT want to deal with global skinning properties.. So this is what actually works to change the button background color, without affecting buttons globally... you can use the 'GUI_FillRect()' or 'GUI_FillRoundedRect()' as shown below, to fill the button background color. (RoundedRect being more like what the default buttons look like, with rounded…

Quote from sravan: “Hi All, Even i'm also facing the same issue of screen hiding when continuous switching happens between multiple screens in stm32 platform . case1 : screen hiding issue occuring after 40 screens with the size (#define GUI_NUMBYTES (90 * 1024) ). case 2:If i increase the GUI_NUMBYTES to 95*1024 the screen hiding is still occuring but this time after 45 screens. As RAM size is constraint in my design i cant increase more than above. so is there any procedure to delete the screen…

Quote from MJus: “Hello Mike, well, thats very funny, we were doing the same thing at the same time. Whish I had found a thread like yours at the beginning of May when I had started with the migration of my project. Unfortunately my debugger isn't working quite properly yet. So, I can give you a helping hand with your Dark Theme problem, under "Tools -> Option -> Enviroment -> User Interface (Scroll Down) -> Theme" you are able to set a dark theme, for the whole Window (and not just the color sh…

Hi, awesome, glad to hear it's working... yeah, you could be running into timing issues, or maybe even caching issues with the sram? in the STM examples (in particular emWin ones) you'll see STMicro usually calls the 'MPU_Config()' function, which sets their external SRAM (or SDRAM) device to be 'WRITE-THROUGH' so that they don't have stale data in the cache that hasn't been flushed to ram... this normally is because they are using the external memory for a frame buffer, but could be a similar i…

Ok, Just to eliminate things I would move your aMemory to an internal sram, do you have any other sram banks on that chip you can use? I too was using that particular SRAM chip on my board, but ended up needing much more ram for a frame buffer (as the STM32H7 has the LTDC controller, hence the need for a frame buffer).... I didn't really have any issues with it, but I never tried to put emWin memory in it either. also push your SES stack/heap sizes up as well if you can.. I think I have mine at …

This all sounds to me like you are running out of memory, I too am using a custom board I made myself, with an STM32H7, using emWin, and SES. (I posted my startup files I put together for the STM32H7, with all the memory placement and flash placement .xml files, in a thread in the SES forum.) Hardfaults will happen easily if you run out of memory, have memory corruption issues, bad pointers, etc.. 1) Check what memory region your stack/heap is assigned to? (ie in the flash_placement.xml) 2) You …

Hi Sven, awesome, thanks so much for this, gives me a nice foundation to work from to try out in my code... - Mike

Hi All, Does anyone know the simplest way to design/emulate something like a 'paint' window? i.e. what you could probably call a 'DRAW' widget, where say you define a blank window, and you capture and display all PID inputs in that window. for example, my display is 800x480, touch screen. 1) I want to make a window of say 400x400, and allow the user to actually 'draw' in the window with their finger? 2) and just display a dot or pixel at each touch point? Only thing I can think of is to just set…

Hi All, Just wanted to share this, in case anyone out there was working on an STM32H7xx (or similar) project, and was looking to switch over to SES. (I know Segger has mentioned they are still working on their IAR to SES import flow (as well as adding a CubeMx type import).) The IAR<->SES import currently works for the basic project properties, etc, but you will still need to fix some things up manually, and I found some of the files from their 'Nucleo eval board' example code merged with some o…

Hi Mike, Not sure if my ideas are valid or not, but figured I'd mention what I think my approach would be, a couple different possibilites: 1) Create 'Window' widgets that are the size of your BMPs, and just have the BMPs displayed with the WM_PAINT callback for each window widget... You can use the 'WM_HideWindow/WM_ShowWindow() APIs to make them go away or be shown.. (I'm currently doing a very similar setup with 4 buttons off my 'main menu' in my design) 2) Create 'IMAGE' Widgets instead of t…

Well, just to update: It appears there are conflicts of about 6 or so functions in the 'cmsis_gcc.h', which comes with Free_RTOS, and the same functions declared in the 'intrinsics.h', that comes with Segger Studio.. ie '\SEGGER\SEGGER Embedded Studio for ARM 4.16\include\intrinsics.h' example cmsis_gcc.h: Source Code (1 line) intrinsics.h: Source Code (1 line) So for some reason these functions are not defined the same within the Embedded Studio and elsewhere...

Hi, I'm currently working on a project using IAR EWARM, which is using the STemWin API library and the FreeRTOS library. I wanted to try Embedded Studio to see how it does compared to IAR, and it mostly builds except for 14 errors when compiling the 'cmsis_os.c', which is part of the FreeRTOS and comes with the STemWin library. (ie you can find it in your latest StemWin 1.4.0, "STemWin_Library_V1.4.0\Middlewares\Third_Party\FreeRTOS\Source\CMSIS_RTOS\cmsis_os.c" I made a simple 'temp' project wi…

Sven had told me in another thread I opened to try this (although at the time I was trying to use both hardware layers of the lcd controller in my mcu, but I put that aside for now) Add a callback function to your frame window, see if it works? Source Code (8 lines)

Quote from volodymyr: “Quote from MikeFlyersFan: “Hi, Is there a way to change the background color of the MULTIPAGE tab? I'm able to change the tab font without issues, and the background color of the dialog box attached to the tab... but the tab itself always has a white background? (see the attached picture) ” Hello. I already solved this. I wrote callback-function for multipage like this: Source Code (22 lines)” Oh man! This is even better! I didn't even think about the 'focused' versus 'non…

Hi Sven, Ok, thanks for the heads up, I'm using the Flex skin for the widget, so I'll play with the properties and see if I can get it.. thanks again, - Mike

Hi, Is there a way to change the background color of the MULTIPAGE tab? I'm able to change the tab font without issues, and the background color of the dialog box attached to the tab... but the tab itself always has a white background? (see the attached picture)

Hi, So, currently I'm still using 'blocking' mode as you are, as I still see corruption when using non-blocking (ie DMA interrupt mode). I don't know yet what that actual issue is, but I didn't really see any advantage to using non-blocking anyhow, so I'm sticking with this for now. *In either case, as I mentioned, you need to make sure any memory you are using for LCD operations is either 'flushed' before any DMA, or your memory is setup as 'WRITETHROUGH' so it cannot be cached.... I was using …

Not sure if this is what is occurring for you, but figured I'd mention what I was seeing just in case.. I'm currently working on a project using an STM32H7.. using the DMA2D transfers, which is pretty much how all transfers are done with the lower level driver that emWin calls.. Anyhow, I was seeing a bunch of distortion as well, especially when trying to use the non-blocking/interrupt driven DMA functions. I ended up going back to using blocking, as the interrupt-driven still is not quite right…

** REsolved this issue, it was indeed handling the 'UP" (loss of contact) Interrupt even in my touch ISR ** Once I handled the no-contact event, and reported it via the 'GUI_TOUCH_StoreStateEx()' API *** This thread can be closed as SOLVED ***