experimenting with WM (bad) and 2D API (good)

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • experimenting with WM (bad) and 2D API (good)

    For the last 3 weeks I tried to learn how to use emWin, using STM32F4 with 8 MB external ram.

    The project uses FreeRTOS and organized in a way that all sources can be compiled with Visual studio, emWin simulation , and an Arduino board connected to the Ethernet, and using UDP simulates all I/Os.

    The same project can be compiled to the target system, using real I/O, and touch screen driver.

    The touch screen driver uses emWin functions activate, measure and GU_TOUCH_Exec.

    I wrote several versions of simple windows that have buttons, and these buttons should create or show other windows dialog, all my testing run quite well on the PC simulation.
    Whoever, using the same code on the target, it was very unstable, a button stayed in the press state (changed color) even when it was not pressed (an led on the target is indicating the pressed state, without emptying the PID fifo), dialog were not displayed, but react to the not-shown buttons (that is, I know that there is a button under the display I see, so I touch it, and the event is fired), dialog were displayed many seconds after the button clicked, and so on.

    As said, on the PC simulation, all was working as expected.

    I didn't think the the main GUI task and the touch Screen task need to be synchronized, but in order to be sure, I used mutex to make sure that these tasks will not interfere each other, with same results.

    So I gave up WM, and tried using only the 2d GUI, finding which object is touch and calling my own functions. To my surprise, this worked very well. the behavior on the PC and on the target is exactly the same (apart for some slower drawing of jpg images).

    I run ram tests many times with many patterns, ram is OK.
    So I am very confused, as the 2D api implementation works fine, I assume that my hardware is OK, I also conclude that the touch screen driver is OK.

    I would like to use WM and widgets of course, and I also assume that this is a well debugged library.

    So my conclusion is that I don't understand something basic about the way to make use of WM, but have no clue what I am missing.

    Will appreciate any comments, in particular, from anybody who used WM successfully on STM32F429 with ST emWIn lib version 5.26

    Thanks
    Johanan
  • I think I solved the problem with WM.
    The solution was to make sure that any changes in the touch screen are not lost due to OS issues. So on every change in the touch panel, a msg is sent to the gui task. the gui task waits for ts msg for 20 ms, then calls GUI_Exec. if a ts mas is triggered, the msg contains x and y position, it sets xops and ypos for X and y measure, then calls GUI_TOUCH_EXE two times, and continues to gui_exe.

    the code looks like this:

    C Source Code

    1. int xpos_ = 0,ypos_ = 0;
    2. int GUI_TOUCH_X_MeasureX(void) {
    3. return xpos_;
    4. }
    5. int GUI_TOUCH_X_MeasureY(void) {
    6. return ypos_;
    7. }
    8. void GUI_Task(void * argument) {
    9. /// do init staff
    10. // ...
    11. // ...
    12. for(;;)
    13. {
    14. // do gui related processing
    15. // ..
    16. // ..
    17. // ---------------- tuoch screen msg processisng -----------
    18. if( xQueueReceive( tsque, &tsMsg, 20 ) == pdPASS ) // wait 20 ms max for ts event
    19. {
    20. xpos_ = tsMsg.x; // set value for GUI_TOUCH_X_MeasureX
    21. ypos_ = tsMsg.y; // set value for GUI_TOUCH_X_MeasureY
    22. GUI_TOUCH_Exec(); // get x
    23. GUI_TOUCH_Exec(); // get y
    24. i = GUI_PID_IsPressed();
    25. if (i >0)
    26. BSP_LED_On (LED3);
    27. else
    28. BSP_LED_Off (LED3);
    29. }
    30. GUI_Exec();
    31. }
    32. }
    Display All