Joel Bodenmann

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.

Glad to hear that you got it up and running!

Hello Matthias, Yes, there is a way: Set the GFX_CPU in the configuration file to GFX_CPU_CORTEX_M4 (or whatever is the correct one) and you won't rely on setjmp() and longjmp() implementations. You can find the corresponding documentation here: https://wiki.ugfx.io/index.php/GOS#CPU

Hello Renan, That is not easily possible with what the current version of µGFX has to offer. You either have to use your own algorithm to achieve that or you resort back to bitmaps (or full blown images).