Joel Bodenmann
-
Posts
2,620 -
Joined
-
Last visited
-
Days Won
2
Content Type
Forums
Store
Downloads
Blogs
Posts posted by Joel Bodenmann
-
-
On 01/06/2018 at 08:21, AlexK17 said:
Issue where the maximum display size couldn't be larger than 640 x 480px,
not FIXED.
All widgets whose y-axis coordinates are greater than 480, after loading the project, are located above this coordinate.We'll investigate this.
On 01/06/2018 at 09:11, AlexK17 said:To background style, it would be nice to add a text primitive.
Added to the ToDo list.
-
12 hours ago, Paul Christopher said:
Thank you, inmarket and Joel! I have now implemented the fillrect function used in the Adafruit library as GDISP_HARDWARE_FILLS, and indeed, it is much faster now. All in all, I'm quite happy with the performance: Clearing the screen with a certain color takes 33ms on the ESP32 using SPI.
Nice, glad to hear that you got everything working!
We'd appreciate it if you could create a ready-to-run example for the downloads page and maybe some documentation for the wiki.12 hours ago, Paul Christopher said:What would be a good example in the code base to test whether multithreading / scheduling really works with my patch?
Have a look at /demos/gos.
12 hours ago, Paul Christopher said:Is this the time for me now to dive into GWIN? Or for what is the ugfx scheduler actually used?
The scheduler is also used for things like GTIMER which in turn is used by GINPUT and GWIN. As mentioned above, /demos/gos should help.
-
Version 0.23.1 has just been released. Changelog:
- Updating About dialog
- Changing default font generator size from 8px to 16px
- Fixing issue where console widget isn't loaded from project file
- Fixing issue where the visible attribute affected the enable attribute
- Fixing issue where the generated calibration code contains syntax errors (missing commas)
- Fixing an issue where the maximum display size couldn't be larger than 640 x 480px
- Fixing an issue where using the mouse wheel on the zoom slider didn't update the actual zoom factor
- Fixing some resource files issues
- Fixing issues with dialog box close events
- Adding new bugs with dialog box close events to fix later
-
I'd recommend you to have a look at the buffer in the GConsoleObject object (cast from GHandle).
-
1 hour ago, krisPainkiller said:
The reading are very responsive though not much accurate on the four angles of my touch screen.
https://wiki.ugfx.io/index.php/Touchscreen_Calibration#Extreme_coordinates
1 hour ago, krisPainkiller said:I've also tested the touch_driver_test demo using its tunings and calibrations but the readings aren't responsive at all. It is very difficult to calibrate the touch screen with this demo for me.
What do you mean by "not very responsive"? What's the behavior in a regular GWIN application like?
-
That's interesting.
Could you please leave some detailed information of the compiler you're using and also your build flags?
4 hours ago, Rafael Zingler said:This problem only happens when I use the console during startup.
What does that mean? Can you please give some more details?
-
Have a look at the /demos directory. Especially /demos/tools in your case.
-
Nice, much appreciated!
-
Welcome to the µGFX community!
Happy to hear that you managed to get things up and running
-
Hello and welcome to the µGFX community!
Unfortunately, there isn't an existing GINPUT driver for that touch screen controller. However, it's very easy to add a new one. Take the existing drivers as an example. You can simply copy the one who matches your controller the best (eg. don't take the ones which use the microcontroller's ADC to determine the touch coordinates) and modify from there.
The entire driver interface is well documented in the corresponding GINPUT documentation.Please don't hesitate to ask if you have any questions - we're happy to help wherever we can!
-
Thank you for bringing this to our attention. I've modified the documentation accordingly.
-
On 22/05/2018 at 20:45, inmarket said:
Use radio widgets with the button draw routine.
Correction: Use the checkbox widget, not the radio widget.
15 hours ago, king2 said:Can you tell when new Studio (without 640px width limit) could be expected?
We don't have any fixed release cycle. We can basically release at any time. I guess we can fire something up this or next week.
-
Welcome to the µGFX community & thank you very much for your feedback!
On 22/05/2018 at 16:31, eco said:- a grid option to place elements
Added to the todo/wish list.
On 22/05/2018 at 16:31, eco said:- markers to show alignments between elements (when borders of elements are aligned, a line in the designer is shown)
Added to the todo/wish list.
On 22/05/2018 at 16:31, eco said:- align tool (left, top, right, bottom,center, middle ) that works between label and edit of same height
Unless I'm misunderstanding you that should already exist (and work). Select multiple items and have a look at the context menu.
-
Thank you for sharing your progress & files with everybody - much appreciated!
On 20/05/2018 at 22:50, Paul Christopher said:I'm just wondering about the performance: Drawing a blue solid rectangle all over the screen takes the original Adafruit GFX library 270ms, µGFX with my Adafruit based board file 512ms.
µGFX can definitely do a lot better than that.
On 20/05/2018 at 22:50, Paul Christopher said:Am I doing something wrong? Is there a way to speed this up? The original Adafruit library seems to have special functions for drawing a rectangle (with no equivalent in µGFX -- sorry for the silly newbie questions?).
µGFX does provide those kind of features as well (in a much bigger scope even). We basically call those "hardware acceleration". There are a number of functions that a GDISP driver can implement to use hardware acceleration. For rectangles that would be the `fill area` function. You can have a look at existing drivers. As you'll see it's simply a matter of turning the hardware support for a feature on in the drivers configuration file and then implementing the corresponding function.
Have a look at the ST7735 driver for an example. You can see that GDISP_HARDWARE_FILLS is enabled in the drivers config file (gdisp_lld_conf.h) and that the drivers implementation file (gdisp_lld_ST7735.c) is implementing the corresponding hardware filling function named gdisp_lld_fill_area().
The actual implementation of such a function varies a lot. Some display controller have a simple command which takes X, Y, width, height and color while other drivers rely on using DMA and similar techniques to speed things up. -
@David Thomas is correct. You're missing some board support package files.
You will find that µGFX also supplies those as part of the board files for the STM32F746 Discovery board files. You can find them under /boards/base/STM32F746-Discovery. Just add the appropriate files that you're missing (most notably the SDRAM ones) and you should be ready to go
After all, board files are completely application specific. You're not forced to use what you find in the /boards directory. If you're using another framework you can either use their board files (if they exist already) or create your own. Board files are just there to give the µGFX driver(s) access to the actual hardware. You'll find a board file template in each driver directory (eg. /drivers/gdisp/STM32LTDC in your case) which you can implement however you want using whatever you want.
-
Hello @cchilumbu and welcome to the µGFX community!
This topic is very old and there has been a lot of improvements in all corners of µGFX. Please make sure that you're using the latest master branch from the official git repository. If you keep having problems, please don't hesitate to open a dedicated forum topic to ask your questions. We're happy to help wherever we can
-
You will definitely get a lot better performance when using FSMC. We strongly recommend that you do so.
It's quite "common" that the FSMC can go faster than the slave (the display controller in this case). For this, the FSMC has plenty of timing registers to make sure that everything stays within the interface specs you can review in the display controller's datasheet. -
Thank you for bringing this to our attention!
-
On 15/05/2018 at 19:23, Paul Christopher said:
By the way: How to deal with the initialization of multiple displays of the same kind in the board file?
That what's the board field in the GDisplay struct is there for. See https://wiki.ugfx.io/index.php/Multiple_displays#Board_files
So what you propose to do is fine, just use the existing g->board integer.
-
Did you perform a clean compilation? This should definitely work. There's not much that can go wrong.
-
Yes that's possible. The existing keyboard widget (virtual on-screen keyboard) has an interface that allows to load custom layouts. You can add whatever keys you want in whatever layout you want. Furthermore, you can use custom rendering functions to make it look the way you want - all without touching any of the logic!
-
Word wrapping is supported: https://wiki.ugfx.io/index.php/Font_rendering#Word-Wrapping
The existing rendering functions for the label widget take a justification value as the param and use word wrapping internally if it's enabled in the configuration file.
-
Uhm... what exactly is the problem/issue you're experiencing?
-
Hello & Welcome to the µGFX community!
On 12/05/2018 at 21:41, Paul Christopher said:When init_board is called, I simply create a new instance of the Adafruit class and store it to g->board = new Adafruit_ILI9341(GDISP_PIN_CS, GDISP_PIN_DC, GDISP_PIN_MOSI, GDISP_PIN_CLK, rst, miso) so that I can work with it.
You should use the private area of the GDisplay structure instead (g->priv) for these sorts of things. g->board is used to identify the board if using multiple displays at once.
On 12/05/2018 at 21:41, Paul Christopher said:Alas, there is an unsolved problem which keeps me from debugging the application and testing it with different boards. It is a problem related to C and C++ intermingeling: The compiler throws the error "unknown type name 'class' class Adafruit_ILI9341". I have already tried different things (extern "C"...) but is doesn't work out for me.
You need to write an intermediate wrapper. You need to call pure C functions from the driver file (which is C code). Those "pure C functions" can be implemented using C++ however. I'd recommend you to have a look at /drivers/gdisp/QImage to get an idea. We did the same there to interface Qt's QImage class in C++.
On 12/05/2018 at 21:41, Paul Christopher said:By the way: https://wiki.ugfx.io/index.php/Teensy seems to be outdated? I think the way to go is like shown in µgfx/boards/base/ArduinoTinyScreen?
We're very happy if you'd like to participate and update existing or create new documentation. An Arduino specific page would be very welcomed.
I hope this helps.
uGFX-Studio v0.20 - Beta
in uGFX-Studio
Posted
Released v0.23.2 that fixes the 480x640 pixel placement issue.