freertos and ugfx

[Waylander]

I'm having strange issue while trying to use ugfx with freertos. In prev forum post i've asked about ugfx and shared pins and i got this issue. But i thought it was because of wrong driver code (i'm using custom disp and touch drivers), but as i understood now, it is because of freertos.

I just took the freertos config from the demo project that i've downloaded from this site and it changed the output of my project. Previously it was not outputting the text in calibration screen, an with other freertos config, it outputs "Calibrati" and top of "o".

I totally do not understand what is going on. Moreover my display behaves strangely, it is not possible to reflash MCU more then once (i need to constantly power off the lcd and reconnect MCU to st-link and only then power on the lcd) and sometimes it outputs noise and artefacts. It is totally not because of malfunction lcd or mcu, while i currently also studying another graphic lib and it works flawlessly (i even managed to get touch working there). Seems like i'm using ugfx in the wrong way, but i don't know where to look for.

BTW: current touch driver is empty and does not influence the bus.

Edited February 27, 2018 by Waylander

[Waylander]

I've viewed other posts and it seems like we have similar issues. May be even because of stack or heap. Is 20kb RAM enough for ugfx using gdisp, gwin, widgets and touch?

Edited February 27, 2018 by Waylander

[Waylander]

When i've set GFX_EMULATE_MALLOC there appeared only a part of "C". Changing heap and stack size in gfxconf.h makes no difference tho.

Edited February 27, 2018 by Waylander

[Joel Bodenmann]

Did you make sure that you're using the latest version of the µGFX library? When you go through the changelog you'll find that there has been a major FreeRTOS port rework at some point. Ever since then the FreeRTOS port is known to work extremely well and is well used & tested.

[Waylander]

Hi, i'm using 2.8 release, that is located in download section. It is said in its release notes that it has that reworked freertos support. May be i'd better downgrade then?

[Joel Bodenmann]

I wouldn't recommend that. As mentioned the FreeRTOS port that comes with v2.8 is well used by dozens of commercial customers, hundreds of makers and multiple universities. Of course there can always be bugs, but what you describe doesn't sound like a core port bug to me.

20kB stack is enough to do all the GDISP, GWIN and GINPUT stuff. But of course this heavily depends on what you do. If you're decoding a PNG image or if you keep stuff cached that obviously isn't enough. However, that shouldn't be an issue here anyway as you're not supposed to make any calls to the µGFX API prior to calling gfxInit() and the calibration is called by that init function.

Could you provide us with a picture of the display? From what I'm reading I suspect an issue with the interface to the display controller or a wrong display controller initialization code.

I would also highly recommend you to run the /demos/modules/gos demo(s) to check if your FreeRTOS stuff is working properly. Those demos don't use any display stuff.

 

[Waylander]

lol. while i was tinkering with stack and heap sizes of freertos and ugfx and linker script, i 'fixed' everything. the thing was that i was still calling calibration manually, while START_RAW was already disabled, and that produced incomplete output (but why tho?). when i've noticed it, i've commented out the manual call and SAW THAT CROSS!!! touch driver is still empty, so i can't press it for now. will write here later.

anyways, thanks for a tip in another post where you've written about stackoverflows.

btw may be you can suggest some values for stack and heap? i'm not going to use images. Just flat gui (but complex tho).

[Joel Bodenmann]

Glad to hear that you managed to get it working

 

11 minutes ago, Waylander said:

anyways, thanks for a tip in another post where you've written about stackoverflows.

I sense a bit of negativity in there - we're not trying to blame stack overflows for everything, but they are an extremely common issue that result in exactly that kind of behavior. However, stack overflows and concurrency issues often lead to very similar results. Also, I mentioned that I don't think that that's the problem in this case  

 

13 minutes ago, Waylander said:

btw may be you can suggest some values for stack and heap? i'm not going to use images. Just flat gui (but complex tho).

That's really difficult to do. 20k definitely sounds like fair amount of RAM then. Depending on what you're actually doing you can get way lower that that. We've systems that run with 5 kB or RAM and they do fancy-looking stuff.
Usually you just start off with a very large number and once you're happy with your GUI you start making it smaller and smaller until shit hits the fan. Then you usually add a margin of 10 to 20% depending on the application. But keep in mind that that's a very "unsafe" approach as GUI memory usage often heavily depends on the user interactions. So while it might be enough for you and me it might still blow up if some dude starts pressing all the buttons at once or something  

[Waylander]

now i was trying to figure out what setting actually fixed the issue and strangely they aren't concerned ugfx ones. they are from freertos config:

configUSE_IDLE_HOOK                0

configUSE_TRACE_FACILITY        1

configQUEUE_REGISTRY_SIZE        4

very strange! everything in linker script and in ugfx, all the heaps and stacks are default!

But with those settings i get that holy cross on the screen, lol. Haven't checked yet whether touch works.

Edited February 27, 2018 by Waylander

[Waylander]

well, i'm again stuck with conflicting display and touch driver. but now at least i  know that when i remove

	while (xSemaphoreTake(lcdBusMutex, MUTEX_DELAY) != pdTRUE) {
		gfxYield();
	}

from code, it works (text and cross is visible). but if i get the actual code for input driver back, it prevents calibration screen to be fully drawn (top of display is filled with blue color and there is part of "Calibration" text), because touch driver uses same pins as display driver.

but how do i use mutex right here? i've tried without gfxYield() (do i need it at all?) and it made no difference.. the code releases the mutex when job is done. but why text and crosses aren't drawn, after the screen is filled blue?

[inmarket]

There are really only four possibilities...

1. The FreeRTOS semaphore functions aren't working properly. To ensure its not a coding error try using the gfxMutex object and calls instead. That way you can also remove the loop, just use the mutex enter and exit calls with no timeout.

2. A bus_release is not being called when it should be effectively causing the bus to remain locked thus preventing drawing.

3. There is a call to the hardware that is not surrounded by the mutex and that is causing contention.

4. You are suitably protecting the bus however you aren't getting the chip selects etc correct. Eg if the display and touch chip selects somehow both end up set or unset simultaneously. It could also be a chip select timing issue.

[Waylander]

thanks for the tip! never thought that there is built-in mutex wrapper in ugfx.

But i don't understand how to use it. For example i have two drivers in separate .c files. In which there are lots of functions and also in each there are aquire_bus and release_bus functions. So i just need to place gfxMutexEnter and gfxMutexExit calls accordingly (and gfxMutexInit somewhere in init code of main.c)? And that's all? Code after gfxMutexEnter will be suspended until mutex is available? No timeouts, no loops?

[inmarket]

Yep. Exactly correct. Much easier to use than a FreeRTOS semaphore.