Joel Bodenmann
-
Posts
2,656 -
Joined
-
Last visited
-
Days Won
2
Content Type
Forums
Store
Downloads
Blogs
Posts posted by Joel Bodenmann
-
-
If you just want to change the colors you can use widget styles: https://wiki.ugfx.io/index.php/Widgets#Widget_Style
Alternative you can write a custom rendering function for the widget: https://wiki.ugfx.io/index.php/Creating_a_custom_rendering_routine
Or even write your own widget that does exactly what you want: https://wiki.ugfx.io/index.php/Creating_a_widget
-
The error is indicating that the compiler cannot find the GDISP driver's configuration file which is located in the driver's directory. I'm not an Eclipse expert but most likely you forgot to include the GDISP driver directory in your compiler/linker include path: https://wiki.ugfx.io/index.php/Using_Eclipse#Adding_driver_resources
Maybe @cpu20 can help.
-
To get the system itself working it's strongly recommended to disable all modules (including the GDISP module).
You have the RAW32 subsystem enabled. You might want to have a look at the corresponding documentation: https://wiki.ugfx.io/index.php/BareMetal -
The first error is because you enabled the GDISP module but you haven't added any GDISP driver. To get started simply disable the GDISP module (and any other module!) in the µGFX configuration file (gfxconf.h).
The other errors are most likely indicating that you haven't enabled a GOS port. You need to specify the underlying system you're using in the configuration file.
-
Your content has nothing to do with this forum topic. Please don't spam existing topics.
-
There's currently no built-in driver for the GT911 touch controller. You'll have to write a GINPUT driver for it. Have a look at the interface documentation and the various existing driver implementations.
-
Alternatively, you can use the forum search and find this:
-
I'd like to add some info: This is not a hardware problem but how your uGFX board file(s) are configured. That's the reason why you're getting better performance with a different solution. The LTDC stuff allow for a lot of different configurations - You have to go through everything and figure out what the right ones for your hardware are. Especially check on DMA2D.
Also don't forget to set your CPU and compiler in the uGFX configuration file. -
There's currently no high-level API for that. I think you'll just have to extend the existing list widget to provide that functionality.
-
There are plenty of board files available in the /boards directory. You'll also find plenty of examples by google. Furthermore, every driver has a board file template in the driver's directory.
-
Hi,
You can look up all the possible hardware acceleration of the GDISP module in the driver interface documentation. Other places that support hardware acceleration are for example the GAUDIO module that can leverage an external codec.
Yes, the Linux framebuffer is supported: https://wiki.ugfx.io/index.php/Linux#Framebuffer
-
Please stop spamming an unrelated forum topic.
-
Hi,
Making ready-to-run projects is very difficult as it depends completely on the underlying hardware. If you're using some sort of development board/kit you should get a project for that and then just add µGFX as described in the detailed step-by-step guide for Keil in the documentation.
µGFX is completely platform/hardware agnostic which means that it will run on almost anything. The normal workflow is that you get your stuff running without µGFX (eg. taking a sample project that comes with the development board/kit that you use) and then you'll add µGFX to it.
-
12 minutes ago, zaher said:
By the way, how to remove this splash screen or it is necessary everytime the system starts up?
Have a look at GDISP_NEED_STARTUP_LOGO in the configuration file.
By the way: It seems that your display (pages) are swapped. Left and right are swapped.
-
The display controller is physically connected to your microcontroller/system via some kind of bus. For example parallel or SPI. The acquire_bus() and release_bus() functions are called by the driver itself (which is independent from what interface/bus is being used) before and after making a bus transaction. These functions allow you to acquire the bus before talking on it and releasing it once you're done.
In case of a simple SPI interface this is where you want to set your CS pin level accordingly. More complex systems might need to call OS functions to acquire/request bus access and stuff like that.
The GDisplay structure represents the actual display. You can have a look at the documentation to figure out what information is contained. Usually you're interested in this when dealing with multiple displays or requiring the private board file area.
-
15 hours ago, emeb said:
Is there an alternative way for me to update text on the display that would operate in a single pass? In other graphics libraries I've used off-screen buffers for this, but for uGFX that would mean pixmaps which as I understand it are not available for me because I'm using single-file include.
Yep, that's correct: Pixmaps are meant to be used for this.
Single-file inclusion is just a method designed to be as comfortable as possible. You can always include the µGFX library sources the classical way. It's just a bit more work. But now that you already know µGFX a bit it should be fairly simple
-
And a GINPUT toggle for the pushbutton to select stuff
-
Definitely!
-
Glad to hear that you got it working!
I'm not sure about what v3 repo you're talking about tho. You should be using the master branch of the official uGFX git repository: https://git.ugfx.io/uGFX/uGFX
That branch will become v2.9 which contains the new type systems and other things to prepare for the v3.0 major update. -
In general you don't want to build µGFX as a static library because there is A LOT of pre-processor magic happening that optimizes tons of things during compile time. We've had many customer projects where they wanted to build µGFX as a static library. After some short argumentations they usually dropped that idea fast - except for one customer. And from there on it was a constant pain in the butt. A lot of time was lost due to different problems that only arose due to building µGFX as a static library.
I'm currently on the road so I've limited comfort to write down detailed reasons. But in general: No you don't want to do that except some very specific special cases where you'd know that you want that and why.
I hope that helps.
-
What you want is the Toggle driver of GINPUT. It allows to attach hardware buttons to µGFX applications.
There's a working example for some Atmel SAM platform. You might want to use the forum search on "toggle" to find more information.
-
Hello & welcome to the µGFX community!
You will certainly be able to run µGFX on that hardware with that SDK.
There's not really much to it. As expected: Setup a working project and then add µGFX to it. As you've mentioned there are guides for that (you might want to have a look at the agnostic guide as well). -
Cool! That would be appreciated
-
GDISP drivers have an interface for reading out the framebuffer. You can use that to get direct access to the pixel data. But keep in mind that uGFX itself doesn't need a framebuffer. So there are certain setups where this won't be possible because there's no framebuffer accessible.
If this is a higher end application you might already be using Pixmaps which are essentially framebuffers. The Pixmaps have high-level API to return a gdispImage object of the framebuffer contents.
Online Font Converter
in Support
Posted
We've tracked the problem down to a source-IP based load-balancing issue. It should be fixed now.