Joel Bodenmann

Please stop spamming an unrelated forum topic.

Hi, Making ready-to-run projects is very difficult as it depends completely on the underlying hardware. If you're using some sort of development board/kit you should get a project for that and then just add µGFX as described in the detailed step-by-step guide for Keil in the documentation. µGFX is completely platform/hardware agnostic which means that it will run on almost anything. The normal workflow is that you get your stuff running without µGFX (eg. taking a sample project that comes with the development board/kit that you use) and then you'll add µGFX to it.

Have a look at GDISP_NEED_STARTUP_LOGO in the configuration file. By the way: It seems that your display (pages) are swapped. Left and right are swapped.

The display controller is physically connected to your microcontroller/system via some kind of bus. For example parallel or SPI. The acquire_bus() and release_bus() functions are called by the driver itself (which is independent from what interface/bus is being used) before and after making a bus transaction. These functions allow you to acquire the bus before talking on it and releasing it once you're done. In case of a simple SPI interface this is where you want to set your CS pin level accordingly. More complex systems might need to call OS functions to acquire/request bus access and stuff like that. The GDisplay structure represents the actual display. You can have a look at the documentation to figure out what information is contained. Usually you're interested in this when dealing with multiple displays or requiring the private board file area.

Yep, that's correct: Pixmaps are meant to be used for this. Single-file inclusion is just a method designed to be as comfortable as possible. You can always include the µGFX library sources the classical way. It's just a bit more work. But now that you already know µGFX a bit it should be fairly simple

And a GINPUT toggle for the pushbutton to select stuff

Definitely!

Glad to hear that you got it working! I'm not sure about what v3 repo you're talking about tho. You should be using the master branch of the official uGFX git repository: https://git.ugfx.io/uGFX/uGFX That branch will become v2.9 which contains the new type systems and other things to prepare for the v3.0 major update.

In general you don't want to build µGFX as a static library because there is A LOT of pre-processor magic happening that optimizes tons of things during compile time. We've had many customer projects where they wanted to build µGFX as a static library. After some short argumentations they usually dropped that idea fast - except for one customer. And from there on it was a constant pain in the butt. A lot of time was lost due to different problems that only arose due to building µGFX as a static library. I'm currently on the road so I've limited comfort to write down detailed reasons. But in general: No you don't want to do that except some very specific special cases where you'd know that you want that and why. I hope that helps.

What you want is the Toggle driver of GINPUT. It allows to attach hardware buttons to µGFX applications. There's a working example for some Atmel SAM platform. You might want to use the forum search on "toggle" to find more information.

Hello & welcome to the µGFX community! You will certainly be able to run µGFX on that hardware with that SDK. There's not really much to it. As expected: Setup a working project and then add µGFX to it. As you've mentioned there are guides for that (you might want to have a look at the agnostic guide as well).

Cool! That would be appreciated

GDISP drivers have an interface for reading out the framebuffer. You can use that to get direct access to the pixel data. But keep in mind that uGFX itself doesn't need a framebuffer. So there are certain setups where this won't be possible because there's no framebuffer accessible. If this is a higher end application you might already be using Pixmaps which are essentially framebuffers. The Pixmaps have high-level API to return a gdispImage object of the framebuffer contents.

That's nice, thanks for sharing! Is this in a state where we could add it as an example to the downloads section?

Agreed - Over five years ago this wasn't supported/working. These days it works just fine

I have no idea what you expect to get from such a post. Please read the documentation and ask specific questions.

Hi, There's a step-by-step guide that shows you how to integrate the µGFX library into an existing Keil project: https://wiki.ugfx.io/index.php/Using_Keil_µVision_5_MDK-ARM Make sure that the integration works and that µGFX is actually running before you enable the GDISP module.

Hi, We don't currently have a PSoC 6 setup available. However, the basics are always the same. Before you have your SPI peripheral spitting out the expected/correct waveforms there's no much sense digging into µGFX itself. I'm sure you'll get plenty of good help from people that actually use this platform. All that SPI & timer stuff is generic and not relevant to µGFX itself.

Please excuse the late reply - I wanted to digg out some sources. We've plenty of people that use µGFX on nRF51 and nRF52 platforms. The nRF51 does have a systick. I've attached a GOS port and the corresponding systick handler implementation for an nRF51 port I made quite some time ago. In general: You might want to check whether the µGFX core runs before starting to use optional modules such as GDISP and GINPUT. You can have a look at the GOS demos - they allow you to check whether the µGFX core is working correctly without using the display code. ugfx_port.c gos_nrf5sdk11.c gos_nrf5sdk11.h

I don't currently have any setup available that least me easily test the Linux event driver. However, I used it myself in the past without any problems. I'd recommend you to setup a project that allows you compiling on a Linux machine with a desktop environment using the SDL2 port for easy debugging. Step through the code to figure out where it's going wrong.

Glad to hear that you managed to get it working!

well the most important thing is checking/changing the initialization sequence.

Hello & welcome to the µGFX community! I'm glad to hear that you managed to get everything working. We're always extremely interested in contributions like that!

Use the forum seach. You'll find that a lot of ILIxxcx users experience these kind problems. I've made a very verbose forum post about this just a few days ago. You'll find a lot of content about that.

Can you please attach a *.zip archive containing a minimum runnable test case that we can run?