All Activity

Need more traffic? [url=https://seo-sea.marketing/service/]Our agency[/url] help businesses to drive conversions through custom digital marketing strategies. We use data-driven strategies to maximize your ad spend and generate consistent leads. We optimize every campaign for maximum ROI and visibility. We help you reach the right audience at the right time. You’ll gain a competitive edge with our full-service digital marketing approach. Let’s build a strategy that works for your unique goals.

The problem with adding the attribute tag is that it is a compiler specific solution. This means that adding the attribute actually breaks the code for other compilers. The solution of course is to make a compiler specific macro that defines it as the attribute where possible and defines it as blank otherwise. There are lots of optimiser style bugs that exist and each compiler, and every optimisation level, is different. GCC is particularly bad, or atleast it was a few years ago when I was playing with this stuff. It is often hard to find bugs that are not source bugs but rather optimiser bugs. In summary, well done on finding this, and especially in finding a solution. When Joel or I find a moment we will add a suitable "no-inline" macro to these calls.

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.

Hi, we are using version 2.9 of the uGFX library compiled with single file inclusion in STM32's CubeIDE. We would like to use Pixelmap. As stated in the wiki, the inclusion of this library does not work in ‘single file inclusion’ which is the mode we have been using. Is there a clear procedure explaining how to use the Makefile with our IDE, or is there an uGFX update available that solves this problem? Alternatively, I would like to ask if there is a method to implement the use of a virtual frame buffer, as I understand that the Pixelmap serves to this purpose. Thank you

_gfxGetStackState and _gfxGetStackStateInFn are not guarded against inlining wich breaks the detection algorithm in some cases. Not having them static helps but is far from a garanty. I have hit this isse with -flto -Oz on gcc for example. A __attribute__ ((noinline)) fixed it.

Excellent! Отлично!

Awesome - Thanks! This has now been merged into the master branch: https://git.ugfx.io/uGFX/ugfx/commit/02cbcea9e5b882f35b33f079340925a511b78acb Will do a v2.10 release this week.

Hi, Joel! I tested the patch for more than a day on two devices. Everything works stably as expected and there were no problems.

µ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

For now everything seems to work fine :). The font disortion was caused by the DMA2D not working. Now its looking good. However the questions are not over I want to test an image, I've used "lcd-image-converter" to generate a byte array, I've included the header as the first 8 elements like follows: 0x4E, 0x49, (1024 & 0xFF), ((1024 >> 8) & 0xFF), (600 & 0xFF), ((600 >> 8) & 0xFF), (0x2565 & 0xFF) But I struggle to find the correct function to draw it.

Great that you got the new driver working so quickly - nice work! 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.

Thanks I've did the switch with the results in the attachments, I've also changed the font size to 32 to show the defects better. Additionally gdispGFillArea(g, 0, 0, 1024, 600, Blue) doesnt seem to work. //Update the issues were caused by my DMA2D clocks not being initialized. Afterwards its working as expected.

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.

Hello Joel, Thanks for responding! Im using 2.9 release from the main website. The board in question is an Alieexpress dev board featuring an h743/256Mbit SDRAM and LTDC screen. As for ChibiOS its the current master branch v21 //Update, the following code results in the following #include "ch.h" #include "hal.h" #include "gfx.h" #include "gfx_thread.h" GListener glistener; static gdispImage myImage; static THD_WORKING_AREA(waGUI, 512); static THD_FUNCTION(GUIThread, arg) { (void)arg; gfxInit(); geventListenerInit(&glistener); gwinAttachListener(&glistener); const font_t font = gdispOpenFont("DEJAVUSANS10"); GDisplay * g = gdispGetDisplay(0); while (true) { chThdSleepMilliseconds(200); gdispGClear(g, Black); gdispGFlush(g); gdispGDrawString(g, 20, 20, "Hello from ChibiOS with UGFX", font, Yellow); gdispGFlush(g); chThdSleepMilliseconds(200); gdispGDrawCircle(g, 256, 300, 150, Yellow); gdispGFlush(g); gdispGDrawChar(g, 256, 300, "X", font, Blue); gdispGFlush(g); } } void startGFX(void) { chThdCreateStatic(waGUI, sizeof(waGUI), NORMALPRIO, GUIThread, NULL); }

Hello & Welcome to the µGFX community! Could you please tell us which version of the µGFX library you're using (eg. v2.9 release or the git master branch, ...) and whether you're using a development kit (such as STM32 discovery or similar) or whether you're using custom hardware?

Hello, I'm currently implementing uGFX on a STM32H743iit6 with an 1024x600 screen via LTDC (rgb565). I'm running in some problems where the code from below doesn't render properly. What could be the cause? #include "ch.h" #include "hal.h" #include "gfx.h" #include "gfx_thread.h" GListener glistener; static THD_WORKING_AREA(waGUI, 512); static THD_FUNCTION(GUIThread, arg) { (void)arg; gfxInit(); geventListenerInit(&glistener); gwinAttachListener(&glistener); const font_t font = gdispOpenFont("DEJAVUSANS10"); GDisplay * g = gdispGetDisplay(0); gCoord width, height; width = 512; height = 300; while (true) { chThdSleepMilliseconds(1500); gdispClear(Black); gdispDrawString(10, 10, "Hello, uGFX with ChibiOS!", font, White); chThdSleepMilliseconds(1500); gdispDrawCircle(g, (width, height), 150, Yellow); } } void startGFX(void) { chThdCreateStatic(waGUI, sizeof(waGUI), NORMALPRIO, GUIThread, NULL); } Like seen in the picture the font is disorted and the circle isn't drawn in the center of the screen, however the Y axis seems to be ok?

@Sergey Kushnir I've applied your patch to the feature/gwin_redraw_fix branch (https://git.ugfx.io/uGFX/ugfx/src/branch/feature/gwin_redraw_fix) Would you be able to verify that everything is working as expected before we merge it into the master branch and make a v2.10 release?

Great, Joel! I already had the experience of repairing the operating system PicOS18, after which the forum about this OS just died. The problems disappeared and there was nothing to discuss.

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.

Hi, Joel! I can’t be friends with GIT. Maybe someone from your team will do this?

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

See topic The screen is redrawn more than once

As I noted earlier, The _gwinFlushRedraws function contains two branches: "Do loss of visibility first" and "Do the visible windows next". The first branch is for hiding the window. The second branch is for drawing windows with visibility flags set. When a window needs to be hidden, the GWIN_FLG_BGREDRAW flag is set, which is processed in the corresponding branch of the WM_Redraw function. A check is performed, does the window have a parent? If there is a parent, then this parent needs to be redrawed. If there is no parent, then there is nothing to redraw. In my opinion, the logic is as follows. The windows that need to be shown are processed in the second branch of the _gwinFlushRedraws function. Based on this reasoning, I modified the code as follows and marked this places with the label ">>": static void WM_Redraw(GHandle gh) { gU32 flags; >> gU32 parents = 0; flags = gh->flags; gh->flags &= ~(GWIN_FLG_NEEDREDRAW|GWIN_FLG_BGREDRAW|GWIN_FLG_PARENTREVEAL); #if GWIN_NEED_CONTAINERS redo_redraw: #endif if ((flags & GWIN_FLG_SYSVISIBLE)) { if (gh->vmt->Redraw) gh->vmt->Redraw(gh); else if ((flags & GWIN_FLG_BGREDRAW)) { // We can't redraw but we want full coverage so just clear the area gdispGFillArea(gh->display, gh->x, gh->y, gh->width, gh->height, gh->bgcolor); // Only do an after clear if this is not a parent reveal if (!(flags & GWIN_FLG_PARENTREVEAL) && gh->vmt->AfterClear) gh->vmt->AfterClear(gh); } #if GWIN_NEED_CONTAINERS // If this is container but not a parent reveal, mark any visible children for redraw // We redraw our children here as we have overwritten them in redrawing the parent // as GDISP/GWIN doesn't support complex clipping regions. if ((flags & (GWIN_FLG_CONTAINER|GWIN_FLG_PARENTREVEAL)) == GWIN_FLG_CONTAINER) { // Container redraw is done for(gh = gwinGetFirstChild(gh); gh; gh = gwinGetSibling(gh)) _gwinUpdate(gh); return; } #endif } else { if ((flags & GWIN_FLG_BGREDRAW)) { GHandle gx; #if GWIN_NEED_CONTAINERS if (gh->parent) { // Child redraw is done >> parents++; // Get the parent to redraw the area gh = gh->parent; // The parent is already marked for redraw - don't do it now. if ((gh->flags & GWIN_FLG_NEEDREDRAW)) return; // Use the existing clipping region and redraw now gh->flags |= (GWIN_FLG_BGREDRAW|GWIN_FLG_PARENTREVEAL); goto redo_redraw; } #endif // Clear the area to the background color gdispGFillArea(gh->display, gh->x, gh->y, gh->width, gh->height, gwinGetDefaultBgColor()); >> #if GWIN_NEED_CONTAINERS >> if (!parents) return; >> #endif // Now loop over all windows looking for overlaps. Redraw them if they overlap the newly exposed area. for(gx = gwinGetNextWindow(0); gx; gx = gwinGetNextWindow(gx)) { if ((gx->flags & GWIN_FLG_SYSVISIBLE) && gx->display == gh->display && gx->x < gh->x+gh->width && gx->y < gh->y+gh->height && gx->x+gx->width >= gh->x && gx->y+gx->height >= gh->y) { if (gx->vmt->Redraw) gx->vmt->Redraw(gx); else // We can't redraw this window but we want full coverage so just clear the area gdispGFillArea(gx->display, gx->x, gx->y, gx->width, gx->height, gx->bgcolor); } } } } } I introduced an additional variable that indicates whether the window has a parent. If there is no parent, then no redrawing occurs. If there is a parent, then it will be redrawed either in this function or later. The gx variable is an auxiliary variable-pointer to an object in the list. Therefore, any setting of flags in this variable is meaningless. I think this code meets your expectations. With this code, redrawing occurs only once.

No, two times.

Hmm. I don't think that is right, and even if it is works it will make the redraw require 2 redraw cycles to work. I think the problem is the bottom gdispGFillArea that is using gx. Whilst WM_Redraw clears any pending drawing operations, the gdispGFillArea doesn't and it should in this case. Try putting back the original code and then changing that bottom gdispGFillArea to... <code> else { gdispGFillArea(gx.... gx->flags &= ~(GWIN_FLG_NEEDREDRAW|GWIN_FLG_BGREDRAW|GWIN_FLG_PARENTREVEAL); } </code> The other area I pointed out is also probably still a bug but that one needs more testing.