Jump to content

Joel Bodenmann

  • Content count

  • Joined

  • Last visited

  • Days Won


About Joel Bodenmann

Recent Profile Visitors

6,241 profile views
  1. How to do a screen dump in my application.

    I'd just like to add that µGFX still has everything you need to read back the framebuffer. So if you GDISP driver and/or your hardware supports it, you can use GDISP high-level API to read back the framebuffer and write it to an image. Another alternative for a GWIN based application is to render everything into a pixmap. If you have a top-level container you can just change the display pointer to render into the pixmap. The pixmap itself already supports writing to an image. Here's a forum post regarding rendering to GWIN stuff to a pixmap:
  2. Gwin vs Gwin_widget

    To save a lot of resources (especially RAM and also CPU time).
  3. Flicker

    This is the relevant code taken from the µGFX-Studio v0.22.4: void UGfxWindow::setDisplay(GDisplay* g) { if (!_ghandle) { return; } // Nullptr means default/standard display if (!g) { g = GDISP; } gwinHide(_ghandle); _ghandle->display = g; gwinShow(_ghandle); } _handle is the GHandle.
  4. Flicker

    There's no hacking involved. You just need to change the GDisplay* pointer. We did the same thing for the µGFX-Studio.
  5. Flicker

    Hi, The most common solution is (as you mentioned) double buffer. However, proper double buffering is very hard to implement and also requires hardware support. While µGFX can fully support double buffering (with the multiple displays API) we do also provide you with a more flexible way: Pixmaps. You can simply render your widget into a pixmap and then blit that pixmap to your real display. Pixmaps have certain advantages over real double buffering. The most notable is that you don't need two times the memory for the entire display area - a pixmap can be just a small portion of the screen. Other than that there are other things which vastly improve these sort of things such as anti-tearing-effect flags and so on. But all of that needs to be supported by the hardware.
  6. uGFX-Studio v0.20 - Beta

    v0.22.4 is available for download. Changelog: Fixing issues with default GWIN settings (default font and default widgetstyle) Fixing crash when modifying target properties in certain situations Many internal improvements regarding code generation
  7. uGFX-Studio v0.20 - Beta

    Hello @baris, Please read the instructions given in the bright red box at the download page.
  8. NUCLEO-F746ZG + 7" SSD1963 16-bit FMC

    The SSD1963 has an R/S pin which is used to tell the display controller whether the incoming data is configuration data or actual pixel data. This is done so that you don't need to wire up all the address pins in order to address each pixel individually (and each configuration register). The two macros above are used to access the SSD1963's memory, one time with R/S set to 0 and one time set to 1 - essentially giving you the option to write pixel data or configuration using "stock FSMC" without having to manually control the R/S pin via a GPIO. You need to ensure that the macro which sets the R/S pin has the correct address. So if you hooked the R/S pin up to FSMC_A16 you need to sure that GDISP_RAM has address bit 16 (the 17th bit) set to 1. FSMC is usually extremely straight forward and there is little that can go wrong. Just make sure that you use low timings until everything is working. Then you can ramp them up. But usually you want to be somewhere in the range of 10k to 100k until everything works. Also make sure that your pins are setup correctly (that the correct pins are being set to alternate function and so on). The most difficult part with the SSD1963 is getting the panel parameters correct. Make sure that you always at least tripple-check them. Those parameters are different for each panel. You should get a table of values together with your panel. However, note that the parameters you get are not always the ones you need to enter into that parameter struct. They are often calculated differently. I know that this post isn't as helpful as you might have wished for but there's not much we can do. FSMC is pretty much self contained: It's all about accessing a memory region. Everything else is up to your hardware and proper pin configuration. Simply tripple-check everything, take a break and do it again. Also, you definitely want to use a scope or logic analyzer to have a peek at those FSMC pins. Keep in mind that you can test the FSMC outside of µGFX. All that FSMC is doing is accessing a memory region. Therefore, you can setup your pins and just try accessing the SSD1963 with the two macros above - no magic involved. You can then just make call to the one with R/S = 0 and one with R/S = 1 in the main loop and use a scope or logic analyzer to verify that the correct pin is toggling.
  9. What type of GWidgetObjset is it?

    GWidgetObject is the base widget call: https://git.ugfx.io/uGFX/uGFX/src/master/src/gwin/gwin_widget.h#L109 You don't usually worry about those as you always access them using the GHandle. Edit: Yes, GWidgetObjset is definitely a spelling error.
  10. STM32F446 + ILI9341 (by STM32F4 to ILI9341 using uGFX)

    Hello Bilymo, I don't understand what you're trying to say. The µGFX library is by far the most portable and agnostic library out there. You can run µGFX on virtually any platform and with any driver. The Keil guide clearly states that the example uses the SSD1289 driver but that it's the same process for any other driver: We cannot provide a guide / tutorial for every possible configuration out there. If you need to use the ILI9341 driver just follow the SSD1289 example but pick the ILI9341 driver. We're open to any kind of feedback regarding the documentation. If you feel that you have some improvements to share we're happy to hear them. But we surely aren't going to write guides for every possible combination.
  11. uGFX-Studio v0.20 - Beta

    Uhm... but that shouldn't happen. Cleaning the project should only remove the output directory. Is it possible that you didn't assign the resource? Because unused resources are being removed as well.
  12. STM32F469I-Disco + SW4STM32 + uGFX-Studio

    It doesn't seem like you even added the image to the µGFX-Studio project. Works fine here:
  13. uGFX-Studio v0.20 - Beta

    Hello @Connel and welcome to the µGFX community! 1) The built-in window manager of µGFX doesn't support overlapping windows. You have to write your own if you need that. 2) Yes, there is. Custom rendering functions and custom widgets. The former is supported by the µGFX-Studio but not well tested yet. The latter should follow soon. 3) Regarding the minor issue: Are you talking about the resources folder of the µGFX-Studio project or the one that gets generated when you generate the code?
  14. STM32F446 + ILI9341 (by STM32F4 to ILI9341 using uGFX)

    I currently don't have access to a running Keil instance. Can you please show us screenshots of the relevant parts (file tree, compiler path settings, ...). The error message you're getting indicates that you didn't properly add the path to the driver directory to the compiler include path list:
  15. STM32F469I-Disco + SW4STM32 + uGFX-Studio

    I don't find any µGFX-Studio project file in there. I don't see how this is related to the µGFX-Studio.