Joel Bodenmann
-
Posts
2,656 -
Joined
-
Last visited
-
Days Won
2
Content Type
Forums
Store
Downloads
Blogs
Posts posted by Joel Bodenmann
-
-
@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.
-
Just to clarify: The driver file (eg. gdisp_lld_ILI3820.c) will only call functions like write_data() and write_cmd(). However, the implementation of those functions need to be in the board file (eg. board_ILI3820.h). In the implementation of those functions in the board file you'll access your microcontroller's peripherals to talk to the display controller. Never access pins or SPI stuff directly from the driver file!
-
Quote
How can i change background page color without using background properties. If i using background,
first drawn white window, then the background is drawn.
That's currently not supported. Right now you can only place a solid rectangle yourself but as you mentioned that's rather inefficient. I've just added that to our ToDo list. Should be there in the upcoming release.
QuoteConsole do not save to project file.
After save then reload project console is missed on page.
We've added that to the bug list.
-
Hello and welcome to the µGFX community!
Is it possible that you forgot to assign the font on the GWIN level? You can either use gwinSetDefaultFont() to set a default font for all widgets or you can set a per-widget specific font with gwinSetFont().
-
Happy yo Help & Very glad to hear that :)
-
Regarding 1: Keep in mind that µGFX can still optionally run off one or more buffers. We have a lot of applications that use either hardware level double buffering or application level double buffering. We also have a lot of applications that use our dynamic arbitrary sized framebuffers called pixmaps.
-
I think you might want to give GWIN_FLAT_STYLING a try (set it to FALSE or GFXOFF).
Other than that you can always just create a custom rendering routine in your application instead of modifying library code: https://wiki.ugfx.io/index.php/Creating_a_custom_rendering_routine
-
Thank you for bringing this to our attention - We'll fix that ASAP!
-
We're happy to answer any specific question you have but please give the documentation a shot first.
-
Thank you for your feedback, @king2. We've updated our ToDo list.
-
You should also set GFX_COMPILER to GFX_COMPILER_KEIL if you're using Keil.
-
What you did is correct. But now you need to debug:
- Step through your application and see whether it hangs or crashes somewhere
- Make sure that your board file is implemented properly. Use a logic analyzer / osmelloscope to verify that the signals are correct
- The ILIxxxx drivers are known to be very difficult to handle in terms of different revisions and so on. Some of the chips are even labeled wrong. Check out the initialization sequence in the driver file (/drivers/gdisp/ILI9341/gdisp_lld_ILI9341.c) and compare it to the one that your manufacturer/supplier supplied with the module you bought.
-
Did you try to debug the application? Most likely it's hanging or crashing somewhere during initialization.
-
Well did you check the configuration file reference? --> https://wiki.ugfx.io/index.php/Configuration
Of course, each setting is also documented in-source code which makes it available in the API documentation: https://api.ugfx.io -
Hello and welcome to the µGFX community!
Did you check out the Eclipse guide in the wiki (and/or the guides for the various eclipse based IDEs)?
P.S. Next time please use code boxes in your post (I've added them).
Generic board file for ILI9341 and the Arduino IDE based on Adadruit's generic library supporting different boards
in User Projects
Posted
Thank you for sharing your progress & files with everybody - much appreciated!
µGFX can definitely do a lot better than that.
µ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.