Joel Bodenmann

How can this be happening with /demos/modules/ginput/keyboard? Did you actually try running the /demos/modules/gwin/keyboard demo on your hardware without any custom code?

That definitely shouldn't happen. The keyboard widget only redraws the key that changed the state (feel free to check the source code). A full redraw of the keyboard widget is only performed if the visibility, enable state (or any of these of the parent container(s)) changed. I'd recommend you try putting the keyboard widget outside of any parent container(s) on your display without your visibility control code to see whether it performs as expected. It's a very simple test (quickly done) that will tell whether it's an issue in your code or something hidden deeper.

Hi, I am not sure whether I understand the problem that you're describing. Can you please create a short video that demonstrates the problem?

Hello Charlotte, The text rendering functions provided by the GDISP module (such as gdispFillStringBox()) don't store the text anywhere in memory. Those functions simply set the pixels correctly to display that text and then everything gets forgotten. They are simple pixel manipulation functions, they don't have any intelligence or memory. That is what labels are there for: They store the text themselves so if they need to be redrawn (eg. when changing the display page) they can redraw themselves because they retain the text they are supposed to display in memory (the GWIN text attribute that you can set with gwinSetText()). Therefore, the behavior that you are experiencing is perfectly normal and expected. If you need to draw things that need to redraw themselves upon changing display pages or similar, use widgets - that is what they are there for. In this case, simply use the Label widget instead of gwinFillStringBox() - or create your own widget if you have more specific needs. The UTF8 thing that you are describing sounds a bit strange. Can you please put together a small test case so that we can run it ourselves to see what is going on? Simply attach a ZIP archive containing the most minimalistic uGFX application code to show the problem (eg. one Label and GTRANS), the fonts that you are using as well as the configuration file.

Hello @cpu20, Thank you very much for diving into this - we appreciate it a lot! Unfortunately nothing comes to mind that might help you right now... If everything went well gfxInit() will clear the display using GDISP_STARTUP_COLOR. Most likely that is set to black so that could be an indication that everything went well. Have you tried actually drawing onto the display?

You can change all colors using WidgetStyles --> https://wiki.ugfx.io/index.php/Widgets#Widget_Style| Alternatively you can create custom rendering functions or even complete custom widgets if you need/want more customization than just colors.

The StdPeriph library is very old and deprecated. You should really be using the CubeHAL instead (which is the official successor of the StdPeriph library). But anyway, from the µGFX point of view this won't change anything. Please do the two other things mentioned in my first post to further track down the problem (Using the debugger to check whether the systick handler gets called and using the latest git master version of the µGFX library).

Hello @yaoyutaoTom and welcome to the µGFX community! Can you please give us more information about the system that you're using: What hardware (eg. what STM32) Whether you're using an underlying RTOS or bare metal Used compiler What HAL you use (eg. CubeHAL?) Anything else that might be helpful/important to know In case of you're using the CubeHAL, just take the example from the wiki to implement the systick functions, there's not need to write that yourself: https://wiki.ugfx.io/index.php/BareMetal#Example If you can't do that because you're not using CubeHAL but something different you might want to set a breakpoint at SysTick_Handler() to verify that it actually gets called. Another likely cause is that you're using an older version of the µGFX library which contains a bug in the RAW32 port used to run on baremetal (which I assume you're doing). Try updating to the latest version. In general we recommend using the latest master branch from the Git repository, not just the latest stable release. For everything else we need to have the information mentioned above. P.S.: Please use code-boxes to put code in your posts, I added them this time for you.

Glad to hear that you got it working!

µGFX doesn't use fixed refresh rates nor full-framebuffer updates. Therefore, you can't get a classic FPS (frames per second) value like on other video systems. The best thing you can do is clearing the display with two alternating colors using gdispClear() and measuring the time in between which gives you a pixels/seconds value similar to the benchmark that you were running earlier. However, you have to disable DMA2D as it would make the results become inaccurate. Also, in this case it's really hard to come up with a number that allows comparing the system to others because you have the LTDC which automatically refreshes the framebuffer. All you do when drawing something is writing to the framebuffer memory but nothing shows on the actual display yet. I'm really more curious whether you have a "smooth" experience or whether it's laggy. I know that the DSI / MIPI interface has two modes: Video mode and Adaptive command mode. When I remember correctly you're using Video mode which always streams the entire framebuffer content to the display. The adaptive command mode (again - when I remember correctly) would allow only updating partial display areas which is something that µGFX is very well capable of and which could vastly increase performance. But I'm really unsure - I'd have to dive into the datasheet(s) again. You probably know more about that than me.

@Ivan.L was using an older version of the µGFX library which still contained the old RAW32 code. Upgrading to the latest master branch was what actually resolved the issue. (This issue has been discussed on IRC).

Thank you very much for bringing this to our attention, we'll have a look at that in the following days.

That is intentional. We want to get the raw reading (as the demo/tool name suggests). Very nice, great work! Can you tell us what kind of performance you get out of the display? What's the maximum refresh speed you get with your driver/board file?

Never trust the Eclipse code analyzer thing. The µGFX library heavily relies on the pre-processor (macros) to optimize code during compilation. Those "simple" highlighters that IDEs like Eclipse come with simply can't cope with the complexity. Furthermore, some of our macros get changed automatically during compile time by the pre-processor so what you see prior to compilation is not necessarily what you get at the end. The same applies to ChibiOS. Simply ignore what Eclipse tells you. It has been a while since I last worked with ChibiOS. Is it possible that you forgot to enable I2C1? When I remember correctly you don't only need to enable I2C in general but also each individual I2C peripheral. Also, don't forget so set you pin configurations correctly: You need to set them to the correct alternate function and depending on the STM32 that you're using even to open drain manually. This is a guide I wrote back a couple of years ago regarding I2C debugging/troubleshooting with ChibiOS, you might find that helpful: http://wiki.chibios.org/dokuwiki/doku.php?id=chibios:community:guides:i2c_trouble_shooting In general the ChibiOS forum is more suited for this question.

Your account is now blocked for 7 days. From then on all your posts will require manual approval from a forum moderator or administrator before they get published.

Glad to hear that you got it working!

Hello Ronan, You have to control the visibility of the keyboard widget yourself. The GWIN module is a very small and efficient window manager that doesn't provide high level features like that as it's optimized for static GUIs. However, that doesn't mean that it can be done - you can do it and it's very simple, it's just something you have to handle in your own application code. We only provide the widgets, it's up to you to implement the actual behavior of them as that depends heavily on your GUI.

Can you please attach the entire build log as a text file to your post? Screenshots are very cumbersome for us to work with (and unnecessarily large files). Also, don't forget to make a clean build.

Hello @dossakab and welcome to the µGFX community! Can you please try setting the path pointing to the µGFX library in your Makefile (the value of GFXLIB) to a path that doesn't contain ~ in it? You can either use relative or absolute paths.

Can't wait to see it

Hello @spectre, good to hear from you again The built-in fonts that come as part of the µGFX library has been filtered quite strictly to only include characters from a-z, A-Z, 0-9 and the most common punctuation marks in order to keep the memory footprint low. The degree symbol is simply not part of the font. What you have to do is converting your own font. You can take the same DejaVuSans12 font of course. Just feed it into the font converter and select the ranges so that it includes the degree symbol.

You can switch between pen and finger mode by using ginputSetFingerMode() (documentation). Furthermore, the flags field of the driver VMT can tell whether the driver is by default in finger or pen mode by using the GMOUSE_FLG_FINGERMODE flag. I don't remember the details on top of my head but as you mentioned in your second we use read_word() instead of read_byte() which will not only grab the XH register. As mentioned previously that driver is pretty crusty and it's very likely that it needs some improvement. We'd be very happy if you could contribute back your updated driver & board file for the discovery board. You did a great job at getting this board working! We appreciate your endurance on this a lot! Keep up the great work! This and next week it will be almost impossible for us to get anything else done but the week after that we'll have a look at your drivers & board files

Hello @Ivan.L and welcome to the µGFX community! For clarification: The GINPUT module relies on a GTIMER which in turn requires threading to work which is provided by the RAW32 GOS port. As @inmarket mentioned there's a very well known bug regarding the c library implementation of setjmp() and longjmp() which are used when GFX_CPU is set to GFX_CPU_UNKNOWN. However, in the configuration file that you showed in your first post you set it correctly to GFX_CPU_CORTEX_M7_FP so I don't expect there to be a problem. However, running the /demos/modules/gos/threads demo as mentioned by @inmarket is definitely worth a try to further track down the problem. The demo lets you verify whether the threading stuff is actually working. The timeout parameter of geventEventWait() should not have any effect in that case. The hardfault that you're mentioning again suggests that it could be a problem in the threading. There has been a similar issue reported by @91321146 but unfortunately we didn't have time yet to investigate ourselves. We have RAW32 working on the STM32F7 Discovery board using Keil µVision but maybe something else is buggy. We're looking forward for your report regarding the /demos/modules/gos/thread demo.

Please read this very carefully: We are happy to help you just as we are happy to help anybody else on this forum. Stop using custom fonts in your forum posts (colors, larger fonts, ...). Exactly tell us what problem you're having. Ask specific questions. Tell us what kind of system you're using (hardware, compiler, board, underlying system, IDE, ...). If you have build issues, attach a text file with your entire build log. Stop ignoring our instructions, this is literally the fourth time... If you keep ignoring our instructions you leave us no choice but ignoring your posts.

Is this issue related to this one and therefore solved now?