Joel Bodenmann

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.

Glad to hear that you managed to get everything up and running!

At the end you just need to create a wrapper or forwarding drawing function because the one that takes the justification parameters is internal only at the moment. You need something like this: GFXINLINE void gwinLabelDrawJustified(GWidgetObject* gw, void* param) { gwinLabelDraw(gw, param); } That should do nicely. I put adding that function to the repository on our ToDo list.

And of course don't hesitate to ask if you have any questions - we're happy to help wherever we can

Hello @harsha, The TextEdit widget currently doesn't support that feature. However, it can be added without any problem. The GWIN module provides everything necessary to do so. Please don't hesitate to contact us if you're interesting in getting a quotation if you want us to do it for you.

Agreed. If the characters themselves are not being drawn then there's something very wrong. Don't forget to make a clean-build if you changed something in the configuration file.

Hello Rafael, The characters being drawn incorrectly in the screen indicates that you didn't set GDISP_NEED_MULTITHREAD to TRUE which will make the entire GDISP API become thread safe. The GWIN console widget itself is however not multi-thread safe so you have to protect access to it yourself. The solution depends on your application. You can either go with a classic producer/consumer where you have just one consumer (the sole thread that writes to the console) and multiple producers. Alternatively you can simply use the a mutex to protect access inside your application. Note that we strongly recommend using the µGFX high-level API such as gfxMutexCreate() and similar to keep your application portable. They are simple wrappers (often just macros so no overhead) towards the corresponding FreeRTOS mutex API. I hope that helps.

Hello @gattis and welcome to the µGFX community! The µGFX library currently doesn't come with a driver for the FT801 display controller. However, it would be fairly simple to create one. This is something that you can do yourself. The display driver interface is explained here and there are plenty of examples as there are already over 37 existing display drivers reaching from simple monochrome drivers to framebuffer drivers to full blown multi-buffering with hardware acceleration drivers. You should definitely be able to write a display driver for that display / display controller. Please don't hesitate to ask if you have any questions, we're happy to help. Alternatively we offer writing display drivers for you as part of our paid support services.

Hi, Judging from the video this appears to be a bug in the TextEdit widget.

A couple of things come to mind: 100 MHz feels like a bit too high. Check the SSD1289 datasheet to ensure that it can actually handle that frequency. Also, keep in mind that you'll have to adjust the timings to take propagation time, parasitic capacitance and other things into account if you connected it with long(er) cables. It's recommended to start with something a lot slower like for example 10 MHz or even 2 MHz until you're sure that everything works. You can always increase your bus speed and adjust timings to work faster afterwards Most display controllers require a way slower bus speed for the initialization. Often you can increase the speed afterwards but the initialization must happen with a lower frequency. This is what the post_init() is there for in the board file: To increase the bus speed after successful initialization. Check the reset pin polarity (as already mentioned by @inmarket), from the top of my head I think you got it the wrong way around. Make sure that nothing else changes the FSMC pin configurations after your FSMC_Init(). That can easily happen when using a tool like CubeMX. This is why we usually recommend to copy the FSMC initialization that was generated and putting it into the board_init() anyway to prevent those kind of problems. Most display controllers have a jumper (physical connection) that determines which interface is used. Check the SSD1289 datasheet whether you have to do something special to use it in 16-Bit mode (maybe it's 8-Bit mode by default).

Yes indeed. Glad to hear that you managed to get everything up and running!

There's your problem. You must not include \..\..ugfx\src in your include paths. Note that it's also not shown in the guide

Ah sorry for the confusion. I thought you were trying to use a custom font (after all you can use a custom DejaVuSans12 font in case of you're playing with different conversion parameters). So, if I understand you correctly you were never able to display any string on your hardware right? The issue is known for when you're not including the proper files or when the order of the inclusion isn't right. Unfortunately I don't have access to a Keil µVision right now. Could you provide us with a screenshot of your C/C++ include paths? Also, never forget to make clean builds when changing something in the configuration file.

Hello James and welcome to the µGFX community! We're glad to hear that you managed to get everything working inside Keil µVision. My first question to resolve this problem is: Are you able to successfully display some text (rendering strings) on your hardware when using the built-in fonts? Are you getting that compilation error only when using µGFX-Studio code?

@wctltya: Vertical alignment options have been added: https://git.ugfx.io/uGFX/uGFX/commit/d8c9ca184f29800f6c23d02bc450ea0e67981990

The makefile is complete. There's the OPT_OS variable in there which will be used to include the proper operating system specific makefile at the bottom: include $(GFXLIB)/tools/gmake_scripts/os_$(OPT_OS).mk All you have to do is downloading the appropriate version of ChibiOS adjusting the GFXLIB and CHIBIOS paths in the makefile and you should be able to build a demo for that board using µGFX + ChibiOS. If you don't want to use our own high-level makefiles you can just add the necessary things to the ChibiOS makefile which is explained here: https://wiki.ugfx.io/index.php/Using_ChibiOS/RT Note that you're not forced to use ChibiOS at all. µGFX runs with any underlying system or none at all (baremetal). It's just what the example uses you're referring too. Another thing: Please don't always quote the entire previous forum post you're replying to unless you're referring to just a specific bit or an older forum post. It's very difficult to read the topic otherwise. You can just reply without any quote.

That problem is not related to µGFX at all but is a problem with your c library as @inmarket mentioned. Your linker can't find the definition of the assert() function which is part of the c library - not of the µGFX library. There's not much we can do here as it's completely out of our hands.

What do you mean by "what library I should use"? There's a guide that shows how to add the µGFX library to any existing Keil µVision project that you can find here: https://wiki.ugfx.io/index.php/Using_Keil_µVision_5_MDK-ARM Additionally there are a hand full of ready-to-run Keil µVision projects that you can find in the downloads section: https://community.ugfx.io/files/category/2-example-projects/

Glad to hear that you could find it. Please don't hesitate to ask if you have any other questions. We're happy to help.