Jump to content

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


slackintosh

Recommended Posts

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.

 

 

 

 

Link to comment
Share on other sites

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 ...

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

  • 2 months later...

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.

Link to comment
Share on other sites

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(..)?

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...