-
Posts
2,620 -
Joined
-
Last visited
-
Days Won
2
Content Type
Forums
Store
Downloads
Blogs
Posts posted by Joel Bodenmann
-
-
Sir, you really need to start giving more details in your feedback posts: For which widget/window/container/...? How can we reproduce it? Is it correct in the generated code? ...
-
It seems that you didn't enable all the features in the configuration file that you're using in your application.
Please read through the introduction page(s) in the wiki to learn how things are supposed to work.
-
Just released v0.24. Changelog:
- Fixing issue with relative child coordinates in generated code
- Improving image editor (fixing various file copying bugs)
- Adding the ability to change a display page's widget style
- Adding missing configuration options for some of the widgets (eg. GDISP_NEED_CONVEX_POLYGON for buttons with arrow rendering method)
- Adding post-generation script option to target editor
The post-generation script stuff will be improved in the next release. Right now it can just launch an OS-native script with no parameters. If you want to run a Python script or anything like that you need to create a standard script for Windows (a *.bat file) and launch your Python script from t here.
-
That's why the board file tried to change the video mode of the Linux framebuffer (which is what you just disabled).
The proper solution is to figure out why it doesn't work on your platform and modifying the board file accordingly (that file is ALWAYS project/application/platform specific anyway). Otherwise, you'll have to change the pixel format that your GDISP driver is using to match the default one of your Linux framebuffer. But then you'll never be able to change it to anything else.
-
Please have a look at the board file. If you're using the default one it will most likely be /boards/base/Linux-Framebuffer/board_framebuffer.h. As you'll see that message is printed when board_init() couldn't set the video mode. This can have various reasons such as every Linux distribution using slightly different framebuffer compilation flags and so on.
To get things sorted out, you can simply start by commenting out this line at the top of the board file:
#define USE_SET_MODE // Optional - comment this out to not to try to set the color mode we want
-
Okay, I feel like adding a "Would you like to overwrite?" dialog is the most sensible solution here.
I'll add that tonight.So far the following things were done for the new release:
- Adding the ability to change the page container's widget style
- Fixing issues with relative coordinates of widgets in a container (in the generated code)
- Adding static text item to background editor (95% done)
-
Thank you for your feedback, much appreciated!
I'm working on fixing the issue with the code generator regarding containers that @king2 mentioned right now.
After that I'll tackle the image editor dialog. I know that it needs some work, I just don't know how to improve it exactly. Any kind of tipps would be welcomed. -
Hello Austin!
The first thing you need to do is figuring out whether you really want to run µGFX as an SDL2 application on your target. In most cases, people running µGFX on Linux on embedded devices use the framebuffer driver. SDL2 requires you to have a desktop environment which is horribly slow & heavy and that's usually not something you're after if you're actually using µGFX. µGFX has been designed to be extremely lighweight and fast. Running it inside a desktop environment brings very little benefits. Whenever you have a desktop environment that allows to run SDL2 application you already have some sort of GUI toolkit such as GTK or KDE. Usually the SDL port for µGFX is only used for development as it allows you to compile & run µGFX as a native application of your host machine. The same exists for Windows and other Unix systems.
So if you're using µGFX on your target because you need something that's extremely fast & lightweight you usally want to use the Linux Framebuffer driver. That driver allows µGFX to directly render into the framebuffer which the Linux kernel will display over some video interface. In that case you don't need any desktop environment, SDL or other package. µGFX compiles without any dependencies!
We don't have a guide specific for the beaglebone black wireless. However, these things always tend to be very similar. You can have a look at the RaspberryPi example as it will be very similar (that example uses the framebuffer driver as well): https://wiki.ugfx.io/index.php/Raspberry_Pi
I hope that helps. Please don't hesitate to ask if you have any further questions.
-
Hi & welcome to the µGFX community!
Your use-case & environment is definitely fully supported. µGFX has been designed to run on literally any platform. Your platform is very common among µGFX users.
I don't exactly understand what's keeping you from just using the 32-bit SDL2 package? It is not a "hack" or "workaround".
-
You'll handle the I2C stuff in the driver's board file just like with GDISP or any other driver stuff in µGFX.
-
You have to write what's called a Toggle driver for the GINPUT module.
There's no way to register an IRQ in the upper levels. You'll find information about this on this forum. It's still possible to hack it into the GINPUT driver though.
-
Glad to hear that you got it working
-
1 hour ago, Angus Schmaloer said:
But i couldn't find anything about flushing in the "stm32f401re_nuleo_ssd1306" example project.
That project will most likely use auto-flushing or timer based flushing which is simply a setting in gfxconf.h.
-
Can you post a screenshot that shows the problem?
Also, there are the high-level calls gwinHide() and gwinShow() which you should use. gwinSetVisible() is fine too though, but check the last parameter.
You should definitely not manually touch the flags. -
The SSD1306 is a flush-based GDISP driver. The driver maintains a framebuffer itself which needs to be copied to the actual display controller's framebuffer. That operation is called flushing. Try to call gdispFlush() after rendering. You will find configuration options for flushing in the configuration file and more information in this forum.
-
Yes, that's possible. With µGFX, almost anything is possible in these regards.
- You can use a pixmap which is only the size of the button, render the button and then blit the finished one to the actual framebuffer
- You can also implement full-screen double buffering
- You can also implement driver level double buffering
- You can also implement hardware supported double buffering
- ...
What works best (and what's possible) depends on the application, used platform, available resources and so on. There's no general guide to double buffering. In our daily work for customers we use all of the methods above. As always: The right tool for the right job. Each method has different advantages, disadvantages, requirements, complexities and so on.
You might also want to keep in mind that flickering can occur from different sources.
-
I don't want to disturb the conversation, I just feel like these two are worth mentioning/showing: They are both using µGFX on an STM32F407 with no external RAM:
-
The migration has been completed successfully. The online font converter is available again.
-
We're physically migrating the online font converter server to a different location. Therefore, the online font converter service will be unavailable for a couple of hours up to two days if things go wrong.
You can always use the offline font converter built into the µGFX-Studio.
-
You might need to increase the values of GMOUSE_ADS7843_FINGER_CALIBRATE_ERROR and GMOUSE_ADS7843_PEN_CALIBRATE_ERROR in your board file. They are currently set to 20 and 2. Those are the distances in pixels which the fourth control crosshair is allowed to have as tolerance after the calibration has been applied. 2 and 20 are some very low values. Try higher ones.
-
If you wrote the code for those functions but you're getting an undefined reference error you simply forgot to include the files in the compilation/linking process properly.
-
9 hours ago, Angus Schmaloer said:
Right now i only have the errors:
undefined reference to `gfxMillisecondsToTicks'
and
undefined reference to `gfxSystemTicks' .
But i guess i have to provide then myself, cuz the library doesn't know my uC.This will help: https://wiki.ugfx.io/index.php/BareMetal#SysTick
-
Thank you very much - we appreciate it!
I've added this to our internal ToDo list. -
uGFX-Studio v0.20 - Beta
in uGFX-Studio
Posted
Thank you very much for bringing this to our attention. I just fixed that.