Joel Bodenmann
-
Posts
2,620 -
Joined
-
Last visited
-
Days Won
2
Content Type
Forums
Store
Downloads
Blogs
Posts posted by Joel Bodenmann
-
-
Okay, so at this point we're pretty sure that there's something "wrong" in the board file. Unfortunately, that's always the trickiest for us to help with as it's completely out of our scope.
The following things are helpful to track down the problem:
- Tripple check your line logic: It's very common to accidentally invert the reset logic and similar,
- Lower your SPI clock to something <= 1MHz to rule out electrical issues due to too high clock speeds.
- Remove any DMA & general interrupt stuff and implement everything polling.
- Use a logic analyzer to confirm that the data on the bus matches the values passed to the board file functions.
- Most display controller provide some sort of chip ID-readout. You can query that in the drivers initialization function to figure out whether transmission is working correctly.
- The ILIxxxx display controllers tend to be extremely difficult to work with when ordered from chinese sources. The main issue is that you often don't get the chip that you though you get. Eg. sometimes you get an ILI9325 instead of an ILI9320. To make matters worse, some of the ILI display controllers have (completely) different initialization sequences for different chip revisions. Usually you get some demo code with the display module that you're buying. Verify that the initialization sequence in the drivers initialization function matches with that provided by the manufacturer. If in doubt, always use the one you received with your display module.
-
37 minutes ago, AlexK17 said:
I changed the parent to label and container to which the label belongs, but both
labels are shown only on the start page.
You do not have to change anything on the parent container.
Just to be clear: What you want to achieve is to have two display pages ghContainerPage1 and ghContainerPage2 as well as a label ghLabel1. The label ghLabel1 is supposed to show up both on ghContainerPage1 and ghContainerPage2 when changing the display page. You use the widgetSetParent() function I posted above in the guiShowPage() that is being generated by the µGFX-Studio:
void guiShowPage(guiPage page) { // Hide all pages gwinHide(ghContainerPage2); gwinHide(ghContainerPage1); // Show the selected page switch (page) { case PAGE2: widgetSetParent(ghLabel1, ghContainerPage2); gwinShow(ghContainerPage2); break; case PAGE1: widgetSetParent(ghLabel1, ghContainerPage1); gwinShow(ghContainerPage1); break; default: break; } }
-
You misread the code that I posted (and probably the explanation/legend I posted below the code snipped). Just translate it to pure C code:
void widgetSetParent(GHandle widget, GHandle newParent) { gwinHide(widget); gdispFlush(); // This is optional and only required in certain driver scenarios to prevent artifacts from showing up. widget->parent = newParent; gwinShow(widget); }
-
Yep, that seems correct. I remember that I left of pretty much at that point. I still wish to finish it at some point. If I remember correctly it's like 95% done.
The segfault should be easy to track down as it will be either a buffer allocation or an array index overflow. -
The spinbox in that branch is made for nummeric values, not texts
-
Glad to hear that!
The online font converter tends to be down quite a lot (we currently have about 80% availability on the statistics). The reason for that is because we're hosting quite a lot of servers (µGFX is a spin-off of an already existing engineering company. We're running a lot of stuff for different projects and also customers. Whenever we do any kind of migrations, changing environment or doing any other kind of modifications we test everything in a test setup. Once we feel comfortable we always move the µGFX online font converter first as it's a pretty good reference server (it uses a few different technologies) which allows us to test everything from simple backups to load balancing and high availability systems.
It's just that the online font converter is the perfect balance between "not critical infrastructure" and "people actually use it" which is just awesome for testing everything before touching real production environments.
-
Hi,
We are manually moderating all git server registrations. This process will change with the release of µGFX 3.0. For now, just let us know your registration username or e-mail and we'll manually validate your account (feel free to PM so you don't have to share any info on this public forum).
-
I'm standing between doors right now so I haven't checked your actual code yet, but let's work our way through the basics:
- Did you use the debugger to check whether the system is halting somewhere?
- Are you getting the µGFX logo to show up but you simply don't get your own stuff to show on the display (make sure that the startup logo option in the configuration file is enabled)?
- Did you check that the integration is actually working? You might want to run one of the GOS demos to confirm that stuff like software timers and threading is working correctly
-
That doesn't matter. As I said it's code from a wrapper around the normal uGFX window.
-
Thank you for your feedback - much appreciated as always!
The next release is very near. So far we've added static text items to the background editor and I've also reworked the way that post generation stuff works. It's a lot nicer and a lot more flexible now.
I'm not sure if we add arraying support for the next release already or if we move that to a different release. -
That sounds great! I'm looking forward seeing that widget
You simply add the function to the widget's VMT which handles incoming dial events - simple as that! --> https://wiki.ugfx.io/index.php/Creating_a_widget#VMT
-
If you need information on multiple display pages the recommended way of doing things is making the page container smaller and adding the widgets that display the required information within the area not covered by that display page. There's an example of a statusbar widget in the download section.
If that is not possible (eg. due to how the UI is designed) you can actually change a widgets parent container. Here's a code snipped of a C++ wrapper class that is used inside the µGFX-Studio to accomplish this:
void UGfxWindow::setParent(const UGfxContainer* parent) { // Sanity check if (!_ghandle) { return; } // Sanity check if (!parent || !parent->handle()) { return; } // Change parent container gwinHide(_ghandle); gdispGFlush(_ghandle->display); _ghandle->parent = parent->handle(); gwinShow(_ghandle); }
_ghandle is an attribute that is simply the GHandle of the µGFX window. Similary, parent->handle() is the GHandle of the new container.
-
Hi,
Yes that's, possible. But it's currently not implemented in the µGFX-Studio itself. But you can compile any µGFX application as a native desktop application (eg. Windows, Linux, MacOS, BSD, ...). The cool thing is that it's not a simulation or emulation like with other libraries, but instead it's a native application using the native µGFX library. Therefore, every single pixel is exactly like it will be on the target device.
Here's the guide on how to do that on Windows: https://wiki.ugfx.io/index.php/Your_First_Compile_-_Windows
You'll find similar guides for Linux and MacOS.Eventually, the µGFX-Studio will generate the necessary code (main code, configuration file, ...) and render it as part of the studio.
-
The board file is completely specific to each application. The existing ones are more of templates and examples that anything else. You're supposed to copy them to your application folder and modify them to fit your needs.
If you have an updated/improved board file for a supported board file we'd appreciate it if you could share it. Most of them were not created by ourselves so it's likely that there's a lot of room for improvement.
On 10/08/2018 at 15:11, Angus Schmaloer said:i did it and its fixed, i though it didn't respond anymore, but i just have to pres it a bit longer than normal (maybe hold it a bit instead of a short touch). now i kinda feel a bit dumd XD but glad it is fixed.
No need to feel bad at all
On 10/08/2018 at 15:11, Angus Schmaloer said:awesome library btw. The company i work for is gonne buy and use it. now i'm just testing for myself to see the library
Thank you for the feedback - glad to hear that!
-
Also check out the documentation (wiki) on how you can store calibration data which is loaded automatically so you don't have to perform calibration every time you launch the application.
-
Hello Tobias and welcome to the µGFX community!
There's no technical problem here. Most likely that example uses the touchscreen in Pen mode. There are two modes that a touchscreen driver can run in: Finger mode and Pen mode. There's no functional difference. The only difference there is is that the Finger mode is a lot less strict when it comes to moves and calibration error. Basically you need to press the calibration crosshairs a lot more precise in the Pen mode.
I'm currently on the road so I can't easily check but there's some API call which allows you to switch the mode. However, calibration takes place in gfxInit() and you cannot change the mode before that, only after the µGFX library has been initialized. Therefore, you need to change the default mode. That's a driver configuration so you need to look at /drivers/ginput/touch/<driver_name> and check whether you can do it in the drivers configuration file. If not, have a look at the VMT (struct) in the drivers implementation.
-
We cannot help you while you keep ignoring our posts.
You can always come back once you have specific questions that we can answer.
-
Hi,
You can use any font you want with µGFX. Therefore, you can just use a font of a different size. The font converter allows you to use any TTF and BDF font you can find which you can render to any size. Here's the corresponding documentation: https://wiki.ugfx.io/index.php/Font_rendering#Adding_fonts
There are four ways to encode a font:
- Use the online font converter (currently unavailable)
- Use the font converter inside GFX-Studio
- Use the pre-compiled font converter that comes with the library
- Compile the font converter yourself from the source that comes with the library
-
54 minutes ago, Fabien Comte said:
If you take a simple button, you can see that the text draw is after the retangle draw. I modified some controls to use pixmaps for compositions and display is very clean. I can move controls with no blink effect now
Yep that's often done in applications. That's definitely a proper way to handle things. In fact, the µGFX-Studio does that internally as well.
-
I've uploaded a patched version (v0.24.1) that addresses this issue with the Y coordinate.
@Steffan: I'm pretty sure that that was related. However, I'd appreciate it if you could check. -
On 01/08/2018 at 10:31, Fabien Comte said:
Could it be because page containers and status bar overlap ?
What do you mean by overlapping? The statusbar is a widget and can therefore either be in a container or not. It cannot be half way in one.
On 01/08/2018 at 10:49, Fabien Comte said:How to manage statusbar parent if it's called in multiple pages ?
Can you please show screenshots/mockups of what you're trying to achieve?
A statusbar is usually not part of a page container as it's always visible. -
Hello & welcome to the µGFX community!
The reason that you're not finding any information like this is because it's very difficult to provide them. The µGFX library has been designed to be lightweight as possible. Keeping resources down to a minimum is one of the main goals (like having a completely cross platform (agnostic) library)). Therefore, everything in µGFX is highly modular. At the highest level you will find that you can enable/disable entire modules. For example, if you don't have a touchscreen you can completely disable the GINPUT module. When you keep going further you'll see that you can individually enable/disable features, sub-features, sub-sub-features and so on.
There's A LOT that is being done prior to compilation by the preprocessor to throw out anything uneeded. Those optimizations don't only take the individual modules & features that have been enable/disable into account but also the used processor, used drivers and even the used compiler. Therefore, every build is completely unique and comparing resource usage across different platforms is extremely difficult and misleading.
We do have an internal spreadsheet which lists RAM usage of the individual objects of the µGFX library. However, we only provide that to customers which we are sure know how to everything works as misinterpreting these numbers is very easy.We have several dozen customers & users that run µGFX on a Cortex-M0 CPU - some with a much higher resolution that what you're targeting. µGFX will definitely be able to run on you platform without any problems at all. We even provide Cortex-M0 specific optimization (see GFX_CPU macro in the configuration file).
The chosen display controller usually has a much bigger impact on performance than anything else. µGFX will always run at full throttle. Choosing the correct display controller and the correct interface is therefore crucial. However, which one the "correct one" is depends on the rest of the hardware and especially the application that will run on it. -
Well that should work just out of the box. Nothing special required. The basic GUI functionality should not change depending on the GWIN redrawing mode. If you encountered some bug we'll need a minimal test case that allows us to reproduce the problem.
-
Hello and welcome to the µGFX community!
Please contact us via e-mail to get a quotation for a new driver implementation.
Alternatively, you can always do it yourself. You'll find plenty of documentation, examples and other resources in the documentation and on this forum.
One widget display on many page.
in Support
Posted
Can you please attach a *.zip archive containing a minimum runnable test case that we can run?