Posts by SEGGER - Schoenen

    Hi,

    I have to agree the description in the manual is not correct.

    To run the examples try the following:

    1. Exclude any files found in the "Application" folder of the VS Solution Explorer.
    - Expand the "Application" folder, mark all files in it and right click on them
    - Select "Properties"
    - Under "General" set "Exclude From Build" to "yes"
    - Of course, you can also delete all files found in the "Application" folder

    2. Add the example you want to run
    - Navigate to "SeggerEval_WIN32_MSVC_GUI_V<VersionNumber>\Sample\Application\"
    - Drag'n'drop the example into the VS Solution Explorer to add the example to the project
    - If the example is in a sub directory (e.g."GUI_NormalMapping_480x272") you also have to replace the file LCDConf.c. Simply exclude the original one as described under "1." and add the one from the example.
    - You can also add examples via the "VS Solution Explorer" by right clicking on a folder (e.g. "Application" ), select "Add -> Existing Item..." and adding the desired example files.

    You will find further examples under the following two links:

    https://wiki.segger.com/emWin_Examples
    https://www.segger.com/products/user-…nology/samples/

    I hope my explanation helped.

    Regards,
    Sven

    Hi,

    I can imagine that the AppWizard version doesn't match the emWin version in your hardware project.

    Are you using the same AppWizard version as your colleague?

    If you are using a newer tool you have to make sure you are also using the matching emWin libraries on your hardware.

    Here you will find out how to check if the emWin and AppWizard version match each other.

    https://www.segger.com/doc/UM03003_Ap…pWizard_version

    You can get access to the correct libraries by clicking "Export libraries" in the "File" menu (seen on the screenshot).

    Currently the AppWizard comes only with GCC libraries for Cortex-M4/M7 and CCRX V2 and V3 libraries.

    Does this solve the issue?

    Regards,
    Sven

    Hi,

    I think turning on/off the backlight is the best approach.

    You can react on the command LCD_X_ON / LCD_X_OFF in the display driver callback function LCD_X_DisplayDriver(). Similar to this:


    GUI_Init() will send LCD_X_ON command after the controller has been initialized (LCD_X_INITCONTROLLER) and the screen has been cleared with black.

    You can use also the functions LCD_On() and LCD_Off() to send the on/off commands to the callback function.

    Regards,
    Sven

    Hi,

    You can use any AppWizard version which matches your emWin version. I'd use the NXP rather than the one from our website (trial). The one from NXP should match the emWin version and shouldn't bother you with any licensing information.

    If you are using an emWin version which is not supported by the AppWizard provided by NXP you can use the one from our website.

    Here is a description how to check for the proper version:
    https://www.segger.com/doc/UM03003_Ap…pWizard_version

    Regards,
    Sven

    Hi,

    It is not possible to use the RA8876 directly with emWin. You would need another controller which generates the proper signals for the RA8876.

    Typically a display controller build in to the MCU is used to generate these signals.

    In this case you would utilize the GUIDRV_Lin driver to manage the framebuffer on MCU side. The internal display controller will parse the framebuffer and generate the signals for the RA8876.

    Regards,
    Sven

    Hi,


    Since mid of the year we (SEGGER) are hosting and building the STemWin libraries.


    These are not the same as those from the ST Cube packages.


    v6m, v7m, v7em: stands for the architecture.
    fpv4_sp_d16_hard: compiled with support for FPU
    fpv4_sp_d16_soft: compiled with support for FPU but with software ABI
    OS1/OS0: with or without OS support


    Just use the library which fits best to your hardware.


    We will regularly update the libraries found on the STemWin page. So we can make sure the STM32 users have access to the latest (or at least a more recent) version of emWin.


    https://www.segger.com/products/user-…mwin-for-stm32/


    Best regards,
    Sven

    Hello Jan,

    Which device are you using and which emWin driver?

    It looks a bit like as if the data where not entirely written into the framebuffer but reside in the CPU cache.

    For example, on STM32 devices devices we call SCB_CleanInvalidateDCache() before any DMA2D operation to ensure the data is properly written into the RAM.

    Best regards,
    Sven

    Hello,

    You can try the following.

    - Select an object in the hierarchic tree
    - Hold the ALT key on the keyboard
    - Drag the object in the editor window with your mouse

    Alternatively you can select the object in the hierarchic tree and modify its position by editing its properties in the the properties window on the right hand side.

    Regards,
    Sven

    Hi,

    Unfortunately, there is no dedicated API function to copy an entire dialog into a memory device.

    But, you can create a memory device with the same size as the dialog at the same position and copy the LCD content into the memory device.

    This might look like this:

    C
    xPos  = WM_GetWindowOrgX (pMsg->hWin);
    yPos  = WM_GetWindowOrgY (pMsg->hWin);
    xSize = WM_GetWindowSizeX(pMsg->hWin);
    ySize = WM_GetWindowSizeY(pMsg->hWin);
    hMem = GUI_MEMDEV_Create(xPos, yPos, xSize, ySize);
    GUI_MEMDEV_CopyFromLCD(hMem);

    Attached is an example doing this.

    Regards,
    Sven

    Hi,

    I guess you have already a solution, but I'll post it just in case other people have a similar problem.

    Here is the code showing how to hook into the drawing process of the GRAPH widget and fill the area under the GRAPH. You might want to improve it by searching the largest rectangular area under the GRAPH and fill it with GUI_FillRect() instead of line by line.

    You can use the switch USE_PUNCH_OUT_DEVICE fill the the area with a gradient.

    Best regards,
    Sven

    Hi,

    You can change the bitmap by triggering the SETBITMAP job.

    To do so you have to set up a APPW_PARA_ITEM structure with the desired information and call APPW_DoJob(). This might look like this:

    C
    aPara[0].v = 0;                                                    // - Index
      aPara[1].p = (_Switch) ? acBitmap2_30x30 : acBitmap_30x30;         // - INT: Pointer to Image-Data / EXT: Pointer to Image-Filename (EXT)
      aPara[1].v = 0;                                                    // - 0 (INT) / 1 (EXT)
      aPara[2].v = aSizeOfBm[_Switch];                                   // - FileSize
      APPW_DoJob(ID_SCREEN_00, ID_IMAGE_00, APPW_JOB_SETBITMAP, aPara);

    You will find a description of the parameter either in AppWizard.h or in the manual under the job description:
    https://www.segger.com/doc/UM03003_Ap…ml#List_of_jobs

    Attached is an example which changes the bitmaps on a timer event. Check out ID_SCREEN_00_Slots.c regarding the code.


    Best regards,
    Sven

    Hi,

    With the default skin of the BUTTON widget the functions BUTTON_SetBkColor() and BUTTON_SetTextColor() are not working. Either set the classic skin or use SKINFLEX properties to change properties like colors.

    If you overwrite the callback function of a widget you can call the default callback function (e.g BUTTON_Callback()) and then draw something.

    Here is a brief example how this could be done:


    Best regards,
    Sven

    Hi,


    Does emWIN work with the GC9A01 Driver?


    Never had one of these controllers on my desk, but according to the data sheet it should work.

    It seems the commands of the GC9A01 are compatible with GUIDRV_FLEXCOLOR_F66709 and GUIDRV_FLEXCOLOR_F66720.

    GUIDRV_FLEXCOLOR_M16C1B8 should be correct, too.

    A cache is required, as there are no read operations possible (you already figured this out).

    I'm not entirely sure how it behaves with read functions being set. So, maybe you have to set a couple of dummy functions which simply return 0.

    Regards,
    Sven

    Hi,

    You have to link the "GUI-memory" into the SDRAM. How this is done depends our your linker.


    emWin will allocate memory only from the block set with GUI_ALLOC_AssignMemory().


    Here is an example from a GUIConf.c which does it.



    If you are using the GUIDRV_Lin driver you might also want to link the frame buffer to the external memory. This is most likely done the same way as with the "GUI-memory".

    Regards
    Sven