Jump to content

Joel Bodenmann

Administrators
  • Content count

    2,135
  • Joined

  • Last visited

  • Days Won

    2

About Joel Bodenmann

  • Rank
    µGFX Developer

Recent Profile Visitors

5,659 profile views
  1. SSD1963- Wrong Colors

    The connection of the physical signals definitely needs to map 1:1 as that wouldn't only have an impact on the color values but also on any other values you write such as initialization values and other commands. I don't have another explanation for this at the moment. What you experienced happens often and so far it was always related to a mismatching config between the display controller and the µGFX configuration. But I guess the most important thing is that you have it working - that makes investigating a lot less frustrating
  2. SSD1963- Wrong Colors

    Well, glad to hear that you got it working! RGB vs BRG is really just a different order of the bytes representing the color value. It's up to the display controller to decide which of the two will be used and µGFX simply adapts to that. With display controllers like the one you're using it's usually possible to configure that during initialization. You might want to have a look at that. The 24 bit thing is most likely a packed vs. non-packed issue. But it's hard to say without knowing the exact details. This again is something that can often be configured on more advanced display controllers.
  3. Transplantation of ugfx

    There are three ways to run µGFX on Linux: Directly on the framebuffer On top of the X window manager As an SDL2 application Which one you choose depends on your needs. If you want to run µGFX directly on the framebuffer then you certainly need a Linux kernel with framebuffer support. The µGFX GDISP driver will simply render into the framebuffer device provided by Linux.
  4. Top layer windows (widget overlapping)

    Hello Steffen, As you mentioned yourself the default window manager doesn't handle overlapping windows at all. However, it's possible to write your own window manager. Our community member @Steffan made a demo once:
  5. uGFX support for USB mouse with BeagleBone Black

    Don't hesitate to ask if you have any further questions - we're happy to help
  6. License and pricing

    Hello @jano, The pricing on shown on the current version of the website is correct. The $5/device option has been removed.
  7. Transplantation of ugfx

    Hi, The workflow usually looks like this: Create a bare hello-world project on your target that runs without any µGFX stuff at all Integrate µGFX into the build system. Therefore, creating a bare hello-world project for your target that runs with µGFX. It's important to disable all the modules (no GDISP, no GINPUT, ...) Enable the GDISP module. Use the TestStub driver to test the compilation process. Then determine whether you have to write your own display driver or whether you can use an existing one and just modify the board files. Enable the GINPUT module (if required). Determine whether you have to write your own mouse/touch driver or whether you can use an existing one and just modify the board files. Enable GWIN, enjoy. Most of the stuff that happens is outside of µGFX (eg writing the board files, setting up peripherals and so on). The goal is to create an environment that already does everything (correct peripherals initialization and so on) and then just put µGFX on top of that.
  8. Hello @jano and welcome to the µGFX community! Thank you very much for sharing your experience with us - we appreciate it greatly and I'm sure other uses will do too in the future
  9. SSD1963 8Bit FMC STM32F7 CubeMX

    Hello & welcome to the µGFX community! There are currently no official examples for that. However, it should be very straight forward to get that working. The FSMC vs. FMC stuff does not concern µGFX at all - that only affects the changes in the board file which are always hardware/platform/target specific. FMC doesn't work that different from FSMC. It's basically just more features. You should be able to take one of the existing FSMC examples and adapt it to your FMC needs. It's always good practice to make sure that your peripherals are working outside of µGFX prior to writing the board files for µGFX.
  10. uGFX support for USB mouse with BeagleBone Black

    Glad to hear that you managed to get it working! The best solution is to pre-render everything into an off-screen area called a pixmap. Once everything has been rendered you can simply copy the pixmap contents to the real display. Therefore, there won't be any flickering at all. You can find the documentation about pixmaps here. I'd also recommend you to think about writing a custom widget. That would allow you to better control the way the widget is being rendered and you could manually cache the parts of the images that are going to be overwritten by the texts on top of it. You can find an entire guide on how to create a custom widget here. I hope that helps!
  11. uGFX + FreeRTOS (on STM32F746-Disco)

    Hello @Simon, Did you make sure that you use the latest version of the µGFX library? There have been a few changes/improvements in the last release. gfxInit() not returning indicates that some part of the initialization failed. The easiest way to track it down is by stepping through the code. One other think you can try is forcing the usage of the built-in memory manager that comes with µGFX. You can do that by setting GFX_OS_HEAP_SIZE to a non-zero value. All µGFX heap allocation calls are then managed by µGFX internally. If it's set to 0, the memory manager of the underlying system will be used (in this case FreeRTOS). There are different heap managers that you can use with FreeRTOS and this test would certainly help to find out whether there might be a problem with that. But I'd recommend you to get started by stepping through the gfxInit() code to find the source of the problem. Your code looks good in general - nothing rings the alarm bells right now. EDIT: One thing that just came to my mind: Are you sure that you want to call the GUIThread from the uGFXInit() thread? It has been quite a while since I worked with FreeRTOS the last time but I could imagine that that is a problem due to nested stack spaces (eg. uGFXInit would need all its stack + the stack of the new thread) and probably also scopes. Did you try following the example given in the wiki?
  12. Attaching a specific button/widget to a listener

    Glad to hear that you managed to get it working! Thank you for your suggestion. This surely sounds interesting. I added as task to our ToDo list - we'll look into it.
  13. Attaching a specific button/widget to a listener

    One thing that helps is using the widget tags. This way you can simply switch-case every widget based on an uint16_t that gets added to each widget. More information: https://wiki.ugfx.io/index.php/Widgets#Tag
  14. Gwin label

    Like any other module, sub-system and feature you can enable the GWIN module in the configuration file by setting GFX_USE_GWIN to TRUE. Just make sure that you use the gfxconf.h file that is part of the demo and everything will be fine. Those demos are supposed to run out-of-the-box.
  15. uGFX-Studio v0.20 - Beta

    µGFX-Studio v0.20.11 is now available for download. This release includes the fix for the missing Custom Parameter field in the widget editor and some internal improvements.
×