Joel Bodenmann

Hi, I think you misunderstood with the text files: Only attach text file containing large, generated things like your compiler output. Don't keep your actual explanations, what you did and questions in there. These things belong directly in your forum post. So to summarize: Stuff you want to say/ask -> Forum post Larger text files that are relative (like compiler outputs, configuration files and similar) -> attach a text file to the same forum post. That is very important, please re-read it carefully. I'll quote your text file: You cannot use the NativeFS in your case. NativeFS is just a file system wrapper that allows using the native file system of the underlying system (if any). For example, when you're running your application on Windows or Linux, you can use NativeFS to directly access files on your computer's hard disk through GFILE. You are not using an underlying operating system that offers a native file system and hence you can't use NativeFS. If you want to use files (eg. if your µGFX application wants to load images and other resources from files) then use ROMFS. It's the best option you have. It's super small & efficient and very easy to use. Otherwise you have to use FatFS or something else that is way more complex and way more resource intensive. So, to summarize: If your µGFX application doesn't need access to files, simply turn the GFILE module off in your configuration file. If your µGFX application needs access to files, then simply use ROMFS in your case. Follow the documentation linked above, create your romfs_files.h files, add it to the project, convert all the files you need to access through ROMFS with file2c.exe, include the generated header files in romfs_files.h and you're done.

So, what is your question? Please ask specific questions that we can answer. Just saying that you don't know something doesn't help anybody.

So far you are only getting one error: ..\ugfx\src\gfile/gfile_fs_rom.c(36): error: #5: cannot open source input file "romfs_files.h": No such file or directory This error means that the file romfs_files.h couldn't be found by the compiler. The romfs_files.h file is required when you are using ROMFS (if GFILE_NEED_ROMFS is set to TRUE). If you don't actually use ROMFS then simply set it to FALSE. If you need ROMFS then create a file named romfs_files.h where you include all the converted ROMFS files (the files converted with file2c.exe). You can find the corresponding documentation here: https://wiki.ugfx.io/index.php/ROMFS

That looks very strange - nothing comes to mind right now. Have you tried making a clean build? You can do that in Keil µVision by clicking Project -> Clean Targets. Then make a new compile. It should restart from the very beginning this time. Can you attach a text file (like you did before, great!) with that clean build output log?

Hello @Ivan_Kuzz and welcome to the µGFX community! We'll have a look at this as soon as possible but that might take a couple of days. In general µGFX works very well together with Keil µVision and we use Keil µVision ourselves a lot in customer projects. From our point of view there is no need to switch. Please don't hesitate to ask if you have any other questions.

All widgets have the possibility to submit functions that handle toggle inputs: #if GINPUT_NEED_TOGGLE struct { uint16_t toggleroles; /**< The roles supported for toggles (0->toggleroles-1) */ void (*ToggleAssign) (GWidgetObject *gw, uint16_t role, uint16_t instance); /**< Assign a toggle to a role (optional) */ uint16_t (*ToggleGet) (GWidgetObject *gw, uint16_t role); /**< Return the instance for a particular role (optional) */ void (*ToggleOff) (GWidgetObject *gw, uint16_t role); /**< Process toggle off events (optional) */ void (*ToggleOn) (GWidgetObject *gw, uint16_t role); /**< Process toggle on events (optional) */ }; #endif This means that each widget itself decides what it does with a toggle input. For example, the list widget allows to scroll through the list and to select an item in the list: #if GINPUT_NEED_TOGGLE { 2, // two toggle roles ListToggleAssign, // Assign toggles ListToggleGet, // Get toggles 0, ListToggleOn, // Process toggle on event }, #endif You use the gwinAttachToggle() function in your application to attach a toggle input to a widget. Note that you can re-assign those at any time. I hope that helps.

Can you please tell us what doesn't work? If you have compile time errors, please attach a text file containing the entire output of the build process to your next forum post. Also, please do not use colored fonts, larger fonts or similar things in your forum posts.

Have you tried displaying the characters "manually"? Eg. by calling something like this: gdispDrawString(..., "Löwen, Bären, Vögel und Käfer sind Tiere", ...)

Hello @yaoyutaoTom, There's currently just one example and that's the one that you mentioned/showed. We'd be happy to include your code as an example once you have it working This is to simply invert the input. Imagine you want to have a hardware button to select an item in a list widget. You want the item to be selected whenever you press the button. You don't want to bother how the button is connected to the input pin of your microcontroller (active-low or active-high). Using the "invert", both cases can be used with the same high-level user code. I hope that makes it more clear. Please don't hesitate to ask if you didn't understand. We're happy to elaborate. These all come from the ChibiOS/HAL. That is something you don't have. All you have to do in those two functions is initializing the GPIO so it becomes a digital input and then reading the digital input (whether it's low or high). That depends what underlying system you're using. For example, if you're using the CubeHAL for the STM32 you'd simply call HAL_GPIO_Init() and HAL_GPIO_ReadPin() instead of palSetGroupMode() and palReadBus().

Did you enable UTF-8 Support? Did you ensure that your source file is properly encoded? Certain IDEs like to change the encoding of the source files.

Let us know about the results

Hello and welcome to the µGFX community! The way to do this is by creating a custom widget. You can find the corresponding documentation here. Judging from the fact that you already linked the matrix operations API documentation I assume that you know that you need to draw a needle polygon and then transform it, is that correct? In order for us to help you efficiently it would be helpful if you could tell us what you already know/understand and what exactly your questions/problems are. Otherwise we have to write down a complete guide here ^^ You might want to have a look at this custom widget that you can download from the downloads section that does more or less exactly that. It's a lot uglier than yours but the logic behind is the same. You might be able to just take and modify that. Note that we are using a PNG image as a background / dial / scale. The one you show in your photo can be drawn manually using arcs and lines. That will require way less memory than rendering a PNG image. Please don't hesitate to ask if you have any other questions. We're happy to help! Edit: This is the real API documentation for the matrix operations: http://api.ugfx.io/group___g_m_i_s_c.html

We just checked and it works well. I assume you didn't see that the first field is filled with a space. You can only enter one character in the filter range input fields. You have to delete the space that is in the first field before you can enter a new one You might want to use the offline font converter if you want to have the ability to use multiple filter ranges.

Glad to hear that you got it working!

@inmarket: note that @ronan_rt wrote his own touch driver. Our RA8875 driver currently only supports the display, not the touchscreen (the RA8875 is both a display and a touchscreen controller, but we only have a GDISP driver for it at the moment).

The GINPUT module performs all the fancy filtering and calibration required to get consistent readings. But it can't do that job well if the coordinates it gets as an input are incorrect. Please follow the advice you were given.

That's strange. We'll look into this. I put it on the ToDo list. But it might take several days / weeks until we get to it.

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.