Joel Bodenmann

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.

@solijoli: I have no idea where you got that link from. That article is probably a hundred years old and I didn't even know that it exists. All the official documentation can be found here ---> http://wiki.ugfx.org In general, you should never trust links in a public forum that are older than half a year. Everything else is pretty well covered by steveds post. If you have a project that compiles with ChibiOS/RT and uGFX, I strongly recommend you to disable everything but the GDISP module in the configuration file and just compile with the blank (empty) board file template that you can find in the drivers directory (in your case /drivers/gdisp/SSD1963/board_SSD1963_template.h). This way you can be absolutely be sure that no project specific issues keep you from getting a successful compile. ~ Tectu

Hello and welcome to the community! There is no such thing as an 'ECOS package'. The ECOS support is built-in into the library. All you have to do is setting GFX_USE_OS_ECOS to TRUE in your configuration file. About the master-slave: I'm not sure if I understand you correctly. When you want to have your GUI running on the master and the slave is just a passive terminal (the actual screen with touchscreen), this can be done easily. uGFX supports remote displays through the uGFXnet driver. ~ Tectu

Where does the Delay() function come from? Can you show us it's implementation? I haven't worked with the stdperiph library for a long time. ~ Tectu

So this issue is actually resolved now?

This means that solijoli should use the master branch in that case. @steved: I will let you know once I ported the driver. But days are currently very busy. Don't expect anything within the next 8 days please. ~ Tectu

Oh... I remember that there was something... Did you port the driver to the new driver structure from the newmouse branch? We'd be more than happy to add your driver to the repository ASAP then Otherwise I'll port it myself if you (re)provide us with your driver that works with the current master branch. However, I'll need you to test and probably debug it. ~ Tectu