Joel Bodenmann

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

Hello Dmytro, Beside the leading dashes in line 26 and 27 I cannot find any issue in your Makefile so far. I just synced the FreeRTOS to the current master branch and then tried to rebuild my SSD1289 project and everything works just fine. As you might be on the old FreeRTOS branch, could you please pull the latest one? I tried it with ChibiOS/RT instead of FreeRTOS but I am pretty sure the GOS port is not the problem here. ~ Tectu

I took a look and I couldn't find any obvious error so far. I assume that you have some build issue. Are you sure that you properly include everything into your projects Makefile? I know that you're not using ChibiOS/RT but you can still take a look here to see which parts are uGFX relevant. They have been hilighted. Don't forget to include GFXSRC and GFXINC. Can you please attach your entire Makfile (or even the entire project) and the compiler output log? Hint: Somebody just pull requested fixes to the FreeRTOS port ~ Tectu

I will take a look at this in a few hours. I am currently on the road. Are you using the current FreeRTOS branch? Make sure you merge it to the master first, it hasn't been synced for quite a while. Talking about this: I am reworking the FreeRTOS port right now. It is very dirty and incomplete. However, as our website states we are searching for testers. We'd be very thankful if you could help us getting this port ready so FreeRTOS can be officially supported by the 2.1 release which should come up in a few weeks. ~ Tectu

Hey Dmytro, nice to hear from you again The SSD1289 driver appears to build correctly with all my boards here. Can you please show your complete board.mk? I assume that you don't include the driver code correctly. Your board.mk should look like this: GFXINC += $(GFXLIB)/boards/base/Land-Tiger-LPC1768-LCD GFXSRC += GFXDEFS += -DGFX_USE_CHIBIOS=TRUE include $(GFXLIB)/boards/base/Land-Tiger-LPC1768-LCD/chibios_board/board.mk # This is optional, remove if unneeded. include $(GFXLIB)/drivers/gdisp/SSD1289/gdisp_lld.mk include $(GFXLIB)/drivers/ginput/touch/ADS7843/ginput_lld.mk You can zip and attach the whole board directory and I'll have a look at it. ~ Tectu

Hi radiotech, The bare metal port has been finished and is available from the repository. You can enable it by setting #define GFX_USE_OS_RAW32 to TRUE in your gfxconf.h. Please feel free to open a new thread should you face any problem. ~ Tectu

Hello, I just took out my hardware and tried it out with the current code. I couldn't find any issue, everything seems to be working as expected. Can you please describe the problem that you are facing a bit more detailed - probably include a test case code snipped? Probably I'm not understanding your problem correctly. ~ Tectu

This feature has finally been added: https://bitbucket.org/Tectu/ugfx/commit ... 5cc557c2f7 As we couldn't come up with any usecase for other widgets than the list, it has been implemented directly into the list widget API. ~ Tectu

Thank you very much for reporting this bug. I'll take a loot at this tonight. ~ Tectu

Thank you very much for all your time and effort. ~ Tectu

Sounds good to me! Every new driver adds value to the project as it helps especially new comers to get their projects worked more quickly. ~ Tectu

Shilow, I've reviewed and added your driver to the repository. Can you please get to the latest master and try the integrated driver out and report any issues? I assume that this driver now works with all four orientation modes. I've also added you to the contributors list. Should you want to get your full name listed, please PM it to me. ~ Tectu

I checked your permission and I don't see any problem there. I even tried it out myself (with your permission and it seems to work). Don't you find the necessary button/link or do you get any error message? ~ Tectu

What's exactly the problem? ~ Tectu

I recommend you to send a private message to zump so he gets an e-mail notification. You can do that by clicking on the username. ~ Tectu

Well in that case we're going to need two separate drivers indeed. Could you guys provide a working drives which works correctly in all four orientations so they can be added to the repository? Please find out the correct controller name and revision. ~ Tectu