Joel Bodenmann

Yep, that's also how it's done for the DMA2D stuff. That's definitely the better way of doing it.

Hello @Joe Stepien and welcome to the µGFX community! We haven't found a previous post from you in our logs. There's also nothing to review. Not sure what happened there. We haven't heard of any other issue like that before. Let's assume that it was just a glitch or miss-click at some point. Please don't hesitate to let us know if you keep experiencing issues with this forum. The simplest way to add µGFX to an existing project is by using the single file inclusion mechanism. That allows you to add just one single file to your project instead of the entire directory which can become difficult and cumbersome to manage. This is documented here: https://wiki.ugfx.io/index.php/Getting_Started#Single_File_Inclusion We don't have a step-by-step guide for IAR but we have one for Keil µVision which uses the same technique. You can find it here: https://wiki.ugfx.io/index.php/Using_Keil_µVision_5_MDK-ARM That should definitely help you to get started. Yes, it is --> https://wiki.ugfx.io/index.php/Images#Examples Follow the guide above to add the µGFX library to your existing project and you should be ready to go. Of course you have to read a bit of documentation. The µGFX library is very easy to use but very complex inside to achieve that (and other features such as complete portability). Unless you can use one of our ready-to-run projects you'll have to spend a couple of minutes to read through the various articles & guides that you can find in the wiki, some of which are linked above.

Unfortunately it is a lot more complex than that. In order to be useful, the gdispDrawString() (and similar) calls still need to have their effect as the higher-level items such as the widgets and user applications depend on them. This means that the font rendering stuff needs to be intercepted below that level. Basically you'd have intercept between the GDISP layer itself and the font rendering engine. However, this gets complex because you have no longer control over the fonts, unless you can load them dynamically to the font engine chip through the gdispOpenFont() function and the main problem is that you have to reproduce the exact behavior in terms of color filling, justification and so on.

That driver actually shouldn't be part of the library anymore, we wanted to throw it out a couple of months ago but seems that we never actually did it. The reason for that is because it appears that the author of the driver (a member of the community) just simply copy-pasted the Adafruit driver and when I remember correctly the Adafruit license doesn't allow for that. We'd appreciate it if you guys could develop a proper µGFX driver from ground up.

Hi, I took your forum post (above) out of the topic you posted it in and created a new one as it was getting heavily off-topic. To your question: There's no high-level API to check whether a flush completed. This is something you'd usually take care of in your low-level driver as you mentioned. If the information is needed in other parts of the application through a high-level interface then using the GDISP Query capabilities is the right way to go (gdispQuery()).

Hello @lerix and welcome to the µGFX community! The µGFX library has been designed to run on any system and on any OS. Therefore, you should definitely be able to run µGFX on your OS. What you have to do is creating a port for the GOS module. The GOS module provides a generic high-level abstract layer towards the underlying operating system that all other components of the µGFX library area using. Read up the various documentation regarding the GOS module to learn how to write a port, it's really straight forward. You can also find plenty of examples in form of existing ports in the /src/gos/ directory of the µGFX library.

Yes, that for sure. This would completely bypass any font engine provided by µGFX itself.

Also, welcome to the µGFX community!

I think that the deal here would be to use the hardware font rendering offered by the RA887x chip. You can give it some font files which it stores in its own flash and then you simply tell it where to render what font with what color. So it's the same deal as with the other hardware accelerations for the shapes: It's a matter of bypassing the µGFX font rendering and sending the proper commands to the RA887x chip to let it do the job. However, this one might be a bit more complex as you have to load the font at some point into the font memory of the chip. Using the GDISP control interface might make sense here.

As @inmarket mentioned the files from the forum post linked above are definitely working. It's just that it's using the video mode instead of the adaptive command mode. That is not even hacky - it's just a different mode. µGFX would benefit from using the adaptive command mode, that would increase the performance and free system resources compared to the video mode. In this case it's really just about the GDISP driver, not the rest of µGFX. Therefore, that might be a really good way to start the dive into µGFX as the driver is somewhat "isolated" and the interface is well documented. However, you'll still learn a lot about how the GDISP module works and from there the journey can continue As always: Any help is highly welcomed.

We're happy to provide you with one - we really appreciate the time you put into this ChibiOS issue. Please don't hesitate to PM me in case of you're interested. As far as I'm informed the latest state are these files in this forum post:

Thank you a lot, really! We appreciate your work. I'm also very thankful that you deleted the repository as these kind of "manual forks" pose a problem for us. If you like working on things like that... There's still the driver for the STM32F469i Discovery board that you can find here on the forum that is not part of the official repository yet. The reason for that is that the driver that two or three people of this community created only works in video mode, not in the adaptive command mode which would be "better".

Thank you for your contribution, we appreciate it a lot! And of course: Welcome to the µGFX community!

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.

Great work, well done! Let's see where this goes

Definitely via their forum.

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?

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.

I put this on our ToDo list. I agree that this is something that should be taken care of.

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:

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.

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.

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

To clarify: This is fairly easy as it's just two high-level API calls: gdispPixmapCreate() to create a valid GDisplay object and then pass that GDisplay* pointer as the first argument to your gdispGImageDraw() function. That's how you draw the image into the pixmap.

@JohnLKW: "Run Time" refers here to the run time of the program. Basically the time during which the code is being executed. There's compile-time and run-time. Although the gdisp_lld_init() doesn't get called directly during the execution of your own program it's still something that happens during the run-time (execution-time) of the program. @steved: While that would/might work as those are only used by drivers internally it would still be hacky/ugly. Those two macros are part of the public interface which allow the user to set the resolution of drivers which already support that (eg. the Win32, X and SDL drivers). The driver can simply ignore them but the user must be able to #define them as integer values prior to compilation. Otherwise some code will not build properly. Again: It would work, but then it won't work in some cases. They were not meant to be used like that so the proper way is not using them like that All other parts of the µGFX code rely on gdispGetWidth() and gdispGetHeight() which will simply access the Width and Height struct fields in the GDisplay struct. That's all that gdispCreatePixmap() is doing in order to support setting a resolution during run-time. No other magic involved.