inmarket

Thank-you.

The macros using set_rd and clr_rd are macros for a reason. Those pins may be used within a gdisp hardware abstraction layer file to implement the GDISP reading functionality. If your driver or your hardware implementation does not support reading then those macros are unnecessary and, like the uftf library does, you can tie the physical pin up. With regard to the palSetPad and palClearPad, this refers to the LOGICAL level, not necessarily the physical voltage. Depending on your hardware it may be using negative or open collector logic which would give you the effect you see. Note: there are also some user contributed drivers that actually do get this the wrong way around. I am not sure without digging if the SSD1963 driver is one of those.

Yes this is something that is part of uGFX v3. It is also not quite that simple for all types of displays. You might be working with a display that uses a window based driver, but there are also framebuffer drivers, and other strange types of drivers (like window drivers with positioning, dma etc). There is actually a lot of complexity in just adding that count relating to bounding. At the moment those questions are relatively simple as the calcs are done at the higher layer. When you add the count some of that bounding needs to be moved down a layer, adding to the complexity. This is why this task is in v3. It is at least a major version number update to add that stuff (along with other stuff we wanted in v3).

There are gwin calls that can resize a widget. Try starting there. I am thinking something like: 1. Change the size of the table when you display the console. 2. Change the size back when you hide the console. How you handle this will really depend on what you are doing with your console window and table widget.

uGFX has a VERY simple window manager. It does not currently support overlapping Windows like you are using, as the generic case for that requires some very complex and processor intensive clipping algorithms. It is also an "unbounded" problem in that it may require additional memory allocation that cannot be pre-computed statically. Once the V3 uGFX has been released we can re-examine this as V3 puts significantly better clipping into the GDISP layer. Until then you can either: 1. remove the overlap e.g by reducing the table size while the console is open, or 2. try to detect the situations it is happening and add additional clipping calls to GDISP. The 2nd strategy may not work for you depending on how you are using GWIN so the most promising strategy is probably number 1.

Thank-you very much. We will review and get it integrated asap.

We did look briefly at doing this a few years ago. The difficulty is getting it to work reliably in all situations e.g. with kerning, antialising etc, and with all fonts. The amount of state required was also significant as well as a number of pre-calculations. Given the amount of work to do it properly to work in all circumstances, and at the time we were thinking if we would replace the font engine with a vector based font engine, we decided it wasn't worth the effort. There was plenty of other work that was higher priority. (At the time we were working on the window manager). If you would like to do the work to do this we would certainly appreciate the patches. It is important however that it works with all fonts and font features (such as kerning and antialiasing), and doesn't overrun the specified area by even a single pixel.

There are two links. One about midway down and one at the bottom of the thread. I just tried the one at the bottom of the thread and it seems to work (it downloaded something onto my mobile phone). Give that a try.

I'll have a good look later, but you should atleast remove the gfxSleepMilliseconds call. There is no need for it as the geventEventWait call will do the waiting for you.

It all depends on the display controller. Some display controllers - that is just how they operate. In terms of speed, they can be just as fast as any other mechanism. It really all comes down to bus speed and the type of bus. For some bus types and speeds streaming controllers can be faster than any other type. Try doing framebuffer pixels writes over a slow I2C bus would be terribly slow, a streaming controller and driver can however perform really well. uGFX is pretty unique amongst graphics libraries because it doesn't require direct access to the framebuffer in RAM. It was with this basic tenant that the first version of uGFX was written, and its first hardware controller was a streaming driver.

Thank-you. Nice work. We will add to the standard driver collection as soon as possible.

It sounds like you got the panel working for you in 18bit mode. I am currently using the original code on a Ili9488 in RGB565 mode (16bit) without change. Looking at your photo the board even looks the same! This is a common problem with the Ili series of controllers. Often chips with the same part numbers behave quite differently depending on the source of the chip. Add to that different ways the panel can be attached to the controller, and then the pixel format you want to use for the application, all mean that the initial sequence often needs to be customised. Seemingly identical boards can sometimes behave differently. I even heard of one case of this happening from a single supplier. With regard to the reset function, the gTrue was supposed to mean the reset was asserted (i.e active low for most boards). As there were a number of different programmers who wrote the different drivers, for some drivers that meaning got transposed and the gTrue was taken to mean pin high instead. It looks like the ili9488 driver is one of those. It is something we are fixing for uGFX v3 but can't change for v2 without breaking someone's already working code. Nice job on working it out!

Check your gfxconf.h file. Make sure it is not defining GDISP_PIXELFORMAT

It is more likely it is caused by the sequence of Alloc's and Free's. Another possibility is that there is a buffer overrun problem in the uGFX image code. This is also possible but unlikely as the uGFX image code is very well tested. What strikes me as unusual here is an Alloc of just 2 bytes.

Looks like you might have found a bug with the FreeRTOS memory allocator.