gwinSetText block thread

[remon]

Hi,

My display controller requires me to flush the entire framebuffer to the controller in order to update the display. To limit the consumed resources, I have a low priority thread that will flush once a second. However, when I call the 'gwinSetText' function from a higher priority thread it seems to block until the framebuffer has been flushed. Is there any way to prevent this behaviour?

Edited August 16, 2016 by remon

[inmarket]

Rather than using your own low priority thread to flush the display have you tried using the ugfx flushing mechanism? Of particular interest to you may be the GTIMER based flushing mechanism.

Unfortunately it is not possible for us to debug what sounds like a mutex  contention without actually having your display driver code (including the low priority flushing thread code).

I would suggest to try using the ugfx flushing mechanism first. If you can't use that then provide us with the driver and thread code and we will see what we can do to help.

[remon]

I enabled the 'GDISP_NEED_TIMERFLUSH' option to flush every 500 ms which works fine. However the 'gwinSetText' still blocks the high priority thread until the flush has been performed. Furthermore, I don't see how this problem could be related to the display driver code.

[Joel Bodenmann]

Hi remon!

What underlying system are you using? It sounds like your underlying system doesn't provide a preemptive scheduler. This would for example also be the case with the scheduler that comes as part of the Raw32 port.

[inmarket]

What platform are you running. If you are say running raw32 it is using a cooperative multitasker. This means that once the flush starts no other thread will run until the flush completes.

Also, all drawing operations are mutex protected. As the gwinSetText issues a redraw then depending on your redraw strategy (controlled by gfxconf macros) the actaul redraw of the control and any subsequent flush may occur synchronously. Look carefully at the gwin redraw settings. The defaults are usually the best.

Finally, depending on your operating system, thread priorities might not be implemented at all at the operating system level.

Basically we need a lot more information and an example program (as small as possible) that demonstrates the issue to help you debug further.

[remon]

I'm running freertos 9 as the underlying system.

[Joel Bodenmann]

On 8/17/2016 at 00:44, remon said:

However, when I call the 'gwinSetText' function from a higher priority thread it seems to block until the framebuffer has been flushed.

Does it just "seem" to do that? Because as @inmarket mentioned the behavior depends on the redrawing mode.
Can you confirm (using a debugger, analyzer, tracer, ...) that the thread that takes care of the flushing actually blocks?

Also, we need more information here:

• Are you using the flushing capabilities built into the GDISP module or a custom solution? If custom, why? The built-in stuff uses a GTimer and therefore doesn't create a dedicated thread for flushing. Also, the built-in stuff is supported all the way down to the display driver level.
• If you are using custom stuff, are you creating the threads through the µGFX API? (eg. gfxThreadCreate()).
• Anything else you think would help us to help you...

[Joel Bodenmann]

Furthermore: What display / display controller are you using? Are you 100% sure that you need to flush once every second? That sounds very odd.
Note that µGFX has different redrawing modes and different flushing modes. If you use the flushing stuff built-in the GDISP module, µGFX will take care of when flushes are required and when not. Flushing is part of the driver interface. You still have full control over how flushing happens.

[remon]

Sorry for the late reply, I was busy last week. I do have a debugger, however it doesn't have support for freeRTOS threads, so I can only see the current active thread. I could setup traces to check but this will take some time.

I basically have one high priority thread that is called when data from an accelerometer is available (50 Hz). When the data is received it increments a counter by one and calls gwinSetText to update the value on the screen. Since I don't want the LCD to refresh 50 times a second, I've set the GDISP_NEED_TIMERFLUSH option to 1000ms. However the counter is only incremented once a second, the same rate as the framebuffer flush, indicating that the high priority thread is blocked by the flushing. When I set the flush timer to 500 ms the counter also increments twice as fast.

I'm using the freertos api to create threads not the gfxThreadCreate function, but the GOS also calls the freertos function, so I see no problem here.

[inmarket]

As we said, we are at the point where we need code to help you further.

[remon]

Which part of the code would be helpful to you? The entire project is quite extensive. I've added the display driver code to this post, since you referred to it in a previous post.

gdisp_lld_ST7586S.c

board_ST7586S.h

[inmarket]

It would be useful for you to create a small project (as small as possible) that demonstrates the problem. The issue here is obviously some sort of threading interaction so the important parts are how you are creating your threads and how you are then using them to call your flushing mecanism and the gwinSetText. We don't need all the rest of your code, just a minimal framework to show the problem.