Jump to content

Joel Bodenmann

Administrators
  • Posts

    2,660
  • 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.

×
×
  • Create New...