Joel Bodenmann
-
Posts
2,656 -
Joined
-
Last visited
-
Days Won
2
Content Type
Forums
Store
Downloads
Blogs
Posts posted by Joel Bodenmann
-
-
Hi,
I should have some spare time on Sunday to have a look at this. Stay tuned
-
The code attachments you provided don't seem to compile and seem generally incomplete.
We'll gladly help wherever we can but we can't do guess work. Please provide a minimal example and explain what "does not work".I'd recommend you to either implement a custom widget from scratch (there is documentation on that as well as the aforementioned examples) or to copy the existing tabset and modifying it as needed.
Your last post seems to go the right direction
-
Before we look at this, could you maybe add a bit more detail than "it's not working"?
-
I just had a closer look at this. In case of anything inheriting from the container class, the custom draw is only responsible for the client area of the container which explains why this didn't work out for you.
The proper way of doing this would be to implement a custom widget to facilitate your needs as demonstrated by the documentation and various existing widgets (there are also two examples in the downloads section).
If you prefer a quick'n'dirty solution you could change the current drawtabs() implementation to render the tabs with images instead. You might be sneaky with some weak pointers here.Long term, the best approach would be to create a custom VMT for the Tabset and having a function pointer in there for the non-client-area drawing.
-
Hello & Welcome to the µGFX community!
You can customize the look'n'feel of any widget to match your needs. The easy approach here is to implement a custom drawing/rendering function for the existing widget. This means that you keep using the existing tabset widget behavior and you only change the way it is being rendered.
There is a full example in the documentation showing how to add an icon to a pushbutton widget. The process will be the same for the tabset: https://wiki.ugfx.io/index.php/Creating_a_custom_rendering_routineYou can use the void* parameter to pass in anything you like such as an images array or a complete custom type.
This should cover any scenario where you are happy with the existing behavior but want more control over the visual look.In case that you also want to have different behavior, you can implement your own widget: https://wiki.ugfx.io/index.php/Creating_a_widget
-
Thank you for sharing your driver with the community!
Luckily, v3 will end the pain of deviating initialization sequences
-
On 22/07/2023 at 19:46, Madyn said:
With a lot of digging, I found that the acquire bus and release bus are supposed to control the SPI CS.
That is indeed correct.
The reason why it might be "ambiguous" is because the driver interfaces & board files are designed to be as agnostic as possible. There are scenarios where the same driver & display controller is used in a scenario where "acquire bus" and "release bus" does not simply translate to controlling the SPI CS.
But in any case I agree that this should be documented more clearly - especially with some basic examples.On 22/07/2023 at 19:46, Madyn said:The system seems to work, however, it fails compilation when gfx.h/c is trying to find the configuration file. Since it's apparently been configured by the makefile, it doesn't read compiler paths.
Just in case this isn't clear: The configuration file (gfxconf.h) is something that you have to provide. There is a sample file you can copy from the top-level directory of the µGFX library distribution (gfxconf.example.h). Usually you'd copy that and rename it to gfxconf.h and that's it. Where this is placed is entirely transparent to the µGFX library as long as you get your include paths correct (which is toolchain/buildsystem/IDE specific).
On 22/07/2023 at 19:46, Madyn said:What I was looking for was a "this is what the project tree needs to look like, so your sources go here".
Given that the µGFX library was purposefully designed to be entirely agnostic to everything there is no "one-size fits all" solution from our side. However, a basic guideline can be:
- If you use a Makefile based buildsystem, simply include the µGFX Makefile
- If you use a CMake based buildsystem, simply include the µGFX CMake module
- If you use some proprietary or non-standard build system or something hidden behind an IDE that is either difficult or impossible to modify, use the single-file-inclusion mechanism if you don't need multiple-display support
- If none of the cases above work, put in the elbow grease and manually add the necessary C files & include paths to whatever system it is you're using essentially treating the µGFX library like "your own code".
But in any case, just take the µGFX library source code and treat it as a black-box. i.e. copy paste the code somewhere on the filesystem. No matter what build system integration option you use this will ensure that you can upgrade transparently to newer versions down the road. Where you place this directory and how you manage that is up to the consuming project. We put a lot of effort into ensuring that it's entirely portable from our side.
On 22/07/2023 at 19:46, Madyn said:Every program (and language, computer or otherwise) is created with the inborn assumption that "things will be done this way". The larger the program, the more subtle, at times, the assumptions. Now I'm beginning to understand the assumptions you made in this program. Since I'm still setting things up, well, still figuring things out.
That is reasonable
There is the overall "architecture" documentation here: https://wiki.ugfx.io/index.php/Architecture
There is a dandy chart in the GDISP documentation about the overall structure of the module: https://wiki.ugfx.io/index.php/GDISPOn 22/07/2023 at 19:46, Madyn said:I think I have the board file reasonably understood, but some of the configuration options are going to be interesting. Since I don't (obviously!) write code the way you do, I'm still figuring out what I need to know.
Don't hesitate to ask if you have any questions. We'll gladly help out wherever we can.
-
Hello & Welcome to the µGFX community!
12 hours ago, Madyn said:- I want a graphics system I do not have to rewrite when larger projects go to Linux.
- I want a graphics system that moves easily from project to project.
You're certainly at the right spot then! This was one of the major design goals of the µGFX library.
12 hours ago, Madyn said:adding uGFX by putting links in and changing some pathis works, but not gracefully. Display inits, but rather complete lack of instructions on how to fill out the board file. (DID find more information here about purpose of inlines, but that REALLY needed to be an inclusion in EVERY board file or at least obvious). GetBus and ReleaseBus were not obvious, as was not the "leave the CS active at all times, thank you" until the bus is released.
Thank you for your feedback. I agree that more documentation should be added to the board files.
Although it does not address your point (because it still doesn't properly document the required board file implementation) this resource might still help: https://wiki.ugfx.io/index.php/Display_Driver_Model12 hours ago, Madyn said:Problem with above scheme is that when trying to clear the display, converting your blue color yields a 0 when converted to native (ILI9341 should use RGB565). Still puzzled about that.
Can you provide a bit more information on this? What exactly do you mean by "converting your blue color yields a 0"?
The GDISP driver is supposed to declare the correct pixel format: https://git.ugfx.io/uGFX/ugfx/src/branch/master/drivers/gdisp/ILI9341/gdisp_lld_config.h#L21
From there, the µGFX library should handle color conversions correctly.12 hours ago, Madyn said:removing this and following instructions to addere uGFX as single file leads to puzzling placements, such as gfx.h, which then calls /src/gfx.h (which makes little sense right now). Many inclusions remain unresolved.
The single-file-inclusion mechanism primarily exists to easily integrate the µGFX library into non-standard build systems (usually proprietary IDEs) as to avoid having to manually list all include paths and source files. The only disadvantage of using the single-file-inclusion mechanism is that multiple display support won't work (i.e. you can only ever have one display).
You should not have to include anything yourself. The only thing you have to do is adding src/gfx_mk.c to your build system. Everything else inside the library itself is self-contained within that structure. Documentation on this is here: https://wiki.ugfx.io/index.php/Getting_Started#Single_File_Inclusion
Can you provide more details on the issues you're encountering?
Which build system are you using? The library itself supports Make and CMake out-of-the-box. Let me know if you need an example of how to use the µGFX library in a CMake scenario.12 hours ago, Madyn said:I also needed to rewrite the C++ routines to C (as separate routines) for things like the SPI driver. While semaphores are not bypassed, my own C++ routines are meant to run on a per-transaction basis, with CS optionally down, run both register and data, then releasing the CS. Again, protected by semaphores to make them thread safe.
On the board-file level you can do pretty much anything you want including using C++ code.
Note that the GDISP module provides a config flag GDISP_NEED_MULTITHREAD. If you set this to GFXON, the GDISP module maintains a mutex to facilitate threadsafety when accessing the actual display itself. This is entirely transparent in terms of API.12 hours ago, Madyn said:I don't really like trying to call C++ routines from C, and run into "unknown statement "class" and the like" I bypass that by only calling C from C++.
That is reasonable. When the µGFX library is used in a C++ environment the typical scenario is to write the board file implementation in plain C and simply using C++ for the application level stuff. The core library and the drivers usually take away all the heavy lifting so implementation of board files in C is pretty painless.
12 hours ago, Madyn said:1) I'd like to know what the preferred directory structure is for uGFX, including all the included routines at the bottom of the stack. By what's not linked, I don't think I have it right.
What exactly do you mean by "preferred directory structure"? Usually you'd include the µGFX library and not touch it. Leave it as a self-contained 3rd-party software component. The only thing that goes into the consuming project itself is the configuration file (gfxconf.h) and the board file (or custom driver if needed).
12 hours ago, Madyn said:Low level driver integration with an existing operating system seems to be a problem, and I do not wish to go to ChibiOS.
Which problems are you observing? The idea is that the board file is simply #included which means that it can live anywhere as long as the path is in the compiler's include paths list.
Furthermore, the board file is the only piece of software which interacts with the underlying OS / HAL. Therefore, it is easy to use anything you like (be it ChibiOS, FreeRTOS, Baremetal, Linux or anything else. The only thing that needs to be adapted is the board file.
This design has served us well for over a decade and we haven't heard of any problems with this particular aspect yet. We'd be very keen on hearing more details on this so we can potentially improve the situation.If you can add a bit more detail to the issues you're encountering we'll gladly help & clarify where we can.
-
Children inside the container will be moved automatically when you move the parent container.
-
You should be able to make the container larger than the display and then move it with `gwinMove()`.
Alternatively, you might want to use the List widget which already implements proper scrolling: https://wiki.ugfx.io/index.php/List
Note that this widget can be heavily customized to fit your needs. There is an example on the forum showing how to use it for an icon grid. -
We'd need a bit more information to provide you with specific answers.
In general, assuming that you have Linux running on your SOM it should be as easy as compiling an µGFX application for Linux: https://wiki.ugfx.io/index.php/Linux
However, whether you can use the X, SDL or FrameBuffer driver or whether you need to use one of the other GDISP drivers depends on how your system is built (eg. how the display is connected), whether you're running a WM and so on.
If you can provide more information we'll gladly point you towards the right direction.
-
3 minutes ago, w3llschmidt said:
I love uGfx, realy great peace of work!
Glad to hear that!
Happy that we could help. Please don't hesitate to ask if you have any further questions. -
Hello & Welcome to the µGFX community!
Yes, it is possible (and very common) to do this with the µGFX library. The library has been designed to run on virtually any system/platform.
Depending your system you can either use one of the "Linux" drivers (eg. X, SDL or framebuffer) or directly interface a display via GDISP (if you have a display not "integrated" into the OS). -
It doesn't have "an advantage". It's just a variant of the string rendering function which also fills in the background whereas the other one doesn't. Which one is the "correct" one to use depends on what you are doing. Sometimes you don't want to override the background.
Just as a side note, you can also use the various gdispGXxx() functions without the capital 'G' in them (for example just gdispFillString() or gdispDrawString()). This way you don't have to specify your display on every function call.
-
Glad to hear that
-
It's difficult to say anything helpful without getting any more details.
If you call gdispGDrawString() repeatedly without clearing the area first it would be quite likely that your text will look jagged as you would basically "override" the "anti-aliasing pixels" every time further offsetting their true/apparent color values.
Try to clear the area first. Alternatively, use another string rendering function (there are some variants that render with a box & background).
-
Hello & Welcome to the µGFX community!
On 25/01/2023 at 18:38, w3llschmidt said:Is there a possibility to decode the pictures (icons) into the code; like Fonts?
Can you explain a bit more what exactly you mean?
One option is to use ROMFS. It comes with a little utility to convert any file into a C array essentially allowing you to "embed" files into your binary.The GFILE module allows to transparently load an image from any supported filesystem (including ROMFS). This means that you can develop your GUI on a desktop machine using one of the corresponding drivers (SDL2, X, Win32, ...) and load the files directly from the host's filesystem via NATIVEFS and if you build binaries for your embedded target you just switch over to ROMFS. All of this works without modifying a single line of your application code.
I hope this helps. Please don't hesitate to ask if you have any further questions.
-
Hey,
It seems like you just copied the same compiler output as in your initial post. Please provide a bit more information as requested in my first post.
-
Hello!
Can you provide a bit more information regarding your environment? The errors you're getting certainly indicate that you didn't enable a GOS port (the main system abstraction layer). You can read more about that here: https://wiki.ugfx.io/index.php/GOS
If you're using zephyr there is an existing port: https://wiki.ugfx.io/index.php/Zephyr
If you're using another underlying operating system such as FreeRTOS there are also existing ports for those.
If instead you're not using any underlying operating system (baremetal) you can use the Raw32 port: https://wiki.ugfx.io/index.php/BareMetalAlso, which build system are you using?
-
Hey,
Based on the compilation errors it seems like you didn't setup the inclusion paths properly. I haven't used Eclipse in a while, maybe someone else can chime in to help. But I'm fairly certain that it has (at least in part) to do with the paths setup.
Is the use of ${ProjName} valid in those paths? And if so, does it make sense that the paths are prefixed with / ?
Have you tried adding the paths exactly as they are shown in the documentation that you linked (here) ? -
Hey Michael,
Well, that is exactly what we are here for: To answer questions, help to guide along the way and most importantly: Improve upon feedback.
If you can tell us in a little more detail which details are unclear, and to which questions you didn't find any answers we will gladly provide the necessary information and update the corresponding documentation
Best regards,
~ Joel -
Hello & Welcome to the µGFX community!
In general, the µGFX library is known to work well on ESP32 platforms. There are plenty of customers and hobby-ists which reported quite satisfying results.
Both porting and writing new display drivers is pretty easy and well documented. We're happy to help wherever we can.Do you have any specific questions we might be able to answer?
-
We don't know everything and we're always open for suggestions
-
Glad to hear that you got it working!
1 hour ago, AJJ said:I would suggest adding either an assert or minimum value to ticks2ms in _gtimerInit(..) to prevent this from tripping others in the future.
Things like that are not as easy / as straight-forward as they might seem at first. For example, if the underlying system is configured to run in tickless mode, things start to look very different already. We try our best to add rules, checks and so on wherever sensible within the µGFX library but everything that is interface related, especially the port to the underlying OS (if any) is not easy to sanity check in a generic manner.
After all, this is embedded. It's very easy to shoot yourself in the food and hard to prevent that without bloating everything or limiting use case scenarios.
Tabset with image in tab instead of text
in Support
Posted
Got some glorious food poisoning over the weekend. I'm afraid you'll have to be patient for a few more days.
Apologies for the inconvenience.