Jump to content

All Activity

This stream auto-updates

  1. Last week
  2. Hello & Welcome to the µGFX community! Unfortunately, the µGFX-Studio is currently not publicly available.
  3. Earlier
  4. NawzaAwan

    studio gfx

    hi, how can i download studio-ugf ?
  5. 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: https://badge.emfcamp.org/wiki/TiLDA_MK3/ugfx https://github.com/pypilot/micropython_ugfx https://github.com/SHA2017-badge/Firmware 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!
  6. Is there some guidance on how to call the uGFX package from Python? Do we have to create our own binding library, or has someone a (shared) project where we can build upon?
  7. @inmarket and I revisited this today. Both problems you reported are now fixed by these commits: 1235a9056c8324c5552f739114343b3e91dc15fb 7845f44f20034779d7d3c969750279297ff524ce Thank you for reporting these! Your contribution were noted in the corresponding commit messages.
  8. Took a bit longer than expected to get to this but yeah: This is definitely a typo. Fixed in commit 888c7e8640caf02082adc23c967c5c0ba49a5146 Thank you for reporting this! There were some other improvements to the STM32LTDC driver in the meantime (which is why getting to this took a bit longer):
  9. 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.
  10. I am developing ugfx_2.9 for a DIY product. Keil uVision is used and the main MCU is nRF52840. 1. The display uses E-ink's ET011TJ2. Is the driver IC correct for UC8173? 2. However, g->priv = 0 in the initialization function of <gdisp_lld_UC8173.c> as follows. So return gFalse; proceed with As a result, the initialization routine does not proceed. sizeof(UC8173_Private) = 14412 How can I initialize normally? 3. I tried changing HESP_SIZE in various ways as follows. But in all cases g->priv = 0 . #define GFX_OS_HEAP_SIZE 14412 //0 //4095 //20480 // 30720 //10240 //10240 //40960 4. I have set it up like this: #define GFX_EMULATE_MALLOC GFXON Still, g->priv = 0. Since g->priv = 0 unconditionally, the initialization function cannot proceed. How to solve it? <gfxconf.h> /////////////////////////////////////////////////////////////////////////// // GOS - One of these must be defined, preferably in your Makefile // /////////////////////////////////////////////////////////////////////////// //#define GFX_USE_OS_CHIBIOS GFXOFF //#define GFX_USE_OS_FREERTOS GFXOFF // #define GFX_FREERTOS_USE_TRACE GFXOFF //#define GFX_USE_OS_WIN32 GFXOFF //#define GFX_USE_OS_LINUX GFXOFF //#define GFX_USE_OS_OSX GFXOFF //#define GFX_USE_OS_ECOS GFXOFF //#define GFX_USE_OS_RAWRTOS GFXOFF //#define GFX_USE_OS_ARDUINO GFXOFF //#define GFX_USE_OS_KEIL GFXON //#define GFX_USE_OS_RTX5 GFXOFF #define GFX_USE_OS_CMSIS GFXON <<<======= //#define GFX_USE_OS_CMSIS2 GFXOFF //#define GFX_USE_OS_RAW32 GFXOFF //#define GFX_USE_OS_ZEPHYR GFXOFF //#define GFX_USE_OS_NIOS GFXOFF //#define GFX_USE_OS_QT GFXOFF // #define INTERRUPTS_OFF() optional_code // #define INTERRUPTS_ON() optional_code // Options that (should where relevant) apply to all operating systems // #define GFX_NO_INLINE GFXOFF // #define GFX_COMPILER GFX_COMPILER_UNKNOWN // #define GFX_SHOW_COMPILER GFXOFF // #define GFX_CPU GFX_CPU_UNKNOWN // #define GFX_CPU_NO_ALIGNMENT_FAULTS GFXOFF // #define GFX_CPU_ENDIAN GFX_CPU_ENDIAN_UNKNOWN #define GFX_OS_HEAP_SIZE 14412 //0 //4095 //20480 // 30720 //10240 //10240 //40960 <<<======= // #define GFX_OS_NO_INIT GFXOFF // #define GFX_OS_INIT_NO_WARNING GFXOFF // #define GFX_OS_PRE_INIT_FUNCTION myHardwareInitRoutine // #define GFX_OS_EXTRA_INIT_FUNCTION myOSInitRoutine // #define GFX_OS_EXTRA_DEINIT_FUNCTION myOSDeInitRoutine // #define GFX_OS_CALL_UGFXMAIN GFXOFF // #define GFX_OS_UGFXMAIN_STACKSIZE 0 // #define GFX_EMULATE_MALLOC GFXON <<<======= // #define GFX_MEM_LT64K GFXOFF <gdisp_lld_UC8173.c> LLDSPEC gBool gdisp_lld_init(GDisplay* g) { UC8173_Private *priv; printf("UC8173:gdisp_lld_init - 1 HEAP = %d\r\n", GFX_OS_HEAP_SIZE); // Allocate the private area g->priv = gfxAlloc(sizeof(UC8173_Private)); <<<======= printf("UC8173:gdisp_lld_init - 2 memAlloc = %d, sz = %d\r\n", g->priv, sizeof(UC8173_Private)); <<<======= if (!g->priv) return gFalse; priv = (UC8173_Private *)g->priv; gfxconf.h
  11. 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.
  12. Here's the `gdisp_lld_Win32.c` file I was using for this test (this is the same as in the current `master` branch): gdisp_lld_Win32.c That sounds like something worth contributing
  13. Thanks for taking the time to look into this! Just to be sure, can you also attach a copy of the gdisp_lld_Win32.c file you are using to test? I have implemented the fixes in my copy of that file, but I have also implemented some other mods such as scaling/stretching/minimize/maximize on the win32 canvas, as well as window styles), and it would help to be able to do a before and after comparison.
  14. 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
  15. I might have a look at this in the meantime. Could you provide the exact font you used (ideally both the font source file (if possible due to licensing) as well as the output of the font converter).
  16. Still looking if there's a solution for this
  17. 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.
  18. Thank you for bringing this to our attention. Any form of feedback & possible bug report is welcomed I'll be working the STM32LTDC driver in an upcoming project (few days/weeks from now). I will look into it then.
  19. I think for the sake of time I will have to respond in pseudocode: //create a display and clear it to all white disp = createDisplay(800, 480) clearDisplay(disp, WHITE) //create a pixmap and fill it with an image pm = createPixmap(800, 600) img = loadImage("puppy.png") //an 800x480 (full-screen) image drawImage(pm, img) //blit the entire pixmap on the display - works correctly blit(disp, pm, 0, 0, 800, 480, 0, 0) //at this point, the display contains the entire image //blit a partial pixmap on the display with source coord (0,0) - works correctly blit(disp, pm, 0, 0, 200, 200, 0, 0) //at this point, the display still contains the entire image, and we re-drew the top left 200x200 pixels //blit a region from the middle of the pixmap to the display (source coord != (0,0)) - PROBLEM!! blit(disp, pm, 200, 200, 200, 200, 200, 200) //If all was working correctly, at this point, the display still would contain the entire image, //and we would have now also re-drew the middle 200x200 pixels. But... //Due to bug #2 above: when the stock code is run with rotation = 0, the line of code labelled //PROBLEM will cause a cras hbecause the buffer is erroneously freed (see bug #2 description above). //when the fix for the free bug (#2) is applied, there still is a drawing bug. //Due to bug #1 above, the code labelled PROBLEM will now draw the wrong region of the image onto the display //because the source pointer computation does not take into account the supplied source horizontal offset. **For both cases, the fixes are above.
  20. Line 545 of gdisp_lld_STM32LTDC.c currently reads: srcstart = LTDC_PIXELBYTES * ((gU32)g->p.x2 * g->p.y1 * + g->p.x1) + (gU32)g->p.ptr; Given that the operator "* +" clearly compiles but is nonsense, the correct line of code should be: srcstart = LTDC_PIXELBYTES * ((gU32)g->p.x2 * g->p.y1 + g->p.x1) + (gU32)g->p.ptr; I think this is a plain and simple typo, but it has been there since uGFX 2.7 or earlier. This means the srcstart (the starting address of the blit source) is not being calculated correctly. I believe the reason this slipped passed the radar in v2.7 is that, for some unknown reason, this same calculation was repeated (without the typo) in line 578, where DMA2D->FGMAR was set to the source address. So in 2.7, the only time the erroneous value was used was in cache flushing and invalidation. In the latest (2.9 release and guthub) version, the erroneously-calculated srcstart is being used directly to set FGMAR (as it should), but due to the typo, the resulting blit regions are copying essentially from random areas as their source. As for reproduction steps, any blit from a pixmap to the display will calculate incorrectly except for, I suppose, blits with a source of (0,0) and a few other lucky combinations. I just thought I would report this to be helpful.
  21. Thank you for bringing this to our attention! Can you supply a minimum test-case that allows reproducing the bug(s) and corresponding patch(es)?
  22. The gdisp_lld_blit_area() function is broken in a few ways, both to do with blits whose source X coordinate is non-zero: 1. The following line is intended to compute the source array for the blit operation, but doesn't take into account the source offset. buffer += g->p.x2*g->p.y1; It should be changed to something like: buffer += g->p.x2 * g->p.y1 + g->p.x1; 2. Near the bottom of the function, the following code is intended to detect if a rotation has been done (thereby changing the buffer variable from the pixmap base buffer to a freshly allocated, rotated buffer: buffer = g->p.ptr; buffer += g->p.x2 * g->p.y1 + g->p.x1; //STUFF if (orientation needs to change): buffer = rotateimg(g, buffer); //STUFF if (buffer != (gPixel *)g->p.ptr) free(buffer); The problem is that after setting buffer to the pixmap base array at the top of the function, it is tweaked by horizontal and vertical offsets to a new value representing the top left of the source image, but is still located in the original pixmap buffer. This means that if your source x or y offsets are non-zero and rotation is not required, it will erroneously decide that is has rotated the image and needs to free the array, causing a crash (free an invalid memory pointer). It should be fixed to something more like: buffer = g->p.ptr; buffer += g->p.x2 * g->p.y1 + g->p.x1; bufferBase = buffer; //STUFF if (orientation needs to change) buffer = rotateimg(g, buffer); //STUFF if (bufferBase != buffer) free(buffer);
  23. uriy

    Multiline textedit

    I think their reason was to save time and implement it as is right now from the box. Be honest collaboration like that is interest for me, but right now I have not enough time. I hope to return to that later.
  24. I haven't had time to check out your code yet - just the video. Looking good! 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
  25. uriy

    Multiline textedit

    I did some work. Maybe it will usefull for somebody, you can find sources here https://bitbucket.org/only_uriy/ugfx_multiline/src/master/ There is new widget multilinetextedit. It's not completed, cursor is not redrawing at mouse click position. And there are other several prerequisites, which make it not ready to use by all. My aim was to show for other persons that it's possible to do. Because thay told before it's impossible. In attachements you can find main.c for test project and video how it looks. 783700217_Untitled14.avi TestProject.7z
  26. For paid support options/discussions, please contact us via e-mail: info@ugfx.io
  1. Load more activity
×
×
  • Create New...