Joel Bodenmann

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.

Hello @JohnLKW and welcome to the µGFX community! GDISP_SCREEN_WIDTH and GDISP_SCREEN_HEIGHT are macros (C-defines). They get replaced by the pre-processor prior to compilation. Therefore, you can't change their values during runtime. Have a look at the pixmap driver. The pixmap driver allows setting a resolution during runtime as well (upon calling gdispPixmapCreate()). I guess that should help you. Don't hesitate to ask if you have any further questions. We're happy to help wherever we can.

It's far from complete. Don't touch it. As far as I know @inmarket managed to get it compiling a couple of days ago but nothing is working yet. Yes, contributions are always possible and always appreciated from our side. As mentioned v3 is far from usable and even further from ready. There's no point in contributing anything to v3 yet unless you want to start actively developing for v3. Furthermore, as mentioned, v3 is backwards compatible to v2 except for the drivers interface. So any high-level stuff like an advanced graph widget will be fully portable to v3. Same as above except for the fact that v2 drivers won't be compatible with v3. However, as mentioned in another forum post somewhere we still accept (and appreciate) any new driver contributions for v2. Prior to releasing v3 we'll port all v2 drivers that have been included to the v2 repository to v3. Therefore, everything you contribute now will be ported & maintained by us. Yes, we are highly interested in that. We simply lack the manpower at the moment. As explained above contributing to v2 is absolutely no problem and actually the "recommended" way. We're happy for any kind of contributions, really There are not many contributions to the core itself because contributing to the core requires a bit more knowledge than lets say a new widget or a new driver where those interfaces are clearly documented and isolated. We do get contributions to the core itself regularly (and even bug fixes) but those usually come from engineers that work with µGFX in a commercial project. They usually have a support contract and don't show up on the forum here. I'd say about 75% of the people on this forum are hobbyists and makers that use µGFX "as is" from the point of view of the core and "simply" add new drivers and widgets. I hope that helps. @inmarket might correct me if my v2/v3 information above is inaccurate. He's currently focusing on v3 development while I'm busy with getting the new µGFX-Studio ready.

Hello @nhandt3 and welcome to the µGFX community! Unfortunately, the current version of the µGFX library doesn't offer any high-level API for that.

This is a common problem. Personally, I just never put the value into the comment but instead just write something like "configure clock rate". It happens just too easily (and therefore too often) that one changes the actual value but not the comment. Often just "for testing" and then it stays like that for a day, then it gets forgotten about, then it gets released as reference code by a huge company such as ST...

Sorry to hear about that... luckily it's just hardware that can be replaced - still a bummer though Definitely waiting for your feedback / response then once you get your hardware. Feel free to create a new forum topic for your question(s) at any point. We're happy to answer any questions we can.

This is great, thank you very much for sharing! Unfortunately I don't have any time the next couple of days/weeks to give this an in-depth look. Do you feel like it's ready enough so we can just put it straight into the downloads section?

@Paul C: Glad to hear that you are making progress. Don't hesitate to ask if you have any questions. We're happy to help wherever we can! Great, thanks for the info @Steve!

Not all of them. Many GCC versions 4.9 don't come with Cortex-M7 support yet. But now that you mention it I think you're right. I used GCC 4.9 with Cortex-M7 too. Probably something late like 4.9.7 but I'm really unsure. Either use GCC 5 to be sure or look it up.

Hello @Paul C and welcome to the µGFX community! That indicates that you're using a GCC version which doesn't include support for the ARM Cortex-M7 architecture (a too old version of GCC). You need at least GCC version 5.3.1 when I remember correctly.

No need to load images into RAM at any time. The image simply needs to be in a (fully) addressable memory. If that is the case, µGFX can handle the rest via GFILE. So using ROMFS to store your images in the microcontrollers FLASH means that you can simply render directly out of that.

Thank you for your feedback on this. We're going to look into adding more example projects for a wider variety of different IDEs and hardware platforms. I sent you the Elixpad binary with some explanatory text and a screenshot via private message. Looking forward for your feedback.