Joel Bodenmann

  • Content count

  • Joined

  • Last visited

  • Days Won



About Joel Bodenmann

  • Rank
    µGFX Developer
  • Birthday

Recent Profile Visitors

2,667 profile views
  1. This is not at all related to your initial problem / the topic of this forum thread. We're happy to help wherever we can but please at least try to figure out what the problem is. Googling the error(s) you're getting would instantly give you results. Furthermore, the demo you're trying to compile even comes with a readme file that explains what to do: In order to run this demo you will have to link against the math libs. You can do this by adding -lm to the LIBS variable in your Makefile: LIBS = -lm
  2. Here: You can add your own color format if you need something specialized. Eg. some people on this forum added color formats with an alpha channel.
  3. It's part of the board file of the framebuffer. Have a look at the board file template that you can find in the driver directory (/drivers/gdisp/framebuffer/board_framebuffer_template.h). You might want to get the latest master branch of the µGFX repository to get all the latest framebuffer driver goodness:
  4. Note that this is not about #defines. This is about function definitions (the C functions). There must only ever be one function named main in the entire program/application. The project you're having has two: One in main.c and one in gui.c. Simply remove the one in main.c (because the one in gui.c is the one from the demo that does everything you want) and you can continue to compile. Then you'll hit the next problem as described above.
  5. This is the error when just building the project you attached without any modifications: compiler_output.txt These are the two only errors: .\Objects\Widge_Create_Ugfx.axf: Error: L6200E: Symbol __ARM_use_no_argv multiply defined (by gui.o and main.o). .\Objects\Widge_Create_Ugfx.axf: Error: L6200E: Symbol main multiply defined (by gui.o and main.o). It tells you exactly what your problem is: You have multiple definitions of the main() function. It even tells you where they are. So currently your problem is that you have your own main.c() and the one that comes as part of the demo. Simply commenting out your own main() function allows you to get rid of that problem. Then, you'll hit the next problem: .\Objects\Widge_Create_Ugfx.axf: Error: L6218E: Undefined symbol dialGCreate (referred from gui.o). .\Objects\Widge_Create_Ugfx.axf: Error: L6218E: Undefined symbol dialGetAngle (referred from gui.o). .\Objects\Widge_Create_Ugfx.axf: Error: L6218E: Undefined symbol dialSetAngle (referred from gui.o). .\Objects\Widge_Create_Ugfx.axf: Error: L6218E: Undefined symbol assert (referred from gfx_mk.o). You haven't added the other source files that came as part of the demo/widget to the project (you're missing dial.c and probably dial.h is not in the include path, but I haven't checked that).
  6. This appears to be related to a miss match of the floating point flags.
  7. I just had the time to download and try building the project. Did you even read the error message that you're getting? It tells you exactly what the issue is.
  8. The µGFX library currently doesn't come with a built-in driver for the ILI9327 so you'd have to write your own GDISP driver. This should be very straight forward as everything is well documented and as there are literally dozens of examples (existing drivers). I assume that you can just copy the existing ILI9325 or ILI9320 driver and modify it to work for the ILI9327 display controller.
  9. Have a look at the GDISP driver / GDisplay documentation. It tells you the function signature (the function name is gdisp_lld_fill() or something like that, that the linker will try to link against). If you implemented the hardware filling functionality into your driver correctly then it should just work. Maybe you forgot to set the corresponding define in the driver configuration file. You might want to have a look at some of the other drivers that implement hardware acceleration.
  10. Usually you'd want your event loop to run in its own thread so you'd use TIME_INFINITE as the timeout parameter of geventEventWait(). This solves all your problems. Keep in mind that you have to use gfxSleepMilliseconds() instead of HAL_Delay() in any case as pointed out by @inmarket.
  11. No, we definitely don't suggest to change your hardware. Your hardware is fine. The µGFX code is optimized to always use the best possible method to achieve something. In case of clearing the screen it would use the hardware clearing if you implemented that. If you haven't it will use gdispGFillArea(0, 0, gdispGetWidth(), gdispGetHeight()). That function would then use the area filling hardware acceleration (if you implemented that) or fall back to manually clearing the screen by basically doing setPixel() - which is what you're experiencing currently. Hence we suggest you to simply implement the hardware area filling (rectangle drawing) support into your RA8875 and your problem will be gone. The performance of your entire GUI will increase immensely.
  12. Hello @cotsos and welcome to the µGFX community! That is expected behavior. For various reasons (which all boil down to saving resources), GEVENT doesn't internally buffer or queue up events. Each listener provides its own buffer with the size of one event. Therefore, if you're not listening you'll miss it. This is a design choice that was made to vastly simplify code complexity and decrease resource usage because the event system is only used for GUI interactions with a user which are always very slow. You get the press but not the release because the press event fits into the one-event sized buffer. Then the release event happens but it can't be stored anyway. The proper way of doing this is using the second parameter of the geventEventWait() function which is the timeout parameter. In a usual application where the event loop runs in its own thread you'd leave this to TIME_INFINITE. Using a timeout of 0 is definitely a bad approach because you're almost guaranteed to miss the event(s). I hope that helps. By the way: Can you share with us what kind of performance you get out of that STM32F469i-Discovery driver from the other thread? Just the overall user experience, not actual measurements. Is it so slow that you see the image being rendered or is everything blazingly fast?
  13. Do not attempt to change anything internal like that. Those things are not like that just because for no reasons. The mechanisms used by the GWIN module (and anything else in the µGFX library) are a result of years of experience and many complex pieces that fit together nicely. When not having the big picture you don't see all the things that go on in the background, what simplifications have been assumed to save memory and so on. Changing something like this is the wrong approach for fixing symptoms rather than problems and you will end up with many other problems instead. Implement the area filling in your RA8875 driver and you'll get a huge performance boost already. After that, apply other mechanisms that have been discussed in this forum many times. Any changes inside of the core code, even if it's just so little of a change, will have many side effects and will imply many more problems.
  15. Are you absolutely sure that you set the range of the font converter correctly to include those umlauts? Did you ensure that you have your file encoded as UTF8 and that that UTF8 support has been enabled in your config file? If you keep having problems after checking those things above, please attach your converted font file as well as your source font file to your next forum post.