AJJ

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

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.

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

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.

I am finally updating uGFX from the version that I had downloaded 2 years ago. Per the previous comments I see that you added the following snippet of code to the fillarea(..) and vline_clip(..) functions just prior to calling gdisp_lld_fill_area(..): #if GDISP_HARDWARE_STREAM_POS && GDISP_HARDWARE_STREAM_WRITE if ((g->flags & GDISP_FLG_SCRSTREAM)) { gdisp_lld_write_stop(g); g->flags &= ~GDISP_FLG_SCRSTREAM; } #endif I think that this same piece of code also needs to be added to the hline_clip(..) function prior to calling gdisp_lld_fill_area(..). Without this code in hline_clip(..) my code locks up because it tries to access the bus without re-acquiring after gdisp_lld_fill_area(..) releases it. There are a couple of other calls to gdisp_lld_fill_area(..) such as in gdispGClear(..), but I'm not calling these functions in my own code so I'm not sure if this same problem exists there. Thanks, AJ

In the function hline_clip(..) in gdisp.c, the following code is executed when GDISP_HARDWARE_FILLS is defined: // This is an optimization for the point case. It is only worthwhile however if we // have hardware fills or if we support both hardware pixel drawing and hardware streaming #if GDISP_HARDWARE_FILLS || (GDISP_HARDWARE_DRAWPIXEL && GDISP_HARDWARE_STREAM_WRITE) // Is this a point if (g->p.x == g->p.x1) { drawpixel(g); return; } #endif // Best is hardware accelerated area fill #if GDISP_HARDWARE_FILLS #if GDISP_HARDWARE_FILLS == HARDWARE_AUTODETECT if (gvmt(g)->fill) #endif { g->p.cx = g->p.x1 - g->p.x + 1; g->p.cy = 1; gdisp_lld_fill_area(g); return; } #endif I think the problem that I see is that drawpixel(..) is aware of the GDISP_FLG_SCRSTREAM flag, acquires the bus only if this flag is not set, and does not release the bus. However, the SSD2119 version of gdisp_lld_fill_area(..) (as well as many of the others that I checked) does not seem to be aware of this GDISP_FLG_SCRSTREAM flag, always acquires the bus and always releases the bus. So if this hline_clip(..) function is being called in a loop, as it is when drawing text, then depending on the order of single pixels vs. areas drawn we can mismanage the bus ownership. For instance, if we draw a single pixel and then an area, we will try to acquire the bus twice in a row, then perform a single release. Then if we draw another single pixel the GDISP_FLG_SCRSTREAM flag is already set and we attempt to access the bus without a first acquiring it. Have I misunderstood the intent of the acquire_bus(..) and release_bus(..) functions and they are supposed to implement reference counting?

After some more looking at the code I think I understand that the GDISP_FLG_SCRSTREAM flag is meant to indicate that the bus is being held open and eventually autoflush(..) is supposed to release the bus. However, in my code I'm somehow getting into the drawpixel(..) function without owning the bus but the GDISP_FLG_SCRSTREAM is already set. So let me dig some more and I'll post an update once I've figured it out.

In the drawpixel(..) function in gdisp.c starting at line 127 there is the following section: It seems to me that this code is missing calls to acquire and release the bus around the gdisp_lld_write_xxx(..) functions. The setglobalwindow(..) does call gdisp_lld_write_start(..), which acquires the bus, but setglobalwindow(..) is not always called. And of course there isn't anything to release the bus.

Do you agree that because of this issue multi-line text is not vertically centered in a label? This has been my experience and the above change fixed it for me. But I'm new to uGFX and it's very possible that I'm doing something else wrong.

Are you saying that font->height and font->line_height are the same thing? When I look at DejaVuSans16 for instance they are initialized to 17 and 19, respectively.

Regarding the default situation where text is vertically centered within the label widget, I'm not sure that it works properly when displaying a string with multiple lines using a font where 'height' is different from 'line_height'. At line 3551 of gdisp.c the code calculates the total height as the number of lines times the font->height. Shouldn't this total height instead be something like the following? totalHeight = font->height + ((#lines-1) * font->line_height);