Search Results

Dear friends! I replaced emWin in my project by uGFX. It is nearly free and pretty reliable: community.ugfx.io/topic/422-external-fatfs-use/#comment-3099 And everything works fine. I offer this like workaround of this bug. B.R. Constantine.

I've found the source of error in implementation of re-initialization routine. GUI_Init after GUI_Exit works fine in FreeRTOS environment until you call for block thread function, in case of CMSIS implementation, it will be osDelay(). I tried to apply queue, to remove any blocking routines from thread that handles re-initialization, but it doesn't help. The idea was pretty simple: the first thread sends in queue number of picture to show, the second tread waits for object in queue, if it appears…

Ok. Finally I found RTOSless workaround, I tested it, it works fine. GUI_Init(); GUI_Clear(); uint8_t img_counter = 0; while (1) { /* USER CODE END WHILE */ /* USER CODE BEGIN 3 */ GUI_Exec(); GUI_TOUCH_Exec(); GUI_DispStringAt("GUI mem. free:", 0, 230); GUI_DispStringAt("Img. num.:", 230, 230); Show_img_from_SD("7_300x225_16bpp.bmp"); img_counter++; GUI_DispDecAt((I32) img_counter, 300, 230, 3); GUI_DispDecAt((I32) GUI_ALLOC_GetNumFreeBytes(), 90, 230, 6); HAL_Delay(500); Show_img_from_SD("8_30…

Sven, I think I found workaround. But solution is pretty weak and unstable. Call me, I think we should discuss it before I issue some code. Maybe you can explain some details about emWin RTOS implementation. mob.: 8 965 318 22 82 P.S. Yes I read chapter 17, I think that on present moment I know your manual nearly by heart. Yes I checked GUI_X_OS and GUIConf files. For me it looks normal.

No, Sven. It is not. Yes function is working, but it still consumes memory until whole GUI runs out of it. This is another thread, I have some trouble with ...Ex() functions at the beginning - it breaks at half of picture. I found solution for this trouble. But I can't resolve issue with memory management. And I still can't found workaround, cause couple GUI_Exit -> GUI_Init not working proper under RTOS. B.R. Constantine.

Good morning, everyone. I think I found source of trouble in this thread. Exit-Init couple works great without RTOS and produces hardFault under RTOS. Tried to find-out some errors in RTOS implementation, but for me everything looks right: file GUI_X_OS.c: #include "GUI.h" #include "main.h" #include "cmsis_os.h" static osMutexId osMutex; static osSemaphoreId osSemaphore; int GUI_X_GetTime(void){ return ((int) xTaskGetTickCount()); } void GUI_X_Delay(int ms) { vTaskDelay(ms); } void GUI_X_Init(vo…

Now I'm using my old HP book with Win7, and JLink interface looks good. So, I cann't understand what is the problem to rebild GUI for Win10. It is task for half an hour. B.R. Constantine.

Look diagram in attachment. When task 2 in point 3 interrupts SDIO protocol (as I understand operation is nonAtomic) it dissolves input-output sequence that causes SDIO shut down.

So, finally I've found what the problem in current situation. emWin block resourses by using mutexes. Look for description of functions: GUI_X_Lock() and GUI_X_Unlock() It prevents LCD from double access - some kind of gatekeeping. That is fine. But it doesn't block processes from interrupting by other threads. In case of using LCDs with parallel interface it is not a problem - interface takes data per one tick on 'E' pin and can wait until other process, that interrupt current GUI to LCD transa…

Yes, Sven, as I expected: I add such code like you at the beginning of main: ... some periph init ... LCD_init(); .... while (1) { GUI_Init(); GUI_DispStringAt("GUI mem. used:", 0, 0); GUI_DispDecAt((I32) GUI_ALLOC_GetNumUsedBytes(), 100, 0, 6); GUI_DispStringAt("GUI free mem.:", 0, 10); GUI_DispDecAt((I32) GUI_ALLOC_GetNumUsedBytes(), 100, 10, 6); GUI_Exit(); HAL_Delay(1000); } And it works perfect. It faults only when I trying to reinit GUI after it runs out of memory. So this is clearly the c…

Ok, thanks Sven, I understand. But, on present moment I found some additional details by this issue: When I reduce size of emWin memory from 20kB to 10kB, I can to way through both function GUI_X_Config() and LCD_X_Config() to the end (without trouble with zero pointer), but final result the same - hardFault. Now it halts somewhere in invisible (indebuggable) part of code. So it seems, that it is some kind of continuation of issue with memory management. Now I'm going to try this functions: 1)wi…

Quote from SEGGER - Til: “ST builds the STemWin library on their own based on the latest emWin sources. In general please contact the ST support. But in this case I will try to help you in order to speed up things.” Ok, Til. Now I begin to understand what you are trying to explain me. I'm pretty in-fusible))) So, you said that STM has source code (C + Asm) of your library that they can change. I thought, that STM received complete precompiled libraries from your engineers for every core. This me…

Quote from SEGGER - Schoenen: “How did you created the file? ” I used this converter: easy2convert.com/jpg2bmp/ If it could be the cause of issue I will try to convert it using Photoshop. Our advertisement section has a license.

Hi, Shoenen. This is just three of 15 that I use. All of them I converted from .jpg by myself, so I'm pretty sure that they have 16bpp 300x225. Maybe I should try other sizes or bpp? Main issue in this case will be, that in final PLC I intend to use images with resolution 560x320. I already created GUI for 800x480 display, now I'm debugging some additional functions. It will be very sad for me if I will be forced to use another GUI library. It will bury pretty big piece of my job. I really hope …

I have 5.28 version of emWin library. In its manual I already see description of GUI_Exit() function. And i have such function prototype in 'GUI.h' file. I want to use it for re-initialization process after emWin runs out of memory (another bug in ...Ex() functions): This is my code: if (GUI_ALLOC_GetNumFreeBytes() < 2 * 1024) { taskENTER_CRITICAL(); GUI_Exit(); LCD_reset(); GUI_Init(); //hardfault here, somewhere in hidden part after LCD_X_Config() taskEXIT_CRITICAL(); } But when I try to use i…

Good morning, Shoenen. I tried what you offered yesterday, it doesn't help - please look my implementation.

Else one, Shoen. Could you look my another thread: GUI_Exit() -> GUI_Init() BUG For many engineers in my situation it could be suitable solution to reinit GUI. In any case GUI is not the main part of real-time application. It is possible to have 0.5 sec gap in it. B.R. Constantine.

Dear Til, as I understand you are some kind of licensing specialist. As I see from Shoen's replies there is some bug in some old library. Could you explain how to initialize process of fixing through STM? Should I write them an official letter? Maybe you can initialize this process? Do you provide some fixes for old libraries? How all this works between your companies? So all my questions lead to simple one: how can I receive fixed library not paying any extra money? Cause if my company has to b…

Quote from SEGGER - Schoenen: “We were able to avoid the bug if _acBuffer was big enough to hold one line of the image and the number of bytes read should were equal to the number of bytes required. ” And again, I'm not enginious)) I have BMP with sizes 300x225, 16bpp. So I should create _acBuffer with size exactly 600bytes? Ok. This is pretty clear for me. But! When I debug through _GetData function I noticed that first time, ...Ex() function requires 64 bytes from _GetData. Is it normal? So, t…

Thanks a lot, Shoenen. I looked a lot through your comments, you are always very informative and professional. Can I realize from your comment now, that I should try to increase _acBuffer? And it maybe will lead to proper behaviour of GUI_BMP_DrawEx() function? Does function IMAGE_SetBMPEx() have the same bug? As I can assume both these functions have the similar code? B.R. Constantine.