Jump to content

Joel Bodenmann

Administrators
  • Posts

    2,656
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by Joel Bodenmann

  1. Using the Makefile approach is very simple as the Makefile that ships with µGFX exposes variables for sources, include paths and libraries to link.
    See the corresponding documentation.

    Does your existing CubeIDE project already use Makefile? If so, follow the makefile documentation linked above. There's also an example for ChibiOS (not specific to CubeIDE but it shows how simple it is to add µGFX to an existing Makefile project).
    If your existing CubeIDE project uses CMake instead, the current master branch of the official µGFX repository (i.e. µGFX v2.10) supports CMake too.

    If you need more hands-on support, we can provide commercial support.

  2. µGFX supports file formats like BMP, GIF and PNG out of the box. You can directly load the encoded image. No need to use an image converter.
    You can use the NATIVE format but then you'll indeed have to do the conversion yourself.
    The easiest way to get an image is to include it in your firmware image. This can be done with the file2c utility that ships with the µGFX library. You can then use ROMF to display it.

    Have a look at the /demos/modules/gdisp/images demo to get started.
    Also, here's more documentation: https://wiki.ugfx.io/index.php/Images

    For the future, please make a separate forum topic/thread. This makes it much easier for other people to find answers to similar questions in the future :)

  3. Great that you got the new driver working so quickly - nice work!

     

    15 minutes ago, dynfer said:

    //Update the issues were caused by my DMA2D clocks not being initialized. Afterwards its working as expected.

    Does everything work properly then? :)

    The font looks a bit funky but maybe that's just the font. You can always test with the built-in DejaVu fonts first to confirm that it's working as intended.

  4. So, generally the good news is that once you see something on the screen (anything, even if it's distorted), you're generally in good shape. It's usually harder to get to the point where you're no longer staring at a black screen.

    First of all, I would recommend that you use the current `master` branch of the official µGFX v2 git repository: https://git.ugfx.io/ugfx/ugfx
    One of the notable changes after the v2.9 release was a rework of the STM32 LTDC driver.
    You can (and should) read more about the changes here: 

    I think it's wasted effort to debug the issue you're currently having with the old driver. I'd suggest that you get it up and running with the new driver and then we figure out what isn't working for you.

    Don't hesitate to ask if you have any questions. We're happy to help wherever we can.

  5. No worries, we'll do it then :)
    We mainly asked because this way author information can be incorporated into the git history which is something some contributors care about.

    I'll try to get this done this week but I need to setup a test case to reproduce the issue and testing your fix first.

  6. This sounds good - thank you for having investigated this!

    If you are able/willing to provide a patch (such as git format-patch) we could apply your fix directly to the repository (and have you credited as the author).
    If possible, adding a comment or two in the source code wouldn't hurt either :) 

  7. Hello & Welcome to the µGFX community!

    µGFX accesses display hardware via the so-called "board file". Each display driver has a file named board_xxx_template.h where xxx is the driver name.
    In your case, that would be /drivers/gdisp/ILI9341/board_ILI9341_template.h. Simply copy that file to your project and rename it to board_ILI9341.h.

    In that file, you will find the various functions the driver needs to access on the hardware/peripherals to talk to the display controller - you'll have to implement those functions to work with your ecosystem (i.e. Arduino) and your hardware. So technically, that is where the pin assignments go.

    You can find an example under boards/addons/gdisp/board_ILI9341_spi.h
    While that is written to work with ChibiOS, it should still give you an idea of what you need to do (toggle GPIOs, make SPI transactions etc).

    As for the repository you linked - That seems to be 10 years old. I am not saying it won't work, but also from an understanding/learning perspective, it might be best if you start from scratch and import whatever you need.

    Please don't hesitate to ask if you have any questions - we're happy to help wherever we can.

     

  8. Hi!

    Have you tried just running the unmodified example found under /demos/modules/gwin/button ?

    With regards to calibration: You would typically only ever do that once (or if you build a full application, have some "settings" menu where the user can re-launch the calibration sequence). Once calibration was performed, you'd typically store the calibration data and load it on power-on.
    Have you had a look at the corresponding documentation? https://wiki.ugfx.io/index.php/Touchscreen_Calibration

  9. 4 minutes ago, Timmy Brolin said:

    since it uses the generic streaming functions in gdisp which are already optimized for many types of drivers.

    Does that mean your patch changes font rendering (the actual painting) to use gdispGStreamStart(), gdispGStreamColor() and gdispGStreamStop()?
    And then on top of that giving gdispGStreamColor() an additional "count" parameter?

    Apologies if I'm way off here - totally buried at the moment.
     

  10. We had a short internal discussion about this. We'll gladly have a look at your patch but we'll need a bit more time as we're quite busy at the moment.

    In general, we're quite keen on this additional/improvement if it is not restrictive to a particular type of driver.

  11. You seem to have been patient with me.... thank you :D

    In your initial post you mentioned that the problem you're encountering happens when changing pages.
    Is this by any chance related to this?

     

  12. Hello & welcome to the µGFX community!

     

    On 13/09/2024 at 12:10, Timmy Brolin said:

    The root cause of the flicker is that they start by doing a background fill, and then render the text on top of that.

    Is there not a better way to do it?

    This is a common issue with graphics rendering not only specific to font rendering. Common solutions include:

    • Render the entire element before pushing it to the framebuffer. In µGFX terms that would mean rendering into a pixmap and then blitting to the real display.
    • Using global double buffering: You render to an off-screen buffer and once your rendering operation(s) are complete you swap the display's framebuffer.

     

    On 13/09/2024 at 12:10, Timmy Brolin said:

    Would it not be possible to modify "skip_pixels()", so that it draws background color to the screen for all alpha=0 pixels when gdispGFillString() / gdispGFillStringBox() are used?

    That way the initial fillarea(g) could be removed, and the flickering should be gone. Without the need for any double buffering.

    I'll need some time to get back to this as it has been a while since I was last digging in the internals of font rendering.
    One thing that comes to mind is that fillarea() tends to be a fast operation as this is an operation commonly supported by hardware acceleration.

    If you can propose a patch that handles the kerning issue I'd be more than happy to look into it.

     

  13. Hello & Welcome to the µGFX community!

    The µGFX library can be integrated into an existing project through four different mechanisms:

    • CMake
    • Makefile
    • Single-File-Include
    • Manually adding all files the old fashioned way

    See https://wiki.ugfx.io/index.php/Getting_Started for more information

    STM32 CubeMX allows to generate projects using either Makefile or CMake - the latter being a very recent addition.

    I'd recommend that you get a basic project up and running without including µGFX to make sure that your environment & tooling are working as expected. Once you have a working project, you can include the µGFX library using any of the available mechanisms. In your case that will most likely be via Makefiles.

    Don't hesitate to ask if you have any questions. We're happy to help wherever we can.

×
×
  • Create New...