Search Results

Hi, Awesome, I can confirm with 0 io 20 as version it works now! And thanks for the version information, i just took something in the middle of the range thinking middle is good without really knowing what it does. Since it seems unlikely we will ever get a stemwin with the fix, is there a way for me to check up front how much free memory is left to block calls that would trigger the problem ? (I would have to avoid using version 0 then too otherwise I dont know how big the bitmap will be) Or ma…

Hi, Any updates on this ? Is there maybe a possibility to give me just the sources for the QR generator part so I can check here what is going on ? If not I think i will just use some other QR generator code and draw the matrix myself, but it is a bit stupid if the code is already present. (If Segger used an existing one which is available under an MIT/Apache/... license let me know then I try to use the same one and maybe learn that way what goes wrong). Regards Bram

Hi, GUI_Init() is called via STemwin_wrapper.c/GRAPHICS_Init() This happens before Freertos is started, while the DISPLAY_Init is called from a Freertos task (i hope there is no restriction there ?). At the moment I only use the "primitive" drawing functions, but I will keep the superloop in mind for when I need something more complex. Regards, Bram

Hi, To simplify the scenario down to the essence I replaced all the stuff I do with the following startup code and I still run into the issue: Source Code (16 lines) I have display.c containing this snipped together with GUIConf.c (which configures the memory area) and STemwin_wrapper.c (I don't think there is anything relevant in there but you never know there is something relevant in there) to a file located at: download.dekimo.be/public/BPE/QRTest.zip Is this sufficient code to reproduce the …

Hi, I am using stemwin (version 5.44) on an STM32F429 I am calling Source Code (6 lines) but sadly this triggers an exception handler. Looking at the program counter in the exception frame i see I am in GUI_ALLOC_Free. I have put a breakpoint on the offending asm line and I see i hit this point several times ( 20 -30 ?) with acceptable values, but then he tries to dereference an address 0x6901133C which is an not an existing address on my processor (see screenshot). Can you give me an indication…

Ah thank you, I see in GUI.h "emWin V5.44". How old are these ? I see release notes on segger.com/products/user-interface/emwin/ but there are no dates mentioned. Not sure if there is a way to get recent stemwins given to move to touchgfx from st

Hi, I was just trying to use GUI_BARCODE_Draw in STemWin but it turns out the function is missing (along with GUI_QR_CreateFramed, but GUI_QR_Create exists so I can make the framed variant myself). Was this not licensed by ST or something ? Or was the function renamed at some point and called differently (because it would seem strange that QR codes are supported but not barcodes ?) ? Or maybe another explanation ? Regards, Bram

Ok thank you very much ! (In the meantime I had made a translation layer to reformulate ST7735 commands into SSD2119 ones, but I will change this to the "native" method then)

Hi, I am trying to use the st precompiled stemwin on an stm32f4 but with an SSD2119 controller. This is controller not selectable in the cubemx SW, though SSD1355 is. If I toggle between the SSD1355 and ST7735 (a controller i used successfully in the past with stemwin) there is no difference in generated code so I was hoping I could get away with the SSD2119 Alas, it does not work, and one problem I am aware of so far is that stemwin will try to set up the drawing area using the ST7735 caset, ra…

Hi, I wanted to try the SWO trace functionality in IAR 7 to debug a problem but no matter what I do the SWO Trace window remains very very empty. I have a JLink Pro and the target is an STM32F429. Is this something that should work with that debugger/cpu combination ? In the model overview I see that ETM trace is only available in JTrace but all the SWO features are checked so I was under the impression SWO trace would work. Thanks Bram

So it is as I expected. If I use the 16 bit interface I get the memdev memory area directy in the low level functions without swapping. And I can transmit the bytes in the order so that my raw images have the right colors, but then any drawing actions I do (st)emwin will have the wrong colors. Eg if I fill the screen with red (RGB: 255,0,0), then the memdev memory area contains 1E 00 1 00 1E 00 (etc) resulting in a green screen if i transmit the bytes in that order to the LCD controller. (note: …

Small update: If I use GUIDRV_FLEXCOLOR_M16C0B16 I get pointers directly inside the memdev region so that is nice. There is a lot of tricky stuff going on though to get it right. Eg to set CASET values of the controller in 8 bit mode the following values are transferred : { 0x00, 0x00, 0x00, 0x7F } Now in 16 bit mode, he still transfers this (calling the functions 4 times), instead of only 2 times { 0x0000, 0x007F } This means that in my pfWrite16_A1 function i have to throw away the upper byte …

Quote from Sven: “Actually, I'm the one [img]https://forum.segger.com/wcf/images/smilies/wink.png[/img] I will add a note to the manual. ” Haha, of course, there can be only one. Thanks Now looking at the buffers for my little color problem I see 2 issues: 1. The memdev region (0x6804008c) is NOT passed directly to the low level function, it seems and intermediate 256 byte buffer (0x6804f674) is used. This is hugely unfortunate, given my attempt to do this whole operation without extra (useless)…

I assume in your Task2 if you would have wanted the 1. GUI_GotoXY(0, 0); 2. GUI_DispString("Task2"); to be run on the memdev and not directly on the screen that you would have put a GUI_MEMDEV_Select(hMem); / GUI_MEMDEV_Select(0); around it right ? I have 'guarded' all my functions with these calls now and that seems to work without any further crashes :). Thanks ! (maybe tell the person(s) responsible for the manual to add a note about this in the GUI_MEMDEV_Select documentation ? ) The problem…

Quote from Sven: “Did you unselect the memory device after GUI_Clear() ” Aha, no I did not ! What I do now is : m_hMemDev = GUI_MEMDEV_CreateEx(0,0,DISPLAY_WIDTH_PIXELS,DISPLAY_HEIGHT_PIXELS, GUI_MEMDEV_NOTRANS) GUI_MEMDEV_Select(m_hMemDev); from my initialization thread to setup the memdev. And then the other threads that need to do something with the display would do: - Get the pointer with GUI_MEMDEV_GetDataPtr( m_hMemDev ) and fill the raw memory directly if needed - Do drawing actions like …

Hi Sven, GUI_OS is set to 1. GUI_MAXTASK is not defined. Manual says the default is 4. I have more tasks in my system but I am only calling it from 2 tasks now. The * GUI_X_GetTime() * GUI_X_Delay(int) * GUI_X_InitOS() * GUI_X_GetTaskId() * GUI_X_Lock() * GUI_X_Unlock() * GUI_X_GetTaskId * GUI_X_WaitEvent * GUI_X_SignalEvent functions have an implementation (provided by ST, if you think these may be involved i can go start checking them) I am actually not calling GUI_Exec/GUI_Delay at all at the…

Hi, Based on the discussion in Direct framebuffer access, I started using memdevs. But now I run into an exception during when calling GUI_Clear() when the memdev is active (though it might not be memdev related, so i created new topic). Background: I am using stemwin in a freertos multitasking environment. The memory I give to emwin (and in which the memory buffer is located) is located in external SRAM. IAR linker file: place in ExtSRam_region { block HEAP, section EXT_MEMORY_IF_AVAILABLE }; G…

Hi, Quote: “Unfortunately, not. the hardware routines called by emWin only receive the pure data. ” Yes, but as far as I understand emwin transfers that data to the LCD controller using the GUI_PORT_API.pfWriteM8_A1 function. This function takes a pointer and a number of elements as arguments. And I would expect that this pointer argument points directly inside the cache region ? So if I write (or simulate to write) the entire screen, the lowest address given to me via this callback function wil…

And another realisation: If emwin does now work with a framebuffer, does this mean then when working with a memdev and caching not enabled, a GUI_MEMDEV_CopyToLCD command will do a direct write from the memdev memory area to the display (so no intermediate copy). Because that would be the perfect solution then (I think) ?

And thinking around the box about my getting to my 'ideal' scenario a bit more: does emwin 'leak' the cache location towards the lower level functions ? Eg if i would trigger a write of the entire screen by filling it with a color will he pass a buffer with the start address of the cache to the low level drivers ? And is the location of that cache constant or does it get relocated under certain circumstances. (I understand that this is totally dirty & bad and Segger is not responsible if a black…