Joel Bodenmann

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.

@inmarket already talked about the benefits. I'd to ask why you think that it makes it less eclipse-friendly (or less-friendly in general)? You don't have to use the makefiles. You can integrated the µGFX library into any project and with any IDE without using the makefiles at all. We even provide a very convenient way that we call the "Single File Inclusion Mechanism" which allows you to add just one file to include the entire µGFX library into a non-makefile based project. That's explained here and here's a practical usage example for Keil µVision that doesn't support makefiles at all. And when it comes down to it you can always add every single file manually as you would just with any other library. The fact that we have makefiles available internally doesn't interfere with that at all, so I'd be really curious to know why you think that it has a negative influence? Elixpad currently doesn't support code completion and the like. However, everything is plugin based so adding so adding things like that is certainly possible. It started off as a pure hobby project (which it somehow still is) and until now I wrote everything on my own - there are no other 3rd party plugins or libraries (except for the Qt library which I'm using). Something like code completion and code analysis is rather complex and I think I have to resort to existing frameworks for that. It's something that will definitely follow in the next couple of months. As mentioned Elixpad is currently not public. That's not by choice but rather because I never bothered. It's a tool that I wrote for myself which @inmarket now uses as well. If it turns out to be useful for other people as well that's a big plus for me. Although the tool runs on Windows, OS X / MacOS, Linux and BSD (all tested) I currently only have Windows binaries at my hand. I am happy to share them with you though. Feedback is always welcomed. If you want I can PM the binary to you.

Great! Thanks for your help on this.

What keeps you from simply using ROMFS to load the images from your microcontroller's flash?

Personally I do most of my developments on Windows these days (for various reasons but mainly because that's what customers use and because Windows has greatly improved over the past few years (my personal opinion!) and because Windows has a few features that I am missing on other operating systems). For customers projects I find myself just using whatever IDE the customer uses. These days that's mostly Keil µVision or some Eclipse based manufacturer specific IDE. I myself am not a fan of Eclipse so I try to avoid it wherever possible and I don't use it myself at all. All in all I tried several (like dozens) of different IDEs (both free and proprietary/paid ones) and different editors over the past . I never found something that satisfies my needs. This resulted in me starting to write my own IDE / Development-Framework about a year ago which I find myself using every day as my main tool ever since. As inmarket mentioned he's using it for µGFX development as well. That IDE (called Elixpad) is able to invoke existing Makefiles so my (and our) projects are usually fully make based wherever possible. When working on Linux I started off with just good old plain vim + make and now moved on to using Elixpad on there as well. The same applies to FreeBSD (which is my main Unix OS) and Mac OS / OS X. As for hardware I use whatever needs to be used. Again, this is mainly dominated by customer needs. For µGFX internal development we usually develop everything on Windows / Linux and then use the different STM32 discovery and evaluation boards. I could go on and on and be more elaborating but I guess that should cover most things. I hope that helps.

Thank you very much for your feedback, we appreciate it a lot! Do you have any idea how we can improve the "IDE friendlyness" other than writing guides for more IDEs and having more ready-to-run examples for different IDEs? Your help is of course greatly appreciated as well

Hello @oyoungjin and welcome to the µGFX community! fgets() is a function of the clib (of stdio). It has nothing to do with µGFX. Your question does not seem to be related to µGFX at all or am I misunderstanding? That's currently not possible through the existing high-level API of the list widget. You'll have to add that yourself and we'll consider adding it in the future.

Looks good to me - Would appreciate it if @kengineer would give it a look anyway as well: https://git.ugfx.io/uGFX/uGFX/commit/23ceb054fcf9a6d7e29359b197e268ba03f1ce3c

Note that what I'm showing in the screenshot is hardware SPI. Just the CS line is being controlled manually. I'll try to do that screenshot with hardware controlled CS, but that might take a couple of days - very stressful around here currently.

No, it will not. The problem you're having is that you spend ages in writing something to the RA8875. It's a hardware problem. You need to wire the display up to the correct pins - there's no other choice. You could hack your own HAL function to write all the data pins at once if they are on the same port. I do have a system with an STM32F103 and an SSD1289 connected via 8-bit parallel bus and I don't use the FSMC and the performance is still great (probably 10 times faster than SPI). But that requires that you wired all your data pins to the same port and in the correct order (to not have to spend further time shifting the bits around): static GFXINLINE void write_index(GDisplay *g, uint16_t index) { (void) g; writePort(GPIOE, index); CLR_RS; CLR_WR; SET_WR; SET_RS; } static GFXINLINE void write_data(GDisplay *g, uint16_t data) { (void) g; writePort(GPIOE, data); CLR_WR; SET_WR; }

That is LTDC, that has nothing to do with this. It's basically an internal display controller that allows connecting a bare display panel directly to the microcontroller without an additional dedicated display controller chip. That's not related to the parallel interface or the thing I mentioned above. And if your data bits are not properly connected to the same port you won't have any chance at all anyway. And even then you'd loose a lot of performance.

@Jim: Here's the screenshot: This is with manually controlling the CS line because the used SPI module didn't provide the necessary functionalities to satisfy the needs (or rather requirements) of the display controller. It would be better if the SPI peripheral would handle the CS but you'd still loose a significant amount of time which you didn't take into account in your calculations.

Some hardware abstraction layers allow setting an entire port at once which would already speed this up a bit (roughly about 5 times). However, that would require that all data bits are connected to the same port (and in correct order). But as far as I know that isn't supported by CubeHAL anyway. But even if you would still loose tons of performance. There's really no way around this. The FSMC interface has been designed exactly for this. For the future: Feel free to either ask here on the forum or contact us directly as part of our paid support service if you'd like us to look over your hardware design prior to committing to it. We're happy to help wherever we can.

That is horrible. That is horrible and most likely a lot worse than SPI. The idea of a parallel interface is that you don't have to set every pin separately. Each call to HAL_GPIO_WritePin() results in multiple function calls which all take time (and memory). Connect your display to the FSMC interface of your STM32 microcontroller - it has been built for applications like this and you'll have an amazing boost in performance and tons of more free CPU resources. Using the FSMC interface allow writing to the display using just one write instruction of the processor. That's blazingly fast. Furthermore, it takes care of handling the WR, CS and RS pins correctly as well. What you're doing right now is having 15 functions calls to HAL_GPIO_WritePin() which results to other nested function calls. A function call is a very expensive operation and takes up a lot of time. You should easily get 20 to 30 frames per seconds using the FSMC interface while also freeing a lot of CPU and memory resources at the same time.

Can you give more information about this? What kind of hardware are you using? What type of bus? what speeds? Even if you're just using an 8-Bit parallel bus connected to the FSMC interface of an STM32F103 you should easily get a speed improvement of factor 10 to 20. If you still have visible screen updates you're doing something very wrong. Any additional information would help and, if possible, a video showing a screen update.