No, I checked my user folder, there should be no that user.
Posts by kenmux
-
-
-
Hello,
I found SES 7.32 cannot import this demo project for iMX7S M4.
No project files created.
Any ideas?Qi,
Regards. -
Hi Sven,
Yes, it has. Okay, I see.
Thanks for your reply.Regards,
Kenmux -
Hi,
These days I try to draw custom 8-bit bitmap with alpha using GUI_DrawBitmap(), but it seems NG.
The image (with alpha) is some like:
To save ROM space, i index the pixel data to 8-bit c file from the one converted by BmpCvt.exe, with the settings:
C
Display Morestatic GUI_CONST_STORAGE GUI_LOGPALETTE _Paloverlay_image_status_26x26x8 = { 232, // Number of entries 1, // Has transparency &_Colorsoverlay_image_status_26x26x8[0] }; GUI_CONST_STORAGE GUI_BITMAP bmoverlay_image_status_26x26x8 = { 26, // xSize 26, // ySize 26, // BytesPerLine 8, // BitsPerPixel _acoverlay_image_status_26x26x8, // Pointer to picture data &_Paloverlay_image_status_26x26x8, // Pointer to palette };
Also, I attached the file as "overlay_image_status_26x26x8.zip".
Then I draw it using the code:
CodeGUI_SetClipRect(&DrawRect); GUI_DrawBitmap(pBitmap, LeftRect.x0, LeftRect.y0); GUI_SetClipRect(NULL);
The screenshot:
It seems just a bit "dirty".
So, what's wrong?
Am I doing something wrong?
My emWin version is v5.48j.Regards,
Kenmux -
Hi Sven,
Okay, I see. Thanks for your work though.
Regards,
Kenmux -
Hi Sven,
It's MIMXRT1052.
The project is built with Keil μVision5.Attached is the code for config MPU.
Thanks,
Kenmux -
Hi Sven,
I check the project over and over again and still the same story.
For I step into this issue using the source codes, so it should not be the library.If I set ITCM read write to MPU, then the code runs well.
(Yes, this bad memory access occurred, too.)For the address of ITCM start from 0x00000000, and we decide to put crucial code to it.
So this issue makes the code crashing from the very beginning.Attached's the config file & OS specific file.
I've removed the file header for the license info.I also check the two tasks: system tick task, background task, and they're running well.
Before the function GUI_SelectLayer() being called, the two tasks run several times.So what should be the problem? Any ideas?
Thanks,
Kenmux -
Hi Sven,
Today I step into the vary functions.
First, the values in the struct pointed by GUI_pContext seems okay after first initial:
But, after calling GUI_LOCK() in the function GUI_SelectLayer() all cleared to 0:
by this:
It seems a context switching occurred.
Then this pointer GUI_pContext->LCD_pColorIndex (its value is 0) is dereferenced. -
Hello,
Recently, I encountered an annoying issue causing freezing.
It seems like dereferencing a null pointer.
Please refer to the image below:It appears to happen in a call to LCD_INIT->GUI_SelectLayer->GUI_SelectLCD->LCD_UpdateColorIndices->LCD_SetColorIndex.
Within that function r1 is loaded from a location with an offset of 0x3C, so probably a structure member.
The content is loaded in r1, but is zero. The next instruction (see yellow arrow) stores r0 back to location zero and thus overwriting the initial stackpointer.I checked the soruce code:
C: LCD.cvoid LCD_SetColorIndex(unsigned PixelIndex) { if (GUI_pContext->DrawMode & LCD_DRAWMODE_REV) { LCD__SetBkColorIndex(PixelIndex); } else { LCD__SetColorIndex(PixelIndex); } }
C: GUI_Private.h#define LCD__SetBkColorIndex(Index) (*GUI_pContext->LCD_pBkColorIndex = Index) #define LCD__SetColorIndex(Index) (*GUI_pContext->LCD_pColorIndex = Index) #define LCD__GetBkColorIndex() (*GUI_pContext->LCD_pBkColorIndex) #define LCD__GetColorIndex() (*GUI_pContext->LCD_pColorIndex)
From the image, you can get that: the value of GUI_pContext->LCD_pColorIndex is null!
So, any solutions? Please save me!My project using:
1) i.MX RT1050
2) KEIL RTX OS2
3) emWin v5.48jPS:
To catch this, I set ITCM read only to MPU.Thanks,
Kenmux -
Okay, got it.
I'm not sure about it.
I'll change the macro value as you post.
Thanks for your reply, Sven. -
Okay, I see, thanks for your reply.
As our product is shipping soon.
It's impossible to upgrade emWin. -
Hello,
Today I work with the issue about MULTIEDIT cannot display the "!" and """. Here's my finding:
The MULTIEDIT is told to display "!" or """ from the key buffer after calling GUI_StoreKeyMsg().
There is a conflict, as the ASCII code of "!" is 0x21 (aka 33), which is the same value as the functional key "PGUP";
also, the ASCII code of """ is 0x22 (aka 34), which is the same value as the functional key "PGDOWN":
Now in my project the handling for GUI_KEY_PGUP and GUI_KEY_PGDOWN are removed as a work round.
So, is there a solution to the conflict?My emWin version is v5.44b.
Any idea is welcome!
Thanks in advance!Regards,
Kenmux -
Hello Sven,
Awesome! Thanks for your reply!
-
I implemented list-wrap by myself at last.
I cannot find a better way to solve this problem.
Appreciate any solutions. -
Very, very embarrassed, at last I found the point: calling this function before calling GUI_Init()...
-
Hello,
The system locks up (Data Abort) after calling GUI_UC_SetEncodeNone().
I checked the source code, and found nothing could be the problem.Anybody ran into this issue? Kindly please share the solution?
I use FreeRTOS v9.0.0, and emWin 5.44.Thanks in advance!
-
Update: the error message is gone if not calling LISTBOX_EnableWrapMode().
But actually it is needed.
So, what should I do to eliminate this error?
My emWin version is: v5.44b, using FreeRTOS. -
Today I set GUI_DEBUG_LEVEL as 3, and implement the function GUI_X_ErrorOut().
And I found calling WM_DeleteWindow(_hListbox) causes an error message:
GUI_Alloc.c:Block to be deleted is already locked in _Free().
Why this came out? Any ideas?
By the way, I used LISTBOX_SetOwnerDraw(). -
Hello Sven,
Yes, you're right. That can do the job.
But, there's no callback for WM_HBKWIN at all.
To be honest, there're only lots of functions calling graphic APIs.
And they do not need redraw.I tried the steps:
1) GUI_EndDialog()
2) WM_MULTIBUF_Enable(OFF)
3) WM_DisableMemdev(WM_HBKWIN)
4) Make sure iMX 7 eLCDIF using the buffer emWin drawing to
5) Terminate task of main UI
6) Task of test UI running
7) The drawing of first calling of graphic APIs causes errorTo the point, a simple question:
How to let emWin be the status just after calling GUI_Init(), without calling GUI_Exit()+GUI_Init()?Best regards,
Kenmux