Joel Bodenmann

@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.

Unfortunately it seems like FreeRTOS doesn't provide a way to query/retrieve the word size - but I might be wrong. Using sizeof(int) appears "wrong" to me because it's purely the choice of the compiler how wide an int is. Using the same processor/target with two different compilers might yield two different sizeof(int) values. I agree that most compilers probably show consistent behavior here but we currently have a list of 74 compilers that are supported by µGFX (and a subset which is actively tested). Therefore, having a solution that works with just most compilers seems inadequate to me. Unless of course FreeRTOS uses sizeof(int) itself internally to determine the word size. Does anybody know? Thank you for bringing this to our attention. Much appreciated!

I agree that we definitely need more demos and also pre-build ones. As mentioned, it solely fails on man power. I do have some more advanced demos ready for publishing as well such as a GUI for a coffee maker that we often use for demonstration purposes. I should clean it up and publish it. We'd appreciate any additional man-power on this.

You have not taken chip-select times into account. Many display controllers require you to pull high the CS line after a frame has been transmitted to reset their internal byte counter. This allows for a much simpler statemachine and therefore a smaller & cheaper chip. The parallel interfaces don't have these constrains which mean that you can usually keep the CS low for as long as you want given that there are no other bus members. Although this is just a matter of toggling a GPIO it's still going to take some time. You have to pull it low prior to start sending data and pull it back up to high once you finished. While the µGFX board files usually inline those functions there are still several nested function calls required to perform a GPIO toggle so the time you loose is definitely not negligible. I do have a logic analyzer screenshot at the office that I took a few days back, I'll post it here tomorrow. The delays you get from that are unfortunately large (like 25% to 50% of the actual frame transmission time). The reason I have that screenshot is because I ran exactly into that issue where the CS line was not being toggled between transmissions which lead to corrupt data. I have worked with many different setups in the past couple of years and I assure you that your 16-bit FSMC will be more like 30 times faster than you SPI. Also keep in mind that 16-bit FSMC is more than twice as fast as 8-bit FSMC as you don't have the additional setup & settling times between the two bytes. Additionally I'd like to point out that many (not sure about this one) display controllers allow for a faster bus speed when using the parallel instead of the serial interface.

Hello Sarma and welcome to the µGFX community! You don't have to create a port - there's already an existing bare-metal port that will work well on your hardware. Here's the documentation that explains how to use it: https://wiki.ugfx.io/index.php/BareMetal. In addition to that, you might want to set the GFX_CPU option in your configuration file to the one matching your target hardware as the baremetal port contains numerous processor dependent optimizations: https://wiki.ugfx.io/index.php/GOS#CPU. Additionally I'd like to give you the following recommendation which might save you a lot of pain: Use the latest master branch of the µGFX repository instead of the latest stable release. The latest master is stable too and contains many improvements for the baremetal port. When it comes to the display you'll have to write a new display driver. This is fairly straight forward. There's an entire article on the wiki that very extensively explains the different display driver models that µGFX supports. Furthermore, there are almost 40 existing drivers that you can take as a reference and if you have questions please don't hesitate to ask - we're happy to help wherever we can. Please attach a text file with the full compiler output (make a clean build!). There's nothing you have to define yourself. Following the Keil µVision guide should give you instant success. If you keep having problems you can also post a screenshot of your project files tree and the C/C++ include paths list. This way we can help you most effectively. A general recommendation: Start off by not enabling any of the modules in your configuration file. This way you can check whether everything builds well and whether the µGFX core is working well. You can actually compile & run a µGFX application without any display just using the GOS module.

Hello @jkraptor, Unfortunately I won't be able to test this as I won't have access to a Mac until the coming Monday. I guess the quick solution is to use SDL2 32-bit as that is what we used ourselves for testing. Other than that I'm not sure whether simply changing the OPT_CPU value in the OS X / MacOS makefile is going to do the trick (in the file /tools/gmake_scripts/os_osx.mk). Maybe @inmarket has something more helpful to say right.

Looking forward hearing about your progress. Don't hesitate to ask if you have any questions!

Or you might just want to create a new forum topic, post the errors you're encountering and ask the questions you're having and we're happy to help you wherever we can. Stating that µGFX "is not ready for commercial compilers" is compilers is completely false and an immature comment. It's being used by hundreds of companies and even more hobbyists and educational institutions. If you are having difficulties the forum is always there to help. But just creating an account to make such a statement is silly. Have a look at other forum topics to see how it's done - we simply can't help you if you don't ask any questions. We're also thankful for any feedback to improve documentation where needed. I assure you that the µGFX library is being crafted very carefully to work with every possible environment and platform. That is what might make it look complex for beginners but that is what this forum is here for. So far we have never encountered a case where somebody couldn't get µGFX up and running - provided that he actually asks questions and informs us about the difficulties he's having.

Hello @bcsavas and welcome to the µGFX community. That's currently not on our ToDo list. We'll do it either when we get to it in our spare time, when the demand is really heavy or when somebody pays us to do it. However, I can't imagine that the new API will be that much different so probably the existing port could be simply copied and adapted. And even if that is inefficient: Writing a port for a new RTOS is very easy. If you feel like giving it a go don't hesitate to ask any questions - we're happy to help.

While I agree with this I'd like to point out that the support for rectangle drawing / area filling is a huge performance booster when using a slow interface such as SPI. uGFX uses solid filled rectangles wherever possible because they are often supported by the display controller. Many drawing operations are broken down to area filling wherever possible to take advantage of this. Keep in mind that when you have a GUI where you have multiple display pages (different "views" / pages with completely different widgets on them, basically like menus) you have to clear the display when switching between them. This means that the entire display needs to be filled with a solid color -> rectangle filling. When the hardware doesn't support this your CPU has to do it. This means that your CPU needs to manually set width * height pixel values. When using an interface such as SPI this will be anything but fun. It's very easy to add support for new display controllers - especially as these are almost always very closely related to each other (often just differences in the maximal resolution). You can use any interface you want. The µGFX GDISP driver doesn't care about that. That is what the board files are there for. You configure your microcontroller's peripherals and GPIOs in the board_init() function in the board file. On a side note: +1 for using the 8-bit parallel interface instead of SPI.

Hello @Jim and welcome to the µGFX community, The performance improvements from using a parallel instead of a serial interface can be calculated very easily - no magic behind that. As for other techniques it's a lot more complicated as mentioned by @inmarket. It starts by the fact that using DMA doesn't necessarily speed up anything. It just frees the CPU to do other things in the mean time. I put writing a guide about all these things on our ToDo list. I'll guess we'll best get started by simply adding @inmarket's post to the wiki and extend from there over time.

One thing I'd like to add is the availability of hardware acceleration: Some display controllers provide hardware acceleration. Many (such as almost all of the SSD family) only provide hardware acceleration for rectangle drawing but that already brings a huge performance improvement when using µGFX. When sticking to your STM32F103 choice and not using a proper parallel interface (FSMC) I would strongly recommend picking a display controller that supports at least hardware rectangle drawing / area filling. This is basically a "must have" in my opinion. The performance benefits are immense. Other than that other display controllers such as the RA8875 also provide hardware accelerated polygon drawing and similar which can further speed up your GUI and free CPU resources. I guess @steved and @inmarket mentioned all the other important factors.