Joel Bodenmann

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.

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