Joel Bodenmann

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

Hello solijoli and welcome to the community! First of all, please note that the tutorial that you are refering to uses a rather old version of uGFX. Many things changed (to the better) by now. We are close to release the new drivers interface that makes it A LOT easier to write new drivers. Therefore, I'd recommend you to check out the newmouse branch of the uGFX repository in order to implement a driver that will be compatible with all the new upcoming uGFX versions. But sadly we don't have any available documentation to that yet. However, the already ported drivers should be more than enough to see how you have to implement a driver. And if you ever hit any problem, the forum is always there for you! A general advice: When starting to implement uGFX into your project, it is strongly recommended to start off just with the GDISP module enabled. Using this minimal configuration it is a lot easier getting your project set up and compiling. You should even start by taking the empty board template for your GDISP driver (in your case it is /drivers/gdisp/SSD1963/board_SSD1963_template.h) and try to compile with that one first. Edit: As I just see, steved seems to help you out with this one As far as I know he already uses the new driver structure as well! Let us know when you have any questions. ~ Tectu

Glad to hear that it compiles Just use the systick API from the standard peripheral library to implement these two functions. ~ Tectu

That is "just" the compiler (and linker) and so on. Make is not part of that package. I agree - I've had the very same experience. Let's see if he can successfully build the unmodified ChibiOS/RT demo first. ~ Tectu

As he uses ChibiStudio, he's quite certainly using Windowsindeed. However, I think that ChibiStudio comes with its own tool. There should not be a make related issue unless he installed a custom toolchain. @electrotehnik: Can you please try to compile an unmodified ChibiOS/RT demo project? (like the /demos/ARMCM3-STM32F103) ~ Tectu

Hi, Can you please specify which version of ChibiOS/RT you are using? I don't think that this is an uGFX related problem. I just compiled a project with ChibiOS/RT 2.6.6 and an STM32F103 as well. It worked without any problems. Please make sure that you always use the ChibiOS/RT provided Makefile and just modify it as described in the wiki as they change sometimes. ~ Tectu

This is definitely not an uGFX related problem. Please open a new thread whenever you hit a new problem. This way we keep the forum clean and it is easier for people to find answers using the forum search. I can try to compile it as well and point you to the actual problem then. ~ Tectu

It is recommended to copy the /drivers/gdisp/ILI9325/board_ILI9325_template.h file to your project and keep it's routines empty so you can see if everything compiles successfully first. This will save you a lot of trouble. From there you just have to use the STM stdperiph library functions to control your microcontrollers peripheral. There is sadly no example/template available for this setup. ~ Tectu

Can you please post the full compiler log? I will try to test it tonight but I cannot promise you anything. ~ Tectu