the gwin/button demo doesn't work

[yuzhubin]

i have configured my project so it can build and run with ugfx, ai first the gdisp/ demos runs well but the gwin/ demos don't work well i can't see any widget display on my screen, just white background.my ide is keil  i configure the os type to be bare-mental

[Joel Bodenmann]

Did you try to debug the application? Most likely it's hanging or crashing somewhere during initialization.

[inmarket]

Also check the threads demo works.

The Keil compiler is supplied with a buggy C runtime library so make sure you have specified the CPU to uGFX so that it can use the CPU specific threading rather than the C library based one. This C library bug will result in symptoms just as you are describing.

[yuzhubin]

what should i do to specified the CPU to uGFX？i have checked the gfxconf.h and i found  3 options below

  #define GFX_CPU                                  GFX_CPU_UNKNOWN

   #define GFX_CPU_NO_ALIGNMENT_FAULTS              FALSE
   #define GFX_CPU_ENDIAN                           GFX_CPU_ENDIAN_UNKNOWN

 

[yuzhubin]

i checked gfx_compilerr.h and i found cpu options below， but my cpu is Samsung s3c2440， it's a arm9 cpu，i can't found arm9 option， which option should i take？

#define GFX_CPU_UNKNOWN                0        //**< Unknown cpu
    #define GFX_CPU_CORTEX_M0            0x01    //**< Cortex M0
    #define GFX_CPU_CORTEX_M1            0x02    //**< Cortex M1
    #define GFX_CPU_CORTEX_M2            0x03    //**< Cortex M2
    #define GFX_CPU_CORTEX_M3            0x04    //**< Cortex M3
    #define GFX_CPU_CORTEX_M4            0x05    //**< Cortex M4
    #define GFX_CPU_CORTEX_M4_FP        0x06    //**< Cortex M4 with hardware floating point
    #define GFX_CPU_CORTEX_M7            0x07    //**< Cortex M7
    #define GFX_CPU_CORTEX_M7_FP        0x08    //**< Cortex M7 with hardware floating point
    #define GFX_CPU_X86                    0x10    //**< Intel x86
    #define GFX_CPU_X64                    0x11    //**< Intel x64
    #define GFX_CPU_IA64                0x12    //**< Intel Itanium
    #define GFX_CPU_POWERPC32            0x20    //**< PowerPC
    #define GFX_CPU_POWERPC64            0x21    //**< PowerPC
    #define GFX_CPU_SPARC                0x22    //**< Sparc

Edited May 6, 2018 by yuzhubin

[inmarket]

Try either the m7 or m7_fp (fp stands for hardware floating point) first but also make sure you are also compiling as if it was a m7 processor.

The other arm versions can also be tried - the difference between them corresponds to differences in the instruction set of the variants of arm cpu. The corresponding code used is found in the src/gos/gos_x_threads.c etc.

It is likely one of the existing arm CPU specific code options will work for you. If not you may need to add one for the arm9. If an existing one works for you please let us know which one and similarly if you add you own for the arm9 don't forget to contribute the code so other users can benefit too. 

We would attempt to add it ourselves but unfortunately we don't have a board with that chip on it for testing.

[yuzhubin]

i specified the CPU type to be m7 and i modified the gos_x_threads_cortexm347.h file because arm9 is an arm920T V4T cpu , it dosen't support the "blx" instruction so i change that line to be  

mov          lr, pc
bx              r1

and then i builded and run ,  at last , i could see the button show on the screen, but another problem shows, the RTOS(a chinese rtos named rtthread) which uGFX ran on has a "stack overflow" issue immediately,  i set the uGFX thread stack to be 200K Bytes , i think it is big enough for it,  but stiil "stack overflow".  then i comment the whie() part code

    while(1) {
        // Get an Event
//         pe = geventEventWait(&gl, TIME_INFINITE);
// 
//        switch(pe->type) {
//            case GEVENT_GWIN_BUTTON:
//                if (((GEventGWinButton*)pe)->gwin == ghButton1) {
//                    // Our button has been pressed
//                    if (++which >= sizeof(orients)/sizeof(orients[0]))
//                        which = 0;
//
//                    // Setting the orientation during run-time is a bit naughty particularly with
//                    // GWIN windows. In this case however we know that the button is in the top-left
//                    // corner which should translate safely into any orientation.
//                    gdispSetOrientation(orients[which]);
//                    gdispClear(White);
//                    gwinRedrawDisplay(GDISP, FALSE);
//                }
//                break;
//
//            default:
//                break;
//        }
    }

nothing wrong with the RTOS now but i could't see the button too, what happened?

the RTOS's website is https://github.com/RT-Thread/rt-thread it's widely used in china

 

Edited May 6, 2018 by yuzhubin

[yuzhubin]

i try to debug this and i found the program runs into this function

bool_t gfxSemWait(gfxSem *psem, delaytime_t ms) ;

i put a log function at the entry of this function

rt_kprintf("gfxSemWait ok!\n");

and i found the the log showed 4 times

gfxSemWait ok!
gfxSemWait ok!
gfxSemWait ok!
gfxSemWait ok!

and then "stack overflow" again

 

[inmarket]

Don't forget to check the size of the main thread. This is normally done using a linker script or for Keil it is somewhere in the project properties. 2K should be more than enough for most situations.

You may also need to turn off stack checking as uGFX provides non-preemptive threading by manipulating the stack.

However, now that you mention you are using a RTOS, using the bare-metal port is probably not the best approach. Bare metal (raw32) is designed for when there is no RTOS. Your best solution is to provide a gos port for your RTOS eg see rawrtos or freertos or cmsisv2 for examples. Again please contribute your result.

[Joel Bodenmann]

You should also set GFX_COMPILER to GFX_COMPILER_KEIL if you're using Keil.

[yuzhubin]

thanks a lot for reply,  i tried to set GFX_COMPILER to GFX_COMPILER_KEIL  but it didn't work for me. 

and then i turned off stack checking it did work well but i think it's not a good way to turn it off, other threads still need this to ensure safety running.

you mentioned i should see rawrtos or freertos or cmsisv2 for examples then i followed the wiki about using uGFX on freertos,  wrote my program like below

 

static void taskInit(void* pvParameters)
{
    (void)pvParameters;
 
    gfxInit();
}
 
void main(void) {
    // Create the initialization task
    xTaskCreate(taskInit, "Initialization", stackSize, 0, priority, 0);
 
    // Initialize FreeRTOS. This will start the scheduler.
    vTaskStartScheduler();
}

but... still stack overflow with my stack checking on.

what should i do now? i don't know much about mcu arch or Makefile. could you give me a simple to do this?

Edited May 7, 2018 by yuzhubin

[inmarket]

You are misunderstanding. The way the raw32 scheduling works is by playing with the stack. This is incompatible with Keil compiler stack checking by very definition.

If you are however using a RTOS as you explained in your later posts you should not be using raw32 at all. Instead you should be porting gos for your RTOS. Freertos, cmsisv2 and rawrtos are examples of that.

[yuzhubin]

finally my button work out and my RTOS didn't complained，here is my gos_ files for rtthread

 

gos_rtthread.c

gos_rtthread.h