Joel Bodenmann

Glad to hear that you are proceeding with this Once you have a GOS port the best way is to disable all the modules in the configuration file (including the GDISP module). So make sure that all GFX_NEED_XXX such as GFX_NEED_GDISP are either set to FALSE or commented out (as FALSE is the default value for those). Try to compile a hello-world program (basically a main() where you call gfxInit() and nothing else). This way you can ensure that your build setup is working correctly. You can also run one of the GOS demos that you can find in /demos/modules/gos to ensure that your GOS port is working as expected. Once everything builds and your GOS port works you can enable the GDISP module by setting GFX_NEED_GDISP to TRUE in the configuration file. The GDISP module is one of the modules that requires a driver to compile. The drivers can be found in the /drivers/gdisp directory. The best thing is to use the so called TestStub driver first. This is a driver that implements all the interface required to compile but has no implementations (so it doesn't actually to talk to hardware) but it allows to ensure that everything is building correctly. Once you're this far it's time to either use an existing GDISP driver or writing your own. When using an existing GDISP driver you have to include the driver's source file in your compilation and the driver directory in the compilation/linking path. The various guides in the wiki explain how to do this. GDISP drivers require a board file. Each driver has a file named board_xxx_template.h in the driver directory. Copy that file to your project and rename it to board_xxx.h where xxx is the given name of the driver. The board file is the place where you actually tell the driver how to talk to the display. It usually contains the SPI, I2C or parallel peripheral HAL function calls. When I understand you correctly you're working with a setup that already has a working framebuffer. Therefore, you can use the existing generic framebuffer driver that you can find in /drivers/gdisp/framebuffer. You'll see that the board file for this driver is especially easy to implement as all you have to do is passing the pointer to the framebuffer in the board_init() function. However, don't forget to also set the proper olor/pixel format with the given #define at the very top of that board file. An additional side note which you might just ignore in case of you don't know what I'm talking about: If your framebuffer is using a packed RGB888 or BGR888 format (24bpp) you have to use the latest repository master branch instead of the latest stable release as there's now an additional dedicated framebuffer driver for that. You can find more info about that in our latest blog post. I hope that helps. Don't hesitate to ask when you have any questions.

Okay, here's your example: And here's a ZIP containing the entire code, the two source images and Makefile to run it directly on a Windows machine: win32_custom_rendering.zip There might be some issues with the calculation of the coordinates of the images (line 32 and 37) - I didn't spend much time on it. One of the things that comes to mind is that the image sections are not vertically centered. But this should definitely get you started. There are other things which you might want to consider such as image caching.

Let us know if you'd like us to write a quick example for this.

Great, thanks for sharing!

Hi, There's currently no driver for that display from our side. However, writing one is very easy. I once wrote one for that display controller but that was for a paying customer that didn't allow us to put it into the public repository. The split areas (two controllers) are not a problem either. Write a driver that handles the full display area and then simply check for the X coordinate and select the appropriate controller to talk to.

Sounds great! Publishing your project will definitely help others in the future Don't hesitate to ask if you have any questions. We're happy to help wherever we can.

Well, those modules are made to be as cheap as possible. It's very likely that they re-use the same PCB from another module. Not much we can do about that. At least it helps to keep the price down

Hello @HWG and welcome to the µGFX community! You definitely don't have to write your own window manager to achieve this The proper solution is to write a custom widget which is a lot easier than it sounds the interface is well documented and there are tons of examples and even a step-by-step guide on how to do that. However, there's an easier solution: You can take the container widget and write a custom rendering routine for it. In that custom rendering routine you draw your two images by using gdispGDrawImage(). That function allows to specify what portion of an image you want to draw. Writing a custom rendering function is also very easy and well documented and there's also a how-to guide: https://wiki.ugfx.io/index.php/Creating_a_custom_rendering_routine I hope that helps. Please don't hesitate to ask if you have any further questions. We're happy to help wherever we can!

Glad to hear that you managed to get it up and running. You can post your project in the user projects section: https://community.ugfx.io/forum/6-user-projects/ What do you mean by "printed on"? On the PCB?

Take one of these SSD1963 based ones and hook it up to the FSMC interface of your STM32 and you'll be fine: http://www.buydisplay.com/default/tft-display/5-inch

I put that on the ToDo list, thank you for your feedback.

Hello Joe, All that #include does is literally copying the contents of the included file into the file at the location of the #include directory. There's nothing that tells you that you can only include header files. In fact, you can include anything. If you want, you can include a word document, an MP3 file or some Java code. It's copy-pasting that the pre-processor handles for you prior to compilation. However, I agree that it is somewhat unusual. Includes are indeed usually just used for header files due to how the software is usually structured on the source code level. The reason for including the C files is exactly what you mentioned: This way we can provide a very easy way to pull in all the source code while automatically resolving all dependencies through the pre-processor by just giving the user one single file to include. To summarize: It's uncommon, but it's completely fine. You must not touch any parts of the µGFX library or the library source code structure. Copy the entire directory to your project and include the gfx_mk.c file. Everything you don't use (like some of the "modules" that you mentioned) will not be included in the compiled binary at all because the pre-processor throws them out. You specify in your configuration file (gfxconf.h, there's an example/template named gfxconfig.example.h in the root directory of the library) what you want to use. Everything that is turned off will be thrown out by the pre-processor. For example: Let's assume you only want to draw raw strings, you don't need the window manager and widgets: Simply set GFX_NEED_GWIN to FALSE (which is actually the default) and the compiler will never even see this code. You can find more information about all this and a complete list of all configuration options with explanations and documentation reference in the wiki. Do not attempt to only include some files and directories yourself. You'll run into a lot of pain. Internally everything is structured to be optimized at pre-processor and compile time. You will not use a single byte of memory or a single CPU instruction if you don't explicitly enable the stuff in the configurations file. No matter whether the directories & files are in your project tree or not.

Glad to hear that you managed to got it working! Well, somebody screw up the API naming

This is normal. The µGFX library heavily relies on the preprocessor. There are very complex constructs in there that those lexers are simply not "smart enough" to comprehend. Furthermore, there are some (or many) things that change during the preprocessing stage. There are defines that get changed one or multiple times during the compilation to create static lists and similar. The sane thing to do is simply disabling the eclipse lexer / interpreter stuff. The compiler is there to tell you when there are issues.

Yep, that's also how it's done for the DMA2D stuff. That's definitely the better way of doing it.

Hello @Joe Stepien and welcome to the µGFX community! We haven't found a previous post from you in our logs. There's also nothing to review. Not sure what happened there. We haven't heard of any other issue like that before. Let's assume that it was just a glitch or miss-click at some point. Please don't hesitate to let us know if you keep experiencing issues with this forum. The simplest way to add µGFX to an existing project is by using the single file inclusion mechanism. That allows you to add just one single file to your project instead of the entire directory which can become difficult and cumbersome to manage. This is documented here: https://wiki.ugfx.io/index.php/Getting_Started#Single_File_Inclusion We don't have a step-by-step guide for IAR but we have one for Keil µVision which uses the same technique. You can find it here: https://wiki.ugfx.io/index.php/Using_Keil_µVision_5_MDK-ARM That should definitely help you to get started. Yes, it is --> https://wiki.ugfx.io/index.php/Images#Examples Follow the guide above to add the µGFX library to your existing project and you should be ready to go. Of course you have to read a bit of documentation. The µGFX library is very easy to use but very complex inside to achieve that (and other features such as complete portability). Unless you can use one of our ready-to-run projects you'll have to spend a couple of minutes to read through the various articles & guides that you can find in the wiki, some of which are linked above.

Unfortunately it is a lot more complex than that. In order to be useful, the gdispDrawString() (and similar) calls still need to have their effect as the higher-level items such as the widgets and user applications depend on them. This means that the font rendering stuff needs to be intercepted below that level. Basically you'd have intercept between the GDISP layer itself and the font rendering engine. However, this gets complex because you have no longer control over the fonts, unless you can load them dynamically to the font engine chip through the gdispOpenFont() function and the main problem is that you have to reproduce the exact behavior in terms of color filling, justification and so on.

That driver actually shouldn't be part of the library anymore, we wanted to throw it out a couple of months ago but seems that we never actually did it. The reason for that is because it appears that the author of the driver (a member of the community) just simply copy-pasted the Adafruit driver and when I remember correctly the Adafruit license doesn't allow for that. We'd appreciate it if you guys could develop a proper µGFX driver from ground up.

Hi, I took your forum post (above) out of the topic you posted it in and created a new one as it was getting heavily off-topic. To your question: There's no high-level API to check whether a flush completed. This is something you'd usually take care of in your low-level driver as you mentioned. If the information is needed in other parts of the application through a high-level interface then using the GDISP Query capabilities is the right way to go (gdispQuery()).

Hello @lerix and welcome to the µGFX community! The µGFX library has been designed to run on any system and on any OS. Therefore, you should definitely be able to run µGFX on your OS. What you have to do is creating a port for the GOS module. The GOS module provides a generic high-level abstract layer towards the underlying operating system that all other components of the µGFX library area using. Read up the various documentation regarding the GOS module to learn how to write a port, it's really straight forward. You can also find plenty of examples in form of existing ports in the /src/gos/ directory of the µGFX library.

Yes, that for sure. This would completely bypass any font engine provided by µGFX itself.

Also, welcome to the µGFX community!

I think that the deal here would be to use the hardware font rendering offered by the RA887x chip. You can give it some font files which it stores in its own flash and then you simply tell it where to render what font with what color. So it's the same deal as with the other hardware accelerations for the shapes: It's a matter of bypassing the µGFX font rendering and sending the proper commands to the RA887x chip to let it do the job. However, this one might be a bit more complex as you have to load the font at some point into the font memory of the chip. Using the GDISP control interface might make sense here.

As @inmarket mentioned the files from the forum post linked above are definitely working. It's just that it's using the video mode instead of the adaptive command mode. That is not even hacky - it's just a different mode. µGFX would benefit from using the adaptive command mode, that would increase the performance and free system resources compared to the video mode. In this case it's really just about the GDISP driver, not the rest of µGFX. Therefore, that might be a really good way to start the dive into µGFX as the driver is somewhat "isolated" and the interface is well documented. However, you'll still learn a lot about how the GDISP module works and from there the journey can continue As always: Any help is highly welcomed.

We're happy to provide you with one - we really appreciate the time you put into this ChibiOS issue. Please don't hesitate to PM me in case of you're interested. As far as I'm informed the latest state are these files in this forum post: