chrisjn52

Hi Joel, the GDISP driver repo readme.txt states that the UC8175 controller is supported but I can find no reference to it. I would modify the UC8173 driver myself but unfortunately I cannot find any datasheets for the UltraChip controllers on their website. Is the UC8173 driver suitable for displays with the UC8175 controller?

Hi Joel, good to hear that things are still progressing on V3, quality over quantity always preferred! I managed to make progress by referring to the touchRawReadings.c example file although I should mention that I had an issue which required further investigation. It turns out that the example code gives incorrect readings when the screen is rotated 180 degrees due to the negative coordinates and the unsigned format used in gprintf. Not an issue for most people and I had initially forgotten that I had rotated the screen. I have also been investigating drawing icon bitmaps from an SD card when using microcontrollers with limited resources, (aka Blue Pill) but so far it only seems practical for very small bitmaps due to the overall red/write time and the inability to cache all bitmaps using gdispImageCache. I am currently considering the effort required to create such icons using the ugfx draw functions....

It's been some time since I last used the touch routines and I now find that functions have changed and the useful refresher links are now appear broken and a search doesn't reveal any updated resource, eg. broken link to the calibration wiki page with 502 Bad Gateway response? Link Are any updated links available? As an aside, is uGFX V3 going to see the light of day anytime soon or has it been shelved?

The font converter is now working much better but the Custom Filter option doesn't allow the From field to be entered. Since this is coded as a Not Allowed field I am assuming this is due to a known issue with the McuFont converter? Currently it would seem that in order to include a character such as the Omega symbol I have to use the No Filtering option but after several minutes I get the following response from the browser: fonts.ugfx.io didn’t send any data. ERR_EMPTY_RESPONSE Many thanks for your support.

Hi Joel, I tried again this morning and I can confirm that there are two reasons why I have been having a problem. The first is that the converter fails if the font file is selected directly from the Windows font folder, but works ok if the font is within some other folder. ????? The second reason is that I was trying to obtain a large font and all font sizes over 20px fail for Arial.ttf causing the webpage to drop through to https://fonts.ugfx.io/index.php. I also tried another font, (Candara), and font sizes >21 fail for this font. I used numeric only conversions to limit the file size in each case. Incidentally, I also found that it is necessary to refresh the browser page before attempting a second conversion request in order to get rid of the "No Entry" symbol when hovering over the "Get .C File" button.

Hi Joel, I am still seeing the same issue, although I now see the file upload percentage in the browser lower left corner which I don't recall seeing before. It still complains about "could not import font - bad file format" despite trying several different ttf fonts? Should I see some sort of confirmation that the request is valid/has been accepted, once the "Get .c File" button is pressed? (I haven't used the Font Converter for some time until recently).

Is the online Font Converter working? When using from https://ugfx.io/font-converter the browser drops through to https://fonts.ugfx.io/index.php whereupon it displays the "could not import font - bad file format" message. I am using windows font file arial.ttf and I cannot get it to work with any character filter. I would use the built-in font converter in uGFX Studio but I want to restrict the conversion to a custom range to include the Greek Omega character and Studio won't allow a range beyond 255? Is there a way in uGFX Studio to limit the Custom Range to include just the Omega character, (U+03A9)?

I had problems with driving a 1.8" LCD when using the ST7735 driver that is currently a part of the uGFX V2.8 library. I found that unless the FRMCTR1 register had the RTNA byte was set to >2, even if the front and back porch bytes are adjusted accordingly, the display simply had a few vertical lines. Several ST7735 datasheets can be found on the web and the early variants had a different oscillator frequency and frame rate calculation which may go some way to explain why I was having problems. That said, I don't see why RTNA should not be set <2 provided that the overall frame rate isn't too high? Does anybody have any other datasheets/manuals etc that may help to explain this anomoly? It would seem from some of the forum comments that the ST7735 driver may not be fully supported as it may have some copyright issues but unless problems like this can be explained it would be hard to ensure any new driver supports all controller revisions. The attached photo shows the type of display I am using and is fairly typical of those that can be purchased on Ebay or Aliexpress.

I can appreciate how this would speed things up but I have very limited RAM in the STM32F103 so pixmaps of any appreciable size are not feasible. I am not familiar with all the variations in hardware capability of each microcontroller and TFT driver chips but I don't believe I have any other options for faster drawing on the STM32F103 and a ILI9341 controller that I am using, but please correct me if I am wrong. I am attempting to write a dial/meter widget much like this, which requires dynamic display of the segments that require updating. Whilst my original simple approach worked, it suffered from display artifacts due to the time delay in overwriting part of the arcs with the circle, (only for increasing meter vales).

Duh, I've missed a simple solution, rotate small polygon segments about the axis of a circle such that they form a continuous arc! The narrower the polygon, the more accurate the arc formation. This should still be much faster than the hardware is capable of filling all the pixels of a much larger circle in order to overwrite most of the the gdispFillArc() segments.

You may need to add paths to any driver files, eg. Stm32SystemWorkbench\ugfx_2.5\drivers\ginput\touch\ADS7843 but that doesn't sound like the fundamental issue. Are you using the single file inclusion method as per this link? Can you send me a screenshot of the errors and the path setup?

It sounds like you need to tell Eclipse the path for the uGFX source files in the project properties.

Are there any plans to create a function that fills two concentric arcs as shown below? I have tried using a gdispFillArc() and overwriting with a circle in the background colour which is fine for a static shape but too slow for any dynamic display. Would a variant of the gdispFillArc() function be the best way forward?

This demo widget code is for a horizontal user defined menu which consumes minimal screen real estate and is fully data-driven. The definition of the menu is declared using two statically declared structures which are independent of the widget render and handler functions. Two icons, (Home & Up) are used to return the menu to the home level or up one level respectively. A menu item is underlined if a child sub-menu exists and the sub-menu replaces the displayed menu when clicked. An event is generated for any menu item that is not underlined when clicked. A short video is attached showing the menu in operation. Menu.zip Video.zip

Version 1.3 submitted after a final polish. Version changes described at top of gwin_spinbox.c file uGFX_Spinbox_1.3.zip