Jump to content

Joel Bodenmann

Administrators
  • Posts

    2,620
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by Joel Bodenmann

  1. Hello & welcome to the µGFX community.

    Given that the library currently doesn't ship with a GDISP driver for the ST7789 I assume that you wrote your own.
    We'll try to address your issues as best as we can:

    • Speed: Make sure that your driver is setup correctly and that your host's SPI is configured to run at a decent speed. Check the corresponding datasheet(s) to determine the maximum allowed bus frequency that your physical driver and display module can handle.
    • Brightness: Not every display module uses features built into the physical controller for screen brightness control. Often you get a simple set of LEDs with which you can control the brightness via PWM. Check whether this is the case in your scenario. If so, changing any of the physical display driver configuration registers won't have any effect on the display brightness. You can setup a PWM peripheral in your GDISP driver's board file in order to still be able to use gdispSetBacklight() to control the brightness.
    • Full image: I'm not sure what you mean by this. However, this sounds again like an issue with your GDISP driver. I do not know which "LCD image converter tool" you're talking about. Image formats supported by µGFX are listed here: https://wiki.ugfx.io/index.php/Images

    It's difficult to help without being able to review the driver. If you're unable to share the driver publicly, you can get in touch with us for paid support.

  2. Hello & welcome to the µGFX community!

    Regarding your first compilation output: It seems like the corresponding features are not enabled in the configuration file (gfxconf.h). Most notably it seems like GDISP_NEED_TEXT and GWIN_NEED_TABSET.
    Did you use the configuration file that ships with the demo? If they are not enabled in there we certainly need to update that demo.

    The same seems to be the case with your second compilation output. It seems like some features such as text, circles and GINPUT are not enabled.

    Useful resources:

  3. Yes, the window manager will resize a widget to fit into the parent. This is where the inner size (inner width & inner height) come into play. Check the return values of gwinGetInnerWidth() and gwinGetInnerHeight() of the parent container. This will most likely return the values you initially reported. The WM has no other option but to resize the widget to fit those dimensions.

    If your child needs to have those exact dimensions, either make the parent container larger or implement a container which handles this the way you need it. I think the default built-in container has a border vs. no-border option (check the docs). I think if you disable the border the inner size will not be reduced by the border size.

  4. Hi,

    As of today, we do not provide python bindings. However, as this is a plain C library it would be very easy to do so. In fact, there have been successful efforts in providing a MicroPython wrapper in the past:

    We'd be more than happy to answer any question you might have when writing bindings. This would certainly be a great addition to the library!

     

     

  5. Hello & welcome to the µGFX community!

    If gfxAlloc() returns NULL, it indeed would indicate an issue with the memory layout/setup/capacity.

    You are setting GFX_USE_OS_CMSIS to GFXON. Are you actually using the CMSIS OS? Note that the CMSIS OS is a different component than the CMSIS library itself. If you're not using the actual CMSIS OS, you should select the proper OS instead - or use GFX_OS_RAW32 instead.

    After checking the OS situation: To further debug this, I'd recommend disabling the GDISP Module (setting GFX_USE_GDISP to GFXOFF in the configuration file) and trying to do various calls to gfxAlloc() in your main() right after gfxInit(). This way you can more easily figure out what is actually happening.

  6. We've made changes to the STM32LTDC driver. While the changelog and updated board files reflect the changes necessary this forum post attempts to provide an overview of the changes necessary for migrations:

    Peripheral clock setups
    The driver no longer implements the necessary logic to setup the clocks for the LTDC & DMA2D peripherals. Instead, the board file now contains the new functions:

    • void init_ltdc_clock(void)
    • void init_dma2d_clock(void)

    Prior to this change, the driver itself setup the clocks. This change was made to increase portability and remove any dependency of underlying HAL definitions for RCC.

    This change also makes the previously existing LTDC_NO_CLOCK_INIT option obsolete and was removed accordingly.

    Renaming existing configuration options
    For consistency reasons and easier upgrading to µGFX v3.x, the following changes were made to the configuration options:

    • ALLOW_2ND_LAYER -> STM32LTDC_USE_LAYER2
    • GDISP_LTDC_USE_RGB565 -> STM32LTDC_USE_RGB565
    • LTDC_DMA_CACHE_FLUSH -> STM32LTDC_DMA_CACHE_FLUSH
    • LTDC_USE_DMA2D -> STM32LTDC_USE_DMA2D

    Double Buffering
    The STM32LTDC now supports double buffering. This feature can be enabled via STM32LTDC_USE_DOUBLEBUFFERING.
    For more information on this, see the readme.md in /drivers/gdisp/STM32LTDC.

  7. I am working on reproducing this. Unfortunately, I was unsuccessful so far.

    Here's my simple test case following your pseudo code:

    #include "gfx.h"
    
    int main(int argc, char* argv[])
    {
    	(void)argc;
    	(void)argv;
    
    	gfxInit();
    
    	// Open image
    	gImage myImage;
    	gdispImageOpenFile(&myImage, "640x480.bmp");
    	
    	// Create pixmap
    	GDisplay* pm = gdispPixmapCreate(640, 480);
    	gdispGImageDraw(pm, &myImage, 0, 0, 640, 480, 0, 0);
    	
    	// #1: blit the entire pixmap on the display - works correctly
    	gdispGBlitArea(GDISP, 0, 0, 640, 480, 0, 0, 640, gdispPixmapGetBits(pm));
    	
    	// #2: Blit a partial pixmap on the display with source coord (0,0) - works correctly
    	gdispGBlitArea(GDISP, 0, 0, 200, 200, 0, 0, 640, gdispPixmapGetBits(pm));
    	
    	// #3: blit a region from the middle of the pixmap to the display (source coord != (0,0))  - PROBLEM!!
    	gdispGBlitArea(GDISP, 200, 200, 200, 200, 200, 200, 200, gdispPixmapGetBits(pm));
    	
    	// Close the image
    	gdispImageClose(&myImage);
    
    	// Keep the application alive
    	while (gTrue)
    		gfxSleepMilliseconds(100);
    
    	return 0;
    }

    When running this, the window (display) shows the image as expected without any defects.

    Am I missing something obvious here?
    For reference, here is a ready-to-run Win32 project with the code shown above and the corresponding asset(s): win32_blit_test.zip

  8. We're currently in the process of migrating our git server.
    Up until now, we were running Gogs but we're changing over to Gitea.

    Any user accounts with last activities older than 6 months will not be migrated to the new server.
    If you'd like to get an account on the new git server (once migration is completed) please get in touch with us.

  9. I haven't had time to check out your code  yet - just the video. Looking good!

     

    5 hours ago, uriy said:

    My aim was to show for other persons that it's possible to do. Because thay told before it's impossible.

    What was their reasoning that it wouldn't be possible?

    if you like we might be able to improve this together and eventually put it into the official µGFX library so it's supported out-of-the-box :) 

  10. Hi!

    As you stated the existing text edit widget only allows for one line of text.
    The proper way of doing this is creating a new widget called MultilineTextedit and implement the functionality. It might make sense to use the exsting Textedit widget as a base for this (i.e. copy-paste & modify).


    Other than the API documentation you can find documentation on creating your own widget here: https://wiki.ugfx.io/index.php/Creating_a_widget

    Alternatively we can implement the widget for via paid support.

  11. Hello & welcome to the µGFX community!

    Yes that is still true. If you purchased an µGFX 2.x unlimited commercial license you can still use any 2.x release without any additional costs. This also applies if it's a new/different project or product as long as the license holder noted on the licensing document is executing the development/sale.

×
×
  • Create New...