Joel Bodenmann

  • Content count

  • Joined

  • Last visited

  • Days Won



About Joel Bodenmann

Recent Profile Visitors

3,188 profile views
  1. Thank you for your contribution, we appreciate it a lot! And of course: Welcome to the µGFX community!
  2. Hello @doc_rob and welcome to the µGFX community! There are plenty of example board files that you can find in the /boards directory of the µGFX library. However, it would be a lot more efficient if you could simply attach a plain text file of the compiler output (make sure that you make a clean build). This way we can see what's going on and help you resolving your problems.
  3. Very close to that. Far from perfect though, but we need to get user feedback soon anyway.
  4. Great work, well done! Let's see where this goes
  5. Definitely via their forum.
  6. Yep, looks like you're getting there... As @inmarket mentioned the current problem is that you're including the uGFXnet GDISP driver - which, I assume, you don't want to use. Make sure that you only include the driver(s) that you really want to use as shown in the Keil µVision guide linked above. All other drivers must be excluded from the build. Also, what is that DispDriver directory shown in your screenshot above? Did you copy the driver you want to use to your project directory? That would be wrong. Leave the µGFX library directory as it is, completely untouched. Only add the gfxconfig.h and the board_* file to your project as those are the only parts that are specific to your project. DO NOT copy other files from the µGFX library directory to your directory.
  7. This is awesome, great work! We appreciate this a lot. For completeness, could you add a link to your repository so we can find the changes? We'll definitely take a look at this and merge it ASAP. Changes required in the ChibiOS sources should definitely be reported back to the ChibiOS people. Would you take care of that or should we?
  8. 1) Please use code boxes if you want to inline code snippets or compiler output logs in your forum post or attach larger ones as plain text files to your forum post. 2) It is correct that the OS definitions are not part of the stuff generated by the µGFX-Studio. It's correct that you add that yourself. 3) Don't place the gfxconf.h file in the µGFX library directory. The µGFX library directory should stay untouched. The configuration file is part of your project. 4) You must exclude the font files (eg. /src/gdisp/fonts/DejaVu16.c) from the build process. Otherwise you get the issues you're currently experiencing. Simply exclude all font files from the build process by checking the "Exclude from build" checkbox in the file properties editor. 5) When using the baremetal part (RAW32) you have to define the gfxMillisecondsToTicks() and gfxSystemTicks() functions in your project. Please refer to the documentation for more information:
  9. Just make sure that you hook it up properly. Don't hesitate to ask if in doubt. All but the second display that you linked appear to only provide an RGB interface. That's not what you want unless you want to / can use the LTDC peripheral of the higher-end STM32 lines.
  10. I put this on our ToDo list. I agree that this is something that should be taken care of.
  11. That is of course correct. But whenever possible, go parallel. However, if done wrong this can actually be slower than SPI. Have a look at this goodie:
  12. Things will be ported over to v3. v3 is not just a rewrite from scratch where we will drop everything that we made so far and completely drop v2. The "only" real difference between v3 and v2 will be the underlying (GDISP). driver interface. All the high-level stuff will stay mostly unchanged except for some simple renaming of types and API functions to keep it clean, consistent and to get rid of some namespace collisions. However, there is the GFX_V2_COMPAT macro (which is turned on by default) that maps all these back to the "old" v2 calls in order to stay completely backwards compatible except for the drivers - which we will all port to v3 if they are part of the repository and provide a guide for everybody else to do it with their own ones. Long story short: Nothing you do now for v2 will be for nothing. If you're working on high-level stuff (everything above the drivers layer) you won't be affected at all and if you made changes to a driver or if you created a new driver you can either contribute it to the v2 repository and we'll port it for you or you can port it yourself to v3 once that stuff is ready.
  13. Actually this will most likely only be related to the wrong include paths as just mentioned by @inmarket. Adjusting those should fix that. A question though: Are you using the built-in makefiles or are you including the µGFX library via the single file inclusion mechanism (through gfx_mk.c)? If the latter, definitely make sure that you only include the top level directory path as mentioned by @inmarket and no other one (except for the directories of the drivers that you're using). Otherwise you'll end up exactly with this issue. This guide for Keil µVision might be helpful here as it clearly shows how to work with the single file inclusion mechanism:µVision_5_MDK-ARM I hope that helps. Please don't hesitate to ask if you have any further questions. We're happy to help wherever we can.
  14. I feel like we should add those interfaces ourselves anyway. They can easily be added, it's simple to maintain and using #ifdef macros means that it adds zero overhead to drivers that don't use it. I need hardware acceleration of primitives myself or another upcoming project anyway. However, everything that @inmarket mentioned still applies though. Note that this doesn't apply to owners of a commercial license.
  15. Hi, Yes, that is definitely possible and as you mentioned this is actually on our ToDo list. It's just a lack of man power (as with almost all µGFX things). Currently @inmarket is focusing on getting the new GDISP driver interface for v3 ready while I am fully focusing on getting the new µGFX-Studio ready for a beta release. We'll not pick up any other tasks until those two are completed. Therefore, the C++ wrapper is something that won't happen within the next couple of months from our side. However, as always, we'd appreciate any kind of contribution