Joel Bodenmann

I'll take a look into this this evening. I'll keep you posted. ~ Tectu

Using the GFILE to be able to read and write these configs to any file sounds sane. However, I'd definitely keep the GFILE magic hidden behind a real uGFX configuration API. This could become part of the core system (gfx.c) in form of: gfxConfigSave() gfxConfigRead() gfxConfigXxx() About the buffer size: I'd recommend to make the first few bytes the information about the size of the actual content. One could then read out these few bytes, allocate the space and continue reading. This could either be implemented in form of gfxConfigGetSize() or simply doing it manually in gfxConfigRead(). ~ Tectu

Hello Steve This sounds like a good idea and it's definitely suited for the future. Both, Andrew and I, are very busy at the moment. As soon as we finished our current tasks, we'll take a look at this. I'm sure that Andrew has some more comments on his own as well :-P ~ Tectu

Could you please attach your project? The important files are: main.c (any any other related sources) Makefile gfxconf.h board files One more thing to check: Can you please make sure that the backlight is on? You should try to manually enable it in your main source files first. It's very likely that your display is actually displaying it but you just can't see it as the backlight is off. Also, when the backlight is on the screen might either be white or filled with garbage. The later would indicate a successful display controller initialisation. We're more than happy to help where we can. ~ Tectu

This is strange... I took my Embest hardware and I don't experience this issue at all (the backlight is a problem indeed. That one used to work but got merged the wrong way at the end). Could you try to find something like a version or revision number on your Embest LCD board? ~ Tectu

Hello himsha and welcome to the community! We need a lot more information to help you with this one. uGFX version (or repository state) Underlying operating system used (the GOS port you use) The microcontroller that you are using The clock setup of your microcontroller And the most important thing: Please attach your board file (gdisp_lld_board.h). I don't understand your question, I'm sorry. Could you try to rephrase it? ~ Tectu

Hello Wolf, Sorry for our late reply but as we mentioned in the Announcement section we were not only for a couple of days. Do you still have the problem? I took out my STM32F407-Discovery board with the same Embest baseboard + LCD module and everything works as expected here. Could you please attach your main.c (test case) and your gfxconf.h? ~ Tectu

Hello pgeiem and welcome to the community! Looks like you're just in time! We have added a generic framebuffer driver for the GDISP module just yesterday. You can find it under /drivers/gdisp/framebuffer: https://bitbucket.org/Tectu/ugfx/src/1f ... ?at=master To use it, you only have to write the board file. The board file is the interface between the software driver and your actual hardware. You can find a corresponding template in the drivers directory. About the GOS port: You can use the raw32 port which is also part of the official uGFX repository. The port allows it to run uGFX on any bare-bone system. To make it run, you only have to implement/provide the following two functions inside your project: systemticks_t gfxSystemTicks(void); systemticks_t gfxMillisecondsToTicks(delaytime_t ms); The first routine gets a "tick" time from the hardware. The 2nd routine converts a number of milliseconds to a number of ticks (normally just a division by a fixed number). I hope that helps. Let us know should you face any problems. ~ Tectu

Hello Fede, Thank you very much for your contribution. However, the TDISP module has been removed a long time ago as it does not fit the projects goal (anymore). ~ Tectu

We'd welcome any feedback and bug fixes for the FreeRTOS support that is now part of the master branch and therefore the upcoming 2.1 release. ~ Tectu

There's no reason to feel bad about anything! The software is far from bug free and we appreciate any bug report. I'm glad that you got it working ~ Tectu

Thank you very much for another great bug report & patch. It has already been commited. I added your name to the contributions table. If you want you can tell me your real name and I'll add that one as well. ~ Tectu

I just gave it a quick try on the Embest-STM32-DMSTF4BB board (the STM32F407-Discovery with the LCD extension) and the demo works nicely out of the box. Could you track down the problem any further in the meantime? Have you tried a custom image instead? Does another demo, for example the list widget demo, work without any problems? Edit: There was a bug fix in the mean time. Can you please update to the latest master branch? ~ Tectu

Hello iccp, I'm sorry that I didn't have time to come back to you yet but I turned sick and I have to stay in bed for a day or two. I apologize for the inconvenience. ~ Tectu

I'm currently on the road so I can only test with the simulator and there everything works just nicely. I assume that the problem is with the color format. Have you tried to convert and display an image on your own? Either way, I'll be at home in about one hour so I can have a closer look. Edit: This might take some longer than expected - I turned sick. ~ Tectu

Either that or we could also probably just take out the definitions for TRUE and FALSE from the generic GOS code and put it into the actual port. This way one could simply do the following in the freertos.h file: #define TRUE pdTRUE #define FALSE pdFALSE ~ Tectu

Thank you very much for reporting this bug, it has been fixed. Please note that you'll have to enable the auto increment feature by setting GWIN_PROGRESSBAR_AUTO to TRUE in your gfxconf.h from now on. ~ Tectu

Thank youfor your research. How do you suggest to solve this problem? So far I've only seen #defines for the TRUE and FALSE values. This way it was fairly easy to avoid colisions using #ifndef within our own implementations. But an enumeration seems to put up some issues... ~ Tectu

That would be very appreciated. All sorts of bug reports or even just feedback helps us to improve the quality of the project. Currently we are heavily searching for people who create demo projects or simply show us a link to their blog. We really need to fill up our demos section on the website. ~ Tectu

Hello cruz and welcome to the community! Thank you very much for reporting this bug. That line is indeed wrong and I've already fixed it in the master. I'll backport it to the 2.0 release ASAP. Personal hint: We'll release uGFX v2.1 this weekend. You probably don't want to start using the 2.0 release right now but directly stick to the master. ~ Tectu

Hello iccp, I'll have some time tonight and/or tomorrow afternoon to digg into the reference manual again. It has been quite some time since I last used the FSMC peripheral from scratch. You mentioned some external address decoder, did you make sure that you handle it properly? Also, have you ever run the official example provided by the board supplier to make sure that it's no hardware issue? I know, this is not very likely but just in case... ~ Tectu

I'm glad to hear that you got it compiled! I plan to release the uGFX version 2.1 this weekend and the FreeRTOS will be reworked and merged into the master branch by then. I hope you can enjoy a full FreeRTOS support by next week :-) About the True/False problem: Can you please track it down and make sure that it is caused by uGFX? Because in the current FreeRTOS port we do not define TRUE and FALSE as those definitions are already provided by FreeRTOS itself. ~ Tectu

Hello iccp, I'm sorry but I won't be able to take a closer look to this within the next 6 hours. Have you ever tried to lower the FSMC bus speed? ~ Tectu

I'll get back to this soon. ~ Tectu

Hello iccp and welcome to the community, You say that the display is connected to Bank4 but out of my mind it looks like you try to initialize Bank0. This could lead to a hardfault and therefore freeze everything. I haven't taken a closer look to the reference manual but please check this to be sure. Back the days I've written this little guide leading you through the process of using FSMC with ChibiOS/RT. Probably that is of any help. The next thing I've noticed is that you actually touch the GDISPControl struct. This is a very bad thing to do. You're not supposed to ever come into contact with that struct and that's why it's nowhere documented nor listed in any examples. Please use the official API to change stuff like the orientation, backlight, contrast and so on to prevent anything bad from happening. I recommend you to use the demo you can find under /demos/modules/gdisp/basic until you get your display working. One more recommendation: Until you have a debugger, modify the hardfault routine of ChibiOS/RT in order to flash an LED for example very fast. This way you at least know whether it is stuck somewhere or something bad happened. ~ Tectu