Joel Bodenmann

With the method mentioned above it is only possible to rotate by 90 degrees as your display won't provide any other orientations that than. When we will implement this feature ourself it will be most likely possible to rotate by 90 degrees as well as by any degree value (the 90 degrees will just be a lot quicker). ~ Tectu

Depending on the GCC version that you are using you might encounter a linking error when building an uGFX project under Linux. This is due to a very well known bug in one of the latest versions of GCC. To bypass this problem, simply disable the LTO feature. When you're using our Makefiles you can just set the OPT_LINK_OPTIMIZE macro to no: OPT_LINK_OPTIMIZE = no This will produce a slightly larger binary but on a Linux enviornment this shouldn't be that much of a problem. ~ Tectu

No problem, I know this situation. Worst thing on earth ~ Tectu

It looks like we won't have time to get this done within the next couple of weeks as we are working on some other quite vital parts of the uGFX project. Did you proceed in any manner? ~ Tectu

Thank you very much, we just fixed this as well: https://bitbucket.org/Tectu/ugfx/commit ... e2b551775a Please keep us up to date about any other upcoming bugs. We are thankful for any bug report as this helps to drastically increase the quality of the library. We also just added you to the community table on our website. We can add your real name if you like. ~ Tectu

Thank you very much, we have just fixed this issue: https://bitbucket.org/Tectu/ugfx/commit ... 39aa742c06 We appreciate bug reports like this a lot! ~ Tectu

Hello Tobi and welcome to the community! We have experienced many many problems with all the ILIxxxx based display controllers over the time. Most issues were related to the fact that Chinese sellers claimed to send you an ILI9320 but you actually got an ILI9325. Then there are too many different revisions of the same chip out there all with something different. When your D15 pin/bit would have a problem you would clearly not be able to successfully use the screen after modifying the version in the driver source. You would not only see colors that are completely wrong but you would most likely not be able to initialize the controller at all. Therefore, I think we can rule out this problem. If everything is working for you I can add that particular version number to the driver. ~ Tectu

I haven't had any time to take a closer look at the driver yet. I don't even have such a key pad. However, we will take a look at your work and include it into the repository. Maybe somebody else will have time to give this a try Anyway, thank you very much for your contribution, we appreciate it a lot as things like this help to not only push the project forward but also to build up an active community. Edit: inmarket is currently working on the keyboard part of the GINPUT driver. As this would be used with that keyboard driver he'll take a look. ~ Tectu

That is correct. It is recommended to place all your files you want to upload into a .zip file as these files are attachable. I'll let inmarket handle this driver issue. ~ Tectu

Hello Loosa and welcome to the community! I'm afraid the console widget itself does not support unicode. This widget was one of our earliest ones and it was mainly intended to be used for debugging purposes. We never thought that it will actually be used by end users. Therefore, it provides only very limited functionalities. We should probably plan to rewrite the entire widget soon. If you end up writing your own (which is actually quite easy due to the classes provided by the GWIN module) we'd be happy to see your code. We'd also be more than happy to help you wherever we can. ~ Tectu

Hello ellboy and welcome to the community! There is currently no API that allows string rotation but we are planing to include that soon. We already added matrix rotation alogrithms to the GMISC module a couple of days ago. However, there is a small work around: You can change the orientation of your screen, draw the string and change the orientation back again. Note that this method however only works if you have a display controller that does not redraw the framebuffer content when you change the orientation. This is the case with most display controllers such as the SSD and the ILI families. ~ Tectu

You shouldn't include the font source files (*.c files) into your build tree manually as they are already included by the top-level font file. Removing all the .c files should fix this linking error. ~ Tectu

The MAX11802 touchscreen driver by steved has been added to the repository. ~ Tectu

Glad to hear that it is working! Please let us know what you did with uGFX in the end. We are stil searching for projects for our demo site on the project homepage ;-) ~ Tectu

We appreciate every new port and we are more than willing to help whenever you have any question. I'm sorry but I don't really understand your question. uGFX does not have to do anything with IDEs. It can be used with any IDE or even with the built-in Make system. As every IDE does handle the build and file tree differently, there's nothing we can do but just give a step-by-step guide that can be found in the wiki. ~ Tectu

Hello Moran and welcome to the Community! There is currently no uGFX port for mbed.org at all. However, with some basic C knowledge it should be possible to implement this by yourself. There's a module called GOS in the uGFX system. This module handles the OS abstraction and that is what you need to implement. You should start by adding the two files /src/gos/mbed.c and /src/gos/mbed.h. There are by now many OSes that are already supported and therefore you should have plenty of implementation examples that should give you an idea. The two most important ports that might serve as a good template to you are the ChibiOS/RT and the FreeRTOS port. When it comes to RTOSes, most routines can be implemented using simple #define wrappers anyway. Sadly the wiki article about creating a new port is far from complete: http://wiki.ugfx.org/index.php?title=GOS However, the forum is always here to help you out whenever you face any issue. We're looking forward for your new port ;-) ~ Tectu

It would be easier for us if you could attach your complete compiler output log. ~ Tectu

Hello baptistes and welcome to the community! Same here, that's why all our code is 100% Makefile based ~ Tectu

Now we hit a different problem: We have many issues with the ILI based display drivers because they exist in many different versions. Often you get an ILI9320 instead of an ILI9325 and vice-versa. In order to finally get your display running, please take the initialization code (that are all the write_reg commands in your LCD_Init() routine and replace the ones in the drivers initialization routine (gdisp_lld_init() routine in /drivers/gdisp/ILI9325/gdisp_lld_ILI9325.c) with them. Let us know when you have any questions. We are sorry for this inconvenience but we have not found a good solution to this problem yet. We will add an optional custom initialization code interface in the future. ~ Tectu

You are NOT supposed to manipulate any register values of the controller in the board file. The only thing that you are supposed to do in there is to set up the GPIO modes and stuff like that. For starting your post_init_board() routine should be empty and your init_board() should contain all the GPIO code. Your board file should look something like this (just so you have a structural idea - this will not compile): /* * This file is subject to the terms of the GFX License. If a copy of * the license was not distributed with this file, you can obtain one at: * * http://ugfx.org/license.html */ #ifndef GDISP_LLD_BOARD_H #define GDISP_LLD_BOARD_H static inline void init_board(GDisplay *g) { (void) g; GPIO_InitTypeDef GPIO_InitStructure; // Open the clock RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOB | RCC_APB2Periph_GPIOC,ENABLE); // Configuration data IO connected to GPIOB GPIO_InitStructure.GPIO_Pin = GPIO_Pin_8 | GPIO_Pin_9 | GPIO_Pin_10 | GPIO_Pin_11 | GPIO_Pin_12 | GPIO_Pin_13 | GPIO_Pin_14 | GPIO_Pin_15; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP; // Push-pull output GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; // Output IO ports for maximum speed 50MHZ GPIO_Init(GPIOB, &GPIO_InitStructure); // Configuration Control IO connected to PD12.PD13.PD14.PD15/ GPIO_InitStructure.GPIO_Pin = GPIO_Pin_0 | GPIO_Pin_1 | GPIO_Pin_2 | GPIO_Pin_3 | GPIO_Pin_4 | GPIO_Pin_5 | GPIO_Pin_6 | GPIO_Pin_7 | GPIO_Pin_8 | GPIO_Pin_9 | GPIO_Pin_10 | GPIO_Pin_11; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOC, &GPIO_InitStructure); } static inline void post_init_board(GDisplay *g) { (void) g; } static inline void setpin_reset(GDisplay *g, bool_t state) { (void) g; (void) state; } static inline void set_backlight(GDisplay *g, uint8_t percent) { (void) g; (void) percent; } static inline void acquire_bus(GDisplay *g) { (void) g; } static inline void release_bus(GDisplay *g) { (void) g; } static inline void write_index(GDisplay *g, uint16_t index) { (void) g; LCD_CS = 0; LCD_RS = 0; GPIOC->ODR = (GPIOC->ODR & 0xff00) | (index & 0x00ff); GPIOB->ODR = (GPIOB->ODR & 0x00ff) | (index & 0xff00); LCD_WR = 0; LCD_WR = 1; LCD_CS = 1; } static inline void write_data(GDisplay *g, uint16_t data) { (void) g; LCD_CS = 0; LCD_RS = 1; GPIOC->ODR = (GPIOC->ODR & 0xff00) | (data & 0x00ff); GPIOB->ODR = (GPIOB->ODR & 0x00ff) | (data & 0xff00); LCD_WR = 0; LCD_WR = 1; LCD_CS = 1; } static inline void setreadmode(GDisplay *g) { (void) g; } static inline void setwritemode(GDisplay *g) { (void) g; } static inline uint16_t read_data(GDisplay *g) { (void) g; return 0; } #endif /* GDISP_LLD_BOARD_H */ ~ Tectu

You are definitely not supposed to put LCD_Init() into the post_board_init() function. Please do the few things that inmarket suggested. Can you show us the content of your LCD_Init() routine? ~ Tectu

We should start a wiki article about these traps in the 'Deverlopers Guide' section. ~ Tectu

So when I understand you correctly, when you manually issue the LCD_Init() routine after gfxInit(), you still use your board file to write the data, right? Do you still have the LCD_Init() routine within the init_board() routine? If not, can you check if the code in LCD_Init() does actually get executed when init_board() is being called? Does it get stuck somewhere? Sorry, I have no clue what the problem is yet - maybe inmarket will have an idea. ~ Tectu

Can you fire up your debugger and get a dump (examine) of the GDisplay struct within the init_board() routine? ~ Tectu

This is indeed a very nice project! I hope that we can add it as an official demo soon Edit: This demo has been added to the official uGFX library. It can be found under /demos/applications/tetris.