соме adjustments if someone wants to use uGFX-2.9 with ESP32 Xtensa rtos variant

[slackintosh]

Xtensa have had made some changes in the freertos for ESP32 . If someone is interested in uGFX-2.9 for ESP32 they should make an correction to the graphics library tree.

There are a few minor changes in the:

src/gos/gos_freertos.h

src/gqueue/gqueue.c

src/gqueue/gqueue.h

to enable ugfx window manager.

how we can discuss this and whether it is of interest ... cheers gents.

 

 

 

 

[Joel Bodenmann]

Ideally you'd provide us with a patch file (eg. by running git diff). This way we can look at the changes you propose and review them.
If for whatever reason that is not an option you can also send us the modified files and we will generate the patch file ourselves.

[slackintosh]

my suggestion for the fix ...

0001-WT32-SC01-Fix-for-the-xtensa-include-freertos-portma.patch

[Joel Bodenmann]

Thank you for sharing - we will review this in the next couple of days.

Just to be sure here: Those modifications, are they to support a newer version of FreeRTOS or is the FreeRTOS used on the ESP32 modified by Espressif themselves? If so, I'd wonder why.

[slackintosh]

Hi, as I see it .... the mods are related to FreeRTOS used on ESP32, modified by Espressif.

[slackintosh]

here is the Xtensa definition:

// ------------------ Critical Sections --------------------

void __attribute__((optimize("-O3"))) vPortEnterCritical(portMUX_TYPE *mux)

...

here is the regular/original rtos definition:

// ------------------ Critical Sections --------------------

void vPortEnterCritical(void)

...

hope this helps ...

[Joel Bodenmann]

Thank you for all the information you provided.

We're still discussing this internally. Personally, I have no idea why anybody would do this but I guess it is what it is.
We'll most likely not have a choice other than providing a dedicated GOS port (µGFX operating system abstraction) for this modified version of FreeRTOS...

[slackintosh]

hi gents,

you could fix these minor issues if you cover them below the definition of "CONFIG_IDF_TARGET_ESP32", which is seen/visible when someone integrates uGFX into Espressif source three ... if you consider it necessary, of course ... cheers ....

[Joel Bodenmann]

Hey!

Yeah that is indeed one possibility. However, right now we're more tending towards creating a dedicated port for the ESP32 FreeRTOS version. The reason is maintenance. When someone (in this case Espressif) is willing to modify something like FreeRTOS it's not unlikely that other changes can follow in the future. Furthermore, it's not unlikely that we want to update the µGFX FreeRTOS port to support newer FreeRTOS version in the future while the ESP32 modified version might not have been updated by Espressif.
Having a dedicated port just makes this a lot easier to maintain.

In case you want to help on that effort: inside the /src/gos folder the existing FreeRTOS port can be copied, renamed to freertos_esp32.[ch] and modified for this version. There are a few more bits & pieces that need to be modified (eg. new configuration macro to use this GOS port, adding it to the GOS port list and so on).

[slackintosh]

of course ... I can try ...

[AJJ]

I also need to get uGFX working on an ESP32, I found this post and was wondering if there has been any more progress on the items described above?  If not then I'll just try to take the patch file attached above and see if I can make it work.

[Joel Bodenmann]

As of today, we did not commit any changes for this. Therefore, it's best that you apply the patch yourself.
We're still planning to create a dedicated port for this but it's not there yet.

[AJJ]

Thanks.  I've been able to merge in the patch from above and can get everything to build and run, though I am struggling with panic aborts that (so far) appear to be related to multithreading.  I was previously using uGFX on bare metal (TI CC3220), so I think there's a learning curve here for me using Espressif / FreeRTOS.

@slackintosh - Were you able to get uGFX running on your ESP32?  How did you end up structuring the initialization of uGFX?  FreeRTOS - uGFX Wiki doesn't seem to directly apply since on the ESP32 the underlying framework has already called vTaskStartScheduler() before entering the app_main(..) where the user code finally gets control.  Have you implemented uGfxMain(..) or have you defined GFX_OS_NO_INIT and simply kept all of your code in the main thread under app_main(..)?

[Joel Bodenmann]

14 hours ago, AJJ said:

though I am struggling with panic aborts that (so far) appear to be related to multithreading.

From the µGFX side of things: When using the public GDISP API (and therefore also the GWIN API), be sure to set GDISP_NEED_MULTITHREAD to GFXON in your config file.

Other than that: Are you able to spawn multiple threads in the ESP32-modified-FreeRTOS version and things work as expected? i.e. is the problem specific to when you start using µGFX or are you already experiencing issues prior to that?

[AJJ]

Thanks Joel.  I discovered that the ESP32 version of FreeRTOS has its tick frequency set to 100 Hz by default, which then makes portTICK_PERIOD_MS = 10, and as a result any call to gfxMillisecondsToTicks(..) with a value less than 10 returns 0.  This was causing all sorts of things to blow up in odd ways -- initially I only had my display driver enabled in uGFX and I was seeing crashes with what looked like buffer overruns or memory corruption.  It was only after I tried also enabling my touch driver that GTimerThreadHandler began crashing because ticks2ms = 0, and I finally figured it out.  I used the ESP-IDF MenuConfig tool to increase the FreeRTOS tick frequency to 1000 Hz and now it seems that uGFX is once again behaving like I'm used to seeing.

I would suggest adding either an assert or minimum value to ticks2ms in _gtimerInit(..) to prevent this from tripping others in the future.

[Joel Bodenmann]

Glad to hear that you got it working!

 

1 hour ago, AJJ said:

I would suggest adding either an assert or minimum value to ticks2ms in _gtimerInit(..) to prevent this from tripping others in the future.

Things like that are not as easy / as straight-forward as they might seem at first. For example, if the underlying system is configured to run in tickless mode, things start to look very different already. We try our best to add rules, checks and so on wherever sensible within the µGFX library but everything that is interface related, especially the port to the underlying OS (if any) is not easy to sanity check in a generic manner.
After all, this is embedded. It's very easy to shoot yourself in the food and hard to prevent that without bloating everything or limiting use case scenarios.

[AJJ]

I understand -- I'm sure you know a lot more than me about the multitude of configurations that uGFX needs to support.

[Joel Bodenmann]

We don't know everything and we're always open for suggestions

[slackintosh]

hello gents,

AJJ: I'm glad you're making progress. I can send the configuration or whatever if you need.

Enjoy esp32 with uGFX on top