Jump to content

Joel Bodenmann

  • Content count

  • Joined

  • Last visited

  • Days Won



About Joel Bodenmann

  • Rank
    µGFX Developer

Recent Profile Visitors

3,921 profile views
  1. Problem Stack Overflow

    Hello and welcome to the µGFX community! Before we start diving into debugging this - did you try running the unmodified /demos/modules/gwin/button demo? Does that work?
  2. Error: Undefined Reference to 'FsROMVMT'

    Regarding the build error: Did you perform a clean build? Regarding the linker options: The top-level makefile provided by µGFX that you're using comes with an entire API that is documented in /tools/gmake_scripts/readme.txt. Furthermore, the ChibiOS makefiles that are being included by the top-level one if OPT_OS = chibios feature some more chibios specific options which are also documented: # See readme.txt for the make API # Requirements: # # CHIBIOS The location of the ChibiOS code eg. CHIBIOS = ../chibios # CHIBIOS_PLATFORM The name of the ChibiOS platform eg. CHIBIOS_PLATFORM = AT91SAM7 # CHIBIOS_PORT The name of the ChibiOS port eg. CHIBIOS_PORT = GCC/ARM/AT91SAM7 # # Optional: # # CHIBIOS_LDSCRIPT The name of the loader script eg. CHIBIOS_LDSCRIPT = AT91SAM7X256.ld # CHIBIOS_BOARD The name of the ChibiOS board eg. CHIBIOS_BOARD = OLIMEX_SAM7_EX256 - if not specified you must include equivalent code yourself # CHIBIOS_VERSION Which version of ChibiOS is this (2 or 3) - default is 3 # CHIBIOS_STM32LIB Use the STM32 library source for drivers instead of native drivers (yes or no) - default no # CHIBIOS_PROCESS_STACKSIZE Size of the ChibiOS process stack. Only useful if the link script supports it - default is 0x400 # CHIBIOS_EXCEPTIONS_STACKSIZE Size of the ChibiOS exceptopms stack. Only useful if the link script supports it - default is 0x400 # As you can see, there are makefile variables for the stack sizes. You're adding "plain" variables via the LDFLAGS variable. Without remembering the details I'm pretty sure that they are just being appended which would explain the behavior that you're experiencing. Try using the proper variables documented above.
  3. change pages by one key

    Hello Alan, Unfortunately, I don't really understand your question. The code you're showing is correct. That is the proper way of doing it. You can't do anything other than that - it's the intended way of handling this.
  4. STM32F407 guiEventLoop issue

    Glad to hear that you managed to get everything running. Good work!
  5. Keyboard type question

    Yes, the existing layout(s) that you can find under /src/gwin/gwin_keyboard_layout.[ch]. And for styling: Custom rendering routines as always.
  6. Input text box

    Exactly. Of course you could start from scratch but that probably won't be as efficient as all the button placement code will be the same.
  7. Input text box

    As you mentioned yourself what you're after is a custom rendering routine. Every GWIN widget supports that: https://wiki.ugfx.io/index.php/Creating_a_custom_rendering_routine I'd recommend you to simply copy the existing one to your project and modify from there.
  8. Input text box

    Yes, you can completely customize the keyboard layout. Have a look at the existing layout that you can find under /src/gwin/gwin_keyboard_layout.c. It's really just a matter of filling in a struct. You can use gwinKeyboardSetLayout() to set your own layout.
  9. Intercepting Input Events

    It should be fairly easy as the GWIN module uses the GEVENT module for event handling: bool_t gwinAttachListener(GListener *pl) { return geventAttachSource(pl, GWIDGET_SOURCE, 0); } There is a matching geventDetachSource() function in the GEVENT module. I'm looking at this on my phone and I don't remember all the details but on first glance this really looks quite straightforward. @inmarket might have more details in his memory.
  10. Intercepting Input Events

    Without thinking too hard about this my first idea is to implement a gwinDetachMouse() which you use to detach the GListener that usually gets attached using gwinAttachMouse() (or gwinAttachListener() in the old days). This will prevent the widgets from receiving mouse/touch events. You can attach it to a dummy listener that will fire up the backlight and then detach itself and attach the old listener again. There might be another / better solution but this sounds quite proper to me.
  11. RGBA support?

    Another solution was presented by our community member @Steffan some time ago. He extended the implementation of the pixmap to support color keying by exploiting exactly what @inmarket mentioned. This way the blending happens inside the µGFX pixmap implementation and not the driver.
  12. We know of several people and companies that successfully run µGFX on a PIC32 platform. As @inmarket mentioned the library has been designed to work with any system and compiler. You shouldn't encounter any problems.
  13. Support for STM32F769I?

    Hello @Mavro and welcome to the µGFX community! Currently we don't have any ready-to-use board files for the STM32F769i-Eval board. This is due to the fact that we don't have such a board. If you want to contribute one, we wouldn't mind Anyway: Running µGFX on that board will be very easy. The STM32F7 microcontroller is well supported by µGFX already and the driver required to use the STM32 LTDC peripheral already exists and is known to work well too. You should get started by simply copying the /boards/base/STM32F746G-Discovery board directory and name it /boards/base/STM32F769i-Eval. From there, just modify the STM32LTCD board file that is located in that directory. It should be pretty straight forward as usually it's just a matter of changing the pin assignments although not even that might be necessary here. I hope that helps. Don't hesitate to ask if you have any further questions.
  14. geventAttachSource Gives Black Screen

    Hello Stephen, Please excuse the late reply... quite busy around here... I'm glad to hear that you got it working, good work! Regarding the debugger: This is not something µGFX related. I am talking about your regular program/software debugger which will most likely be GDB.
  15. F7 bare metal ADC+DMA won't work with ugfx

    Definitely unrelated to the GADC module as @inmarket already mentioned. It is likely due to a DMA stream collision (if your ADC peripheral has been set-up to use the DMA as well). It has been a long time, I really can't remember which DMA stream the STM32 LTDC driver uses (or even if at all) but you should be able to check the sources and then use a different DMA stream for your ADC. If you say that "it stops working", does that mean that just the DMA halts or do you experience a hard-fault or some other from of crash? As in: Does the CPU keep working and it's just the DMA that gets stuck?