Dmytro Posted May 4, 2014 Report Share Posted May 4, 2014 Hi all,I want to compile uGFX with SSD1289 display drivers. I have board Land-Tiger with LPC1768 controller. For supporting this board I added folder to board/base/ directori (was copyed from existing). Then I added in my general Makefile: gfx.mk ($(GFXLIB)/gfx.mk) and board.mk ($(GFXLIB)/boards/base/Land-Tiger-LPC1768-LCD/board.mk). Without board.mk all compile fine and linked in *.hex file. But with board.mk I had the next output from linker:/mnt/Project_X/obj//mnt/Project_X/ugfx/src/gdisp/gdisp.o: In function `fillarea':gdisp.c:(.text.fillarea+0x16): undefined reference to `gdisp_lld_write_stop'gdisp.c:(.text.fillarea+0x3c): undefined reference to `gdisp_lld_write_start'gdisp.c:(.text.fillarea+0x42): undefined reference to `gdisp_lld_write_pos'gdisp.c:(.text.fillarea+0x4a): undefined reference to `gdisp_lld_write_color'gdisp.c:(.text.fillarea+0x5e): undefined reference to `gdisp_lld_write_stop'/mnt/Project_X/obj//mnt/Project_X/ugfx/src/gdisp/gdisp.o: In function `_gdispInit':gdisp.c:(.text._gdispInit+0x32): undefined reference to `gdisp_lld_init'/mnt/Project_X/obj//mnt/Project_X/ugfx/src/gdisp/gdisp.o: In function `gdispGClear':gdisp.c:(.text.gdispGClear+0x46): undefined reference to `gdisp_lld_write_start'gdisp.c:(.text.gdispGClear+0x4c): undefined reference to `gdisp_lld_write_pos'gdisp.c:(.text.gdispGClear+0x54): undefined reference to `gdisp_lld_write_color'gdisp.c:(.text.gdispGClear+0x68): undefined reference to `gdisp_lld_write_stop'collect2: error: ld returned 1 exit statusLooks like that file ugfx/drivers/gdisp/SSD1289/gdisp_lld_SSD1289.c does not compile. I expressly did mistake in code - and did not receive any errors. Link to comment Share on other sites More sharing options...
Joel Bodenmann Posted May 4, 2014 Report Share Posted May 4, 2014 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-LCDGFXSRC +=GFXDEFS += -DGFX_USE_CHIBIOS=TRUEinclude $(GFXLIB)/boards/base/Land-Tiger-LPC1768-LCD/chibios_board/board.mk # This is optional, remove if unneeded.include $(GFXLIB)/drivers/gdisp/SSD1289/gdisp_lld.mkinclude $(GFXLIB)/drivers/ginput/touch/ADS7843/ginput_lld.mkYou can zip and attach the whole board directory and I'll have a look at it.~ Tectu Link to comment Share on other sites More sharing options...
Dmytro Posted May 4, 2014 Author Report Share Posted May 4, 2014 Hi, I was a little surprised, becouse it is my first post on this forum. But it is very nice for such a warm welcome.So, as for the problem. Now I am trying use only display, without touchscreen. Also I use FreeRTOS instead Chibi and CMSIS for low level hardware manipulations. This is my board.mk:GFXINC += $(GFXLIB)/boards/base/Land-Tiger-LPC1768-LCDGFXSRC +=include $(GFXLIB)/drivers/gdisp/SSD1289/gdisp_lld.mk#include $(GFXLIB)/drivers/ginput/touch/ADS7843/ginput_lld.mkAlso I attached .zip file with board directory, as you want. I hope this is help for you to help me .base.zip Link to comment Share on other sites More sharing options...
Joel Bodenmann Posted May 4, 2014 Report Share Posted May 4, 2014 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 Link to comment Share on other sites More sharing options...
Dmytro Posted May 4, 2014 Author Report Share Posted May 4, 2014 Okay, I also will go to the cinema.I cloned freertos branch.I did not test this yet, but I ready help to you with testing. Link to comment Share on other sites More sharing options...
Joel Bodenmann Posted May 4, 2014 Report Share Posted May 4, 2014 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 Link to comment Share on other sites More sharing options...
Dmytro Posted May 4, 2014 Author Report Share Posted May 4, 2014 Yes, sure.I attached output from my build and my "root" makefile.make+output.zip Link to comment Share on other sites More sharing options...
Joel Bodenmann Posted May 5, 2014 Report Share Posted May 5, 2014 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 Link to comment Share on other sites More sharing options...
Dmytro Posted May 6, 2014 Author Report Share Posted May 6, 2014 Hello Tectu,I have good news - I have compiled this!The problem was in my root makefile. I don't know why, but when I had been collecting source files from directories - file from SSD1289 directory was not included to my $(SOURCES) variable.So, I changed from this:SOURCES = $(wildcard $(CMSIS_BOOT_DIR)/*.c)SOURCES+= $(wildcard $(CMSIS_CORE_DIR)/*.c)SOURCES+= $(wildcard $(CMSIS_LIB_SRC)/*.c)SOURCES+= $(wildcard $(CORE_SRC)/*.c)[color=#FFFF00]SOURCES+= $(wildcard $(GFXSRC)/*.c)[/color]SOURCES+= $(wildcard $(CURRENT_DIR)/*.c)to this:SOURCES = $(wildcard $(CMSIS_BOOT_DIR)/*.c)SOURCES+= $(wildcard $(CMSIS_CORE_DIR)/*.c)SOURCES+= $(wildcard $(CMSIS_LIB_SRC)/*.c)SOURCES+= $(wildcard $(CORE_SRC)/*.c)[color=#FFFF00]SOURCES+= $(GFXSRC)[/color]SOURCES+= $(wildcard $(CURRENT_DIR)/*.c)Also I had issue with TRUE/FALSE defines - as I am using CMSIS library - these constants defined there. So I temporary had included header file with type definitions from CMSIS to the gfx.h file.I did not try if it works on my board, only compiled. But it good start, I think Link to comment Share on other sites More sharing options...
Joel Bodenmann Posted May 6, 2014 Report Share Posted May 6, 2014 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 Link to comment Share on other sites More sharing options...
Dmytro Posted May 6, 2014 Author Report Share Posted May 6, 2014 In freeRTOS these definitions are named as pdTRUE and pdFALSE (projdefs.h, version 8.0.0). uGFX theoretically can have problem with CMSIS (library for lowlevel hardware manipulations for NXP MCU's). There are declared enumeration (in file lpc_types.h):typedef enum {FALSE = 0, TRUE = !FALSE} Bool;So, if this code will compile after uGFX - it can lead to errors, I think. Link to comment Share on other sites More sharing options...
Joel Bodenmann Posted May 6, 2014 Report Share Posted May 6, 2014 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 Link to comment Share on other sites More sharing options...
Dmytro Posted May 8, 2014 Author Report Share Posted May 8, 2014 You can choose way like freeRTOS - to use unique name for these definitions. For example gTRUE and gFALSE. Maybe it's not very nice solution, but it can help solve this problem. Link to comment Share on other sites More sharing options...
Joel Bodenmann Posted May 8, 2014 Report Share Posted May 8, 2014 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 Link to comment Share on other sites More sharing options...
Dmytro Posted May 8, 2014 Author Report Share Posted May 8, 2014 Hi Tectu,I am not sure if this can resolve the problem. But you can try to compile ugfx but with CMSIS. I will be in the other place and can not help with checking your proposition till Monday. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now