Joel Bodenmann

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.

I assume you're referring to the Tetris demo as you already asked in the comments of that video. You can find the demo in the /demos/games/tetris directory inside the µGFX library directory.

Hello Matthias, The solution is simple: You can keep using our RAW32 scheduler but you only have to implement the two functions in assembly for the context switching: _gfxTaskSwitch() and _gfxStartThread(). This is how it's done for all the Cortex-M processors currently as well in order not to rely on the setjmp() and longjmp() implementations. You can have a look at the file /src/gos/gos_x_threads_cortexm347.h to have a look at how we implemented them. Simply create a new file like that for the LX106 processor and implement the two functions. You can see that we even implemented them twice using different types of assembly (embedded and in-line). One thing that comes to mind: Is it possible that your used library provides setjmp() instead of _setjmp()? We have seen this before which is why we have this code (line 217 of /src/gos/gos_x_threads.c: #if (!defined(setjmp) && !defined(_setjmp)) || GFX_COMPILER == GFX_COMPILER_KEIL || GFX_COMPILER == GFX_COMPILER_MINGW32 || GFX_COMPILER == GFX_COMPILER_MINGW64 #define CXT_SAVE setjmp #else #define CXT_SAVE _setjmp #endif #if (!defined(longjmp) && !defined(_longjmp)) || GFX_COMPILER == GFX_COMPILER_KEIL || GFX_COMPILER == GFX_COMPILER_MINGW32 || GFX_COMPILER == GFX_COMPILER_MINGW64 #define CXT_RESTORE longjmp #else #define CXT_RESTORE _longjmp #endif If you have those, then properly setting your compiler (and probably modifying the lines shown above) might solve your issue as well. These two things are actually the reason why the GFX_CPU and GFX_COMPILER options exist in the configuration file. However, we always try to to provide implementations which work for most cases.

Hello @Mutasim, The µGFX-Studio doesn't care about your hardware. The code it generates is high-level µGFX application code and therefore completely portable. It is correct that you can just copy-paste the generated code into your existing project - that is the intended way of using it. We even support post-generation scripts to automate this step.