inmarket

It has been a long time since I looked at the code but... It should be possible to retest the visibility flag in the invisible loop. If the window is now visible don't redraw it because it will get redrawn later.

Looking at the video, whenever you swap screens (using either button) it is doing the double drawing. It is much more visible with the tab with the list because font drawing is relatively slow, but it is also happening when you switch to the button screen. uGFX's window manager is really dumb because the drawing engine doesn't support multiple clip areas, which means it struggles with overlapping Windows. That can often lead to double draw operations. The reason the tab control doesn't have this issue is because the control code itself understands exactly how the tab pages overlap and therefore optimises its drawing for that Check if when you are switching between the tab window and the button window that you are hiding the old window before making the new window visible so that there is only one visible full screen page at any time. I hope that helps

Yes, the existing keyboard action for backspace is not multi-byte language aware. If someone would like to submit a patch to make it utf-8 aware, that would be great.

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.

In this case it is the LTDC peripheral that is doing the pixel conversion and layer mixing I talked about in my earlier post. While the LTDC does not support RGB666 DPI it does support RGB888. You can connect that to a RGB666 panel by simply not connecting the two lowest bits of each colour byte. So, You can use RGB565 as the CPU and framebuffer pixel format for a layer, and then you program the LTDC to take that RGB565 pixel data and convert it to the RGB888 output DPI bus. That RGB888 DPI bus you then connect to RGB666 panel by ignoring the bottom 2 bits of each colour on the DPI bus. So, uGFX works and is programmed around the chosen framebuffer pixel format - not the DPI bus format. The LTDC converts that framebuffer pixel format on the fly to your RGB888 DPI bus. Note: when you have 2 layers they can be in different framebuffer formats. uGFX then may have a "system" pixel format and two different display/layer pixel formats. uGFX drivers convert from the system format (which all drawing operations occur in) to each display/layers internal format in the driver. That conversion is obviously trivial when the system and all drivers agree.

There seems to be a confusion here between the display DPI interface and the framebuffer format. They usually do not need to be the same. For most controllers, they will do the conversion on the fly between the frame buffer RAM interface and the DPI lcd interface. E.g. if you are using an 8 bit palette framebuffer format the display controller will do the palette lookup to create the 18/24 bit wide DPI data. Similarly, the framebuffer can be in RGB565 format which is efficient for the CPU, RAM and memory usage, and convert it on the fly to the 18bit DPI interface (by bit shifting the red and blue values). Layering also occurs at this level. Layers involves taking 2 framebuffers in potentially different pixel formats and "mixing" them to produce a single 18/24 bit hardware DPI value for the LCD. That is the other thing about layers, you need a full size framebuffer for each layer. They can usually be in different pixel formats. In fact, they may have to be in different pixel formats in order to not exceed the total RAM bandwidth limitations. E.g. an STM4 chip using LTDC with external RAM can only support 1 x 320x240 framebuffer at RGB565 unless frame rates are quote low. If you want the 2nd layer it needs to run at RGB232 or an 8 bit palette mode to meet RAM and LTDC bandwidth requirements. As implied there are things that can be done to help here, 2 x RGB565 are available at low frame rates. It may help to split the RAM interface, it may be possible to use higher speed static RAM, a different CPU may also help etc. I will leave the bandwidth calculations to be part of your hardware design.

Looking at the symptoms and your description it is obvious that you are still not talking SPI correctly to the display. Unfortunately you can't use SPI in 16 bit mode to emulate SPI in 9 bit mode. Unfortunately many micros are not able to talk 9 bit SPI, only 8 or 16. So, 1. Check carefully the data sheets of your micro to see if you can put the SPI port in true 9 bit mode 2. If it can't, see if the display has an 8 bit mode with a separate D/C line (most do). Note this requires an extra pin on your micro for the D/C line, or 3. Use bit banging instead of the micro UART. While this is a pain there is plenty of example code on the internet. At least this method can prove the working of the display and you can investigate a less CPU intensive solution later.

To also add some more detail... Most small display controllers use a pixel framebuffer that is outside the CPU address space. This is because the CPU is talking to them over a very slow bus like SPI or even 8 bit parallel. These buses are far too slow to be feeding display data directly to the display. Instead graphic commands are sent to the display controller which then renders into the off-CPU framebuffer. This covers most of the GDISP drivers. The few CPU's that have the display controller built in (or are on a very high speed bus) will typically map the pixel framebuffer directly into the CPU address space. The framebuffer and fb24 drivers are for these displays. The only odd one out is the LTSC driver for STM32 CPU'S. While this is theoretically a framebuffer driver situation, it has very complicated initialisation and eccentricities due to its support of DMA operations thus warranting a specialised driver for it.

The divide by 2 when calling xyaddr() is incorrect. It is the xyaddr() macro itself that needs the divide by 2. As indicated by the macro name, it is supposed to take (x,y) as it's parameters.

Those routines are typical of routines you would see at the board file level. They describe how to convert a logical operation into a physical one. For example, the logical operation is writePixel, the physical requires the details inside SPI_DataWrite_Pixel. Your driver will call those routines. Those routines will be in the board file of the driver. Note: This actually looks like 16 bit SPI with the top bits indicating data/cmd and read/write. You might rearrange the board interface like follows... write_cmd8(g, c) = SPI_CmdWrite(c) write_data8(g, d) = SPI_DataWrite(d) write_data16(g, w) = { write_data8(g, (gU8)w) write_data8(g, w >> 8 ) } Read instructions are similar. If you compare this to other driver board interfaces you will see this is very similar. You then just need to write the driver itself. Note: By doing this board level extraction the same driver could be used with the display controller in 8080 bus mode simply by changing the implementation of the board routines above. For the driver, having had a quick look at the data sheet, it is basically a "window" model driver that effectively uses the "MCU write with ROP" controller instruction. When you have that working you can then add an accelerated block fill routine using the controller "rectangle fill" instruction. There is another controller that is similar in that it is a window driver and has a accelerated block fill routine. From memory (I am currently away from my computer) it might be the SSD1331 driver or one of the RA drivers. Hope this helps.

Also have a look at the code for an Olimex board. It is lying around somewhere probably in the boards directory in the source code. It also uses a 9th bit instead of a D/C line and was one of the first boards used when developing the uGFX project. Of note: This means of communication requires a CPU capable of 9 bit SPI. The standard ST processors don't but SAM processors do. Look at your CPU hardware specs to see if it is supported. Also, sometimes the display controller can operate in either 8 bit mode with D/C or in 9 bit mode. This is usually pin configurable. If your CPU doesn't support 9 bit SPI then you will need to modify the display board, use bit banging SPI (not simple), or find another display.