Sting Posted July 4, 2016 Report Share Posted July 4, 2016 I am attempting to add ugfx to an existing project that cross compines a bunch of c++ code to an ARM target. I use the remote system explorer to move the project executable to the target. I thought I would start simple and use the notepad demo just to see if I could build it and I can't see that anything is actually being done. Is there a tutorial or hints for how to do this, or is it not recommended? So far I have changed Eclipse to not use default build command and instead inserted gfx.mk in its place. I also disabled the automatic generation of make files. I added the base directory of ugfx to the eclipse path. 11:47:35 **** Incremental Build of configuration Debug for project TestUgfx **** gfx.mk all 11:47:35 Build Finished (took 62ms) In my project I added the main,c and demo.mk files and modified demo.mk to have GFXLIB point to the head of ugfx and pointed the DEMODIR to my project head. GFXLIB = /usr/local/arm/ugfx_2.5 DEMODIR = /home/ray/Eclipse/brewery/TestUgfx GFXINC += $(DEMODIR) GFXSRC += $(DEMODIR)/main.c I added an environment variable to eclipse GFXLIB that points to the head of ugfx, the same value that is in the demo.mk file. Is there a way to see the progress that gfx.mk is making. I know that this is insufficient to actually build the application, I want to see if I understand and I clearly don't. What am I missing Link to comment Share on other sites More sharing options...
David George Posted July 6, 2016 Report Share Posted July 6, 2016 Hi I'm attempting something similar using Eclipse (not working yet), But I have cross-build a uGFX Demo from the command line, scp'd to the target and run successfully. Have you created your top level Makefile that basically builds the target ( you can't make from just a .mk file) Your top level Makefile will set GFXLIB etc.. You don't need a main.c file as this is supplied by the uGFX Demo directory. Link to comment Share on other sites More sharing options...
Joel Bodenmann Posted July 7, 2016 Report Share Posted July 7, 2016 Hello Sting and welcome to the community! On 7/4/2016 at 21:10, Sting said: Is there a tutorial or hints for how to do this, or is it not recommended? Assuming that your hardware (drivers, ...) are already supported it doesn't matter which demo you use. However, if you have to implement your own display driver or board files, we recommend using the most basic demo: /demos/modules/gdisp/basic. The recommended way of using µGFX in an Eclipse environment is to just include the µGFX makefile. Therefore, from what you tell you are doing the right thing Link to comment Share on other sites More sharing options...
Sting Posted July 7, 2016 Author Report Share Posted July 7, 2016 (edited) On 7/6/2016 at 04:38, David George said: Hi I'm attempting something similar using Eclipse (not working yet), But I have cross-build a uGFX Demo from the command line, scp'd to the target and run successfully. Have you created your top level Makefile that basically builds the target ( you can't make from just a .mk file) Your top level Makefile will set GFXLIB etc.. You don't need a main.c file as this is supplied by the uGFX Demo directory. To set GFXLIB I set environment variables in the properties of the project. So far I have built a normal project that generates it's own makefile. I add all of the includes that I think I need and then change the project to not automatically generate the makefile. A makefile is built and then when I change this switch a new makefile is not generated each time I run make. Then I edit the make file and add the two lines -include gfx.mk -include demo.mk I copied these files into the Debug directory of the project. I will have to change this procedure, I am just trying to figure out what it takes to build a simple project. I build the project and I think the build goes well except I have to find a way to include the ugfx source into the project. I think I need to create a virtual link to the source subdirectory and will try this next. If someone knows a better way, I would appreciate pointers. Edited July 7, 2016 by Sting Link to comment Share on other sites More sharing options...
Sting Posted July 7, 2016 Author Report Share Posted July 7, 2016 I made it to the next step, at least it is one step better: I added link directories as Base => /usr/local/arm/ugfx_2.5 gDisp => /usr/local/arm/ugfx_2.5/srs/gdisp Demo => /usr/local/arm/ugfx_2.5/demos/modules/gdisp/basics And it seems at this point all of the mk files are included into the Makefile and I don't have to turn off automatically generate makefile. I am down to two error: /usr/local/arm/ugfx_2.5/src/gdisp/fonts/DejaVuSans10.c:11:2: error: #error The font file is not compatible with this version of mcufont. and /usr/local/arm/ugfx_2.5/src/gdisp/fonts/DejaVuSans10.c:14:14: error: unknown type name ‘uint8_t’ Link to comment Share on other sites More sharing options...
Sting Posted July 8, 2016 Author Report Share Posted July 8, 2016 (edited) I am getting a little further, I can compile it all now but have trouble in the linker because I have probably included things too many times. I will go through it all again but some experience would be good to know what is included more then once I have many statements just like this. ./gDisp/gdisp_mk.o: In function `gdispGFillArea': /usr/local/arm/ugfx_2.5/src/gdisp/gdisp.c:1085: multiple definition of `gdispGFillArea' I also have undefined references ./gDisp/gdisp.o: In function `drawpixel': gdisp.c:(.text+0xa): undefined reference to `gdisp_lld_draw_pixel' ./gDisp/gdisp.o: In function `fillarea': gdisp.c:(.text+0xc6): undefined reference to `gdisp_lld_draw_pixel' ./gDisp/gdisp.o: In function `hline_clip': gdisp.c:(.text+0x1ee): undefined reference to `gdisp_lld_draw_pixel' ./gDisp/gdisp.o: In function `vline_clip': gdisp.c:(.text+0x2e6): undefined reference to `gdisp_lld_draw_pixel Any advise would be good, thanks Edited July 8, 2016 by Sting Link to comment Share on other sites More sharing options...
Sting Posted July 8, 2016 Author Report Share Posted July 8, 2016 I started a new project from scratch. I copied the main.c and the gfxConf.h file from the demo directory that I wanted to build. I added the following in the include path ugfx_2.5 ${workspace_loc:/${ProjName}} ugfx_2.5/drivers/gdisp/framebuffer ugfx_2.5/boards/base/Linux-Framebuffer ugfx_2.5/src/gdisp/mcufont Everything compiled with this set of settings I then added the ugfx_2.5 folder to the project as a link and built the project. I got the following errors Building file: /usr/local/arm/ugfx_2.5/drivers/multiple/uGFXnet/gdisp_lld_uGFXnet.c Invoking: Cross GCC Compiler arm-linux-gnueabihf-gcc -I/usr/local/arm/ugfx_2.5 -I"/home/ray/Eclipse/brewery/TwoUgfx" -I/usr/local/arm/ugfx_2.5/drivers/gdisp/framebuffer -I/usr/local/arm/ugfx_2.5/boards/base/Linux-Framebuffer -I/usr/local/arm/ugfx_2.5/src/gdisp/mcufont -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"ugfx_2.5/drivers/multiple/uGFXnet/gdisp_lld_uGFXnet.d" -MT"ugfx_2.5/drivers/multiple/uGFXnet/gdisp_lld_uGFXnet.o" -o "ugfx_2.5/drivers/multiple/uGFXnet/gdisp_lld_uGFXnet.o" "/usr/local/arm/ugfx_2.5/drivers/multiple/uGFXnet/gdisp_lld_uGFXnet.c" /usr/local/arm/ugfx_2.5/drivers/multiple/uGFXnet/gdisp_lld_uGFXnet.c:85:3: error: #error "GDISP: uGFXnet - The driver pixel format must match the protocol" #error "GDISP: uGFXnet - The driver pixel format must match the protocol" ^ /usr/local/arm/ugfx_2.5/drivers/multiple/uGFXnet/gdisp_lld_uGFXnet.c: In function ‘NetThread’: /usr/local/arm/ugfx_2.5/drivers/multiple/uGFXnet/gdisp_lld_uGFXnet.c:398:6: warning: implicit declaration of function ‘close’ [-Wimplicit-function-declaration] closesocket(clientfd); ^ It gets a lare way through building, it seems to be building stuff for drivers I don't use, which is where the error is. Link to comment Share on other sites More sharing options...
Sting Posted July 8, 2016 Author Report Share Posted July 8, 2016 I have tried to build only adding in the parts of the project that I need and it seems like not the right way to go so I went to including the entire project. I'm not sure which way to proceed. Link to comment Share on other sites More sharing options...
inmarket Posted July 8, 2016 Report Share Posted July 8, 2016 UGFX normally requires 3 things... 1. Gfxconf.h and a main program. These can come from your project or by including a makefile in one of the demo directories. 2. The main source itself built by including ugfx.mk. This automatically includes all the necessary sub makefiles. 3. Any drivers you need for your hardware. Again there are makefiles in each driver directory that you can include. Obviously you would only include one gdisp driver unless you intended to create a multiple display system. Alternatively you can use a makefile in the boards/base directory tree to include all the drivers and hardware io interfacing for a particular supported board (and any glue logic). All 3 parts above rely on GFXLIB being set to the ugfx directory. The above makefiles build a GFXSRC and a GFXINC make variable which your outer makefile then uses to set the compiler include path and then build the source. The 3 parts are just linked together. Our example makefiles (under the boards/base/xxx/example directories) just make this this combining task simple. They support building for a few embedded operating systems without the complexity of a complicated user makefile. Many people however (such as yourselves) want to include uGFX into their own makefile system. In such a case the process is the same, include the 3 parts above into your own makefile wrapper. Link to comment Share on other sites More sharing options...
Sting Posted July 8, 2016 Author Report Share Posted July 8, 2016 7 hours ago, inmarket said: UGFX normally requires 3 things... 1. Gfxconf.h and a main program. These can come from your project or by including a makefile in one of the demo directories. I copied the main.c and gfxconf.h from the the demos directory: $GFXLIB/demos/modules/gdisp/basics 2. The main source itself built by including ugfx.mk. This automatically includes all the necessary sub makefiles. Eclipse generates makefiles for the source in my existing project. I have an option to write my own makefile but I think that eliminates the benefit of using eclipse. To get eclipse to add $GFXLIB/ugfx.mk into the project I created a link in the project to add the $GFXLIB source. If I don't add the directory into my project the include section of the makefile looks like: # All of the sources participating in the build are defined here -include sources.mk -include subdir.mk -include objects.mk When I run make in this situation all of the files compile but object files are missing. I get undefined reference to everything because the only file it compiles is main. Something like: Building target: TwoUgfx Invoking: Cross GCC Linker arm-linux-gnueabihf-gcc -o "TwoUgfx" ./main.o ./main.o: In function `drawScreen': /home/ray/Eclipse/brewery/TwoUgfx/Debug/../main.c:49: undefined reference to `gdispOpenFont' Plus many more If I tell eclipse to not generate a new makefile and add $(GFXLIB)/gfx.mk nothing changes, the only file that gets compiled is main.c If I link the ugfx_2.5 directory into my project everything gets compiled. The include section of the makefile looks like: # All of the sources participating in the build are defined here -include sources.mk -include ugfx_2.5/tools/file2c/src/subdir.mk -include ugfx_2.5/src/gwin/subdir.mk -include ugfx_2.5/src/gtrans/subdir.mk -include ugfx_2.5/src/gtimer/subdir.mk -include ugfx_2.5/src/gqueue/subdir.mk -include ugfx_2.5/src/gos/subdir.mk -include ugfx_2.5/src/gmisc/subdir.mk -include ugfx_2.5/src/ginput/subdir.mk -include ugfx_2.5/src/gfile/subdir.mk -include ugfx_2.5/src/gevent/subdir.mk -include ugfx_2.5/src/gdriver/subdir.mk -include ugfx_2.5/src/gdisp/mcufont/subdir.mk -include ugfx_2.5/src/gdisp/fonts/subdir.mk -include ugfx_2.5/src/gdisp/subdir.mk -include ugfx_2.5/src/gaudio/subdir.mk -include ugfx_2.5/src/gadc/subdir.mk -include ugfx_2.5/src/subdir.mk -include ugfx_2.5/drivers/multiple/uGFXnet/subdir.mk -include ugfx_2.5/drivers/multiple/X/subdir.mk -include ugfx_2.5/drivers/multiple/Win32/subdir.mk -include ugfx_2.5/drivers/ginput/touch/STMPE811/subdir.mk -include ugfx_2.5/drivers/ginput/touch/STMPE610/subdir.mk -include ugfx_2.5/drivers/ginput/touch/MCU/subdir.mk -include ugfx_2.5/drivers/ginput/touch/MAX11802/subdir.mk -include ugfx_2.5/drivers/ginput/touch/FT5x06/subdir.mk -include ugfx_2.5/drivers/ginput/touch/FT5336/subdir.mk -include ugfx_2.5/drivers/ginput/touch/ADS7843/subdir.mk -include ugfx_2.5/drivers/ginput/toggle/Pal/subdir.mk -include ugfx_2.5/drivers/ginput/dial/GADC/subdir.mk -include ugfx_2.5/drivers/gdisp/framebuffer/subdir.mk -include ugfx_2.5/drivers/gdisp/TestStub/subdir.mk -include ugfx_2.5/drivers/gdisp/TLS8204/subdir.mk -include ugfx_2.5/drivers/gdisp/STM32LTDC/subdir.mk -include ugfx_2.5/drivers/gdisp/ST7565/subdir.mk -include ugfx_2.5/drivers/gdisp/SSD2119/subdir.mk -include ugfx_2.5/drivers/gdisp/SSD1963/subdir.mk -include ugfx_2.5/drivers/gdisp/SSD1351/subdir.mk -include ugfx_2.5/drivers/gdisp/SSD1331/subdir.mk -include ugfx_2.5/drivers/gdisp/SSD1306/subdir.mk -include ugfx_2.5/drivers/gdisp/SSD1289/subdir.mk -include ugfx_2.5/drivers/gdisp/SPFD54124B/subdir.mk -include ugfx_2.5/drivers/gdisp/S6D1121/subdir.mk -include ugfx_2.5/drivers/gdisp/RA8875/subdir.mk -include ugfx_2.5/drivers/gdisp/R61505U/subdir.mk -include ugfx_2.5/drivers/gdisp/PCF8812/subdir.mk -include ugfx_2.5/drivers/gdisp/PCD8544/subdir.mk -include ugfx_2.5/drivers/gdisp/Nokia6610GE8/subdir.mk -include ugfx_2.5/drivers/gdisp/Nokia6610GE12/subdir.mk -include ugfx_2.5/drivers/gdisp/LGDP4532/subdir.mk -include ugfx_2.5/drivers/gdisp/ILI9481/subdir.mk -include ugfx_2.5/drivers/gdisp/ILI93xx/subdir.mk -include ugfx_2.5/drivers/gdisp/ILI9342/subdir.mk -include ugfx_2.5/drivers/gdisp/ILI9341/subdir.mk -include ugfx_2.5/drivers/gdisp/ILI9325/subdir.mk -include ugfx_2.5/drivers/gdisp/ILI9320/subdir.mk -include ugfx_2.5/drivers/gdisp/HX8347D/subdir.mk -include ugfx_2.5/drivers/gdisp/ED060SC4/subdir.mk -include ugfx_2.5/drivers/gaudio/vs1053/subdir.mk -include ugfx_2.5/drivers/gaudio/pwm/subdir.mk -include ugfx_2.5/drivers/gaudio/gadc/subdir.mk -include ugfx_2.5/drivers/gaudio/Win32/subdir.mk -include ugfx_2.5/drivers/gadc/AT91SAM7/subdir.mk -include ugfx_2.5/demos/tools/uGFXnetDisplay/subdir.mk -include ugfx_2.5/demos/tools/touch_raw_readings/subdir.mk -include ugfx_2.5/demos/tools/touch_driver_test/subdir.mk -include ugfx_2.5/demos/tools/touch_calibration_grabber/subdir.mk -include ugfx_2.5/demos/modules/gwin/widgets/subdir.mk -include ugfx_2.5/demos/modules/gwin/textedit_virtual_keyboard/subdir.mk -include ugfx_2.5/demos/modules/gwin/textedit/subdir.mk -include ugfx_2.5/demos/modules/gwin/tabset/subdir.mk -include ugfx_2.5/demos/modules/gwin/slider/subdir.mk -include ugfx_2.5/demos/modules/gwin/radio/subdir.mk -include ugfx_2.5/demos/modules/gwin/progressbar/subdir.mk -include ugfx_2.5/demos/modules/gwin/list/subdir.mk -include ugfx_2.5/demos/modules/gwin/label/subdir.mk -include ugfx_2.5/demos/modules/gwin/keyboard/subdir.mk -include ugfx_2.5/demos/modules/gwin/imagebox/subdir.mk -include ugfx_2.5/demos/modules/gwin/graph/subdir.mk -include ugfx_2.5/demos/modules/gwin/gl3d-spin/subdir.mk -include ugfx_2.5/demos/modules/gwin/gl3d-gears/subdir.mk -include ugfx_2.5/demos/modules/gwin/frame/subdir.mk -include ugfx_2.5/demos/modules/gwin/container_nested/subdir.mk -include ugfx_2.5/demos/modules/gwin/container/subdir.mk -include ugfx_2.5/demos/modules/gwin/console/subdir.mk -include ugfx_2.5/demos/modules/gwin/checkbox/subdir.mk -include ugfx_2.5/demos/modules/gwin/button/subdir.mk -include ugfx_2.5/demos/modules/gwin/basic/subdir.mk -include ugfx_2.5/demos/modules/gtrans/basic/subdir.mk -include ugfx_2.5/demos/modules/gtimer/subdir.mk -include ugfx_2.5/demos/modules/gos/threads_advanced/subdir.mk -include ugfx_2.5/demos/modules/gos/threads/subdir.mk -include ugfx_2.5/demos/modules/ginput/keyboard/subdir.mk -include ugfx_2.5/demos/modules/gdisp/streaming/subdir.mk -include ugfx_2.5/demos/modules/gdisp/polygons/subdir.mk -include ugfx_2.5/demos/modules/gdisp/pixmap/subdir.mk -include ugfx_2.5/demos/modules/gdisp/multiple_displays/subdir.mk -include ugfx_2.5/demos/modules/gdisp/images_animated/subdir.mk -include ugfx_2.5/demos/modules/gdisp/images/subdir.mk -include ugfx_2.5/demos/modules/gdisp/fonts_cyrillic/subdir.mk -include ugfx_2.5/demos/modules/gdisp/fonts/subdir.mk -include ugfx_2.5/demos/modules/gdisp/circles/subdir.mk -include ugfx_2.5/demos/modules/gdisp/basics/subdir.mk -include ugfx_2.5/demos/modules/gdisp/arcsectors/subdir.mk -include ugfx_2.5/demos/modules/gaudio/play-wave/subdir.mk -include ugfx_2.5/demos/modules/gaudio/play-vs1053/subdir.mk -include ugfx_2.5/demos/modules/gaudio/oscilloscope/subdir.mk -include ugfx_2.5/demos/modules/gadc/subdir.mk -include ugfx_2.5/demos/benchmarks/subdir.mk -include ugfx_2.5/demos/applications/tetris/subdir.mk -include ugfx_2.5/demos/applications/notepad/subdir.mk -include ugfx_2.5/demos/applications/mandelbrot/subdir.mk -include ugfx_2.5/demos/applications/combo/subdir.mk -include ugfx_2.5/demos/3rdparty/notepad-2/subdir.mk -include ugfx_2.5/demos/3rdparty/bubbles/subdir.mk -include ugfx_2.5/boards/base/STM32F746-Discovery/subdir.mk -include ugfx_2.5/boards/base/STM32F429i-Discovery/subdir.mk -include ugfx_2.5/boards/base/RaspberryPi/FreeRTOS/subdir.mk -include ugfx_2.5/boards/base/RaspberryPi/subdir.mk -include ugfx_2.5/boards/base/Olimex-STM32-LCD/chibios_board/subdir.mk -include ugfx_2.5/boards/base/Mikromedia-STM32-M4-ILI9341/ChibiOS_Board/subdir.mk -include ugfx_2.5/boards/base/Mikromedia-Plus-STM32-M4/ChibiOS_Board/subdir.mk -include ugfx_2.5/boards/base/Marlin/chibios_board/subdir.mk -include ugfx_2.5/boards/base/HY-MiniSTM32V/chibios_board/subdir.mk -include ugfx_2.5/boards/base/FireBull-STM32F103-FB/chibios_board/subdir.mk -include ugfx_2.5/boards/base/Embest-STM32-DMSTF4BB/example_chibios_3.x/subdir.mk -include ugfx_2.5/boards/base/Embest-STM32-DMSTF4BB/example_chibios_2.x/subdir.mk -include ugfx_2.5/boards/base/ArduinoTinyScreen/gfx/subdir.mk -include ugfx_2.5/3rdparty/tinygl-0.4-ugfx/src/subdir.mk -include ugfx_2.5/3rdparty/tinygl-0.4-ugfx/examples/subdir.mk -include ugfx_2.5/3rdparty/petitfs-0.03/src/subdir.mk -include ugfx_2.5/3rdparty/fatfs-0.10b/src/option/subdir.mk -include ugfx_2.5/3rdparty/fatfs-0.10b/src/subdir.mk -include ugfx_2.5/3rdparty/fatfs-0.10b/doc/img/subdir.mk -include subdir.mk -include objects.mk and everything gets compiled until an error occurs. Building file: /usr/local/arm/ugfx_2.5/drivers/multiple/uGFXnet/gdisp_lld_uGFXnet.c Invoking: Cross GCC Compiler arm-linux-gnueabihf-gcc -I/usr/local/arm/ugfx_2.5 -I"/home/ray/Eclipse/brewery/TwoUgfx" -I/usr/local/arm/ugfx_2.5/drivers/gdisp/framebuffer -I/usr/local/arm/ugfx_2.5/boards/base/Linux-Framebuffer -I/usr/local/arm/ugfx_2.5/src/gdisp/mcufont -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"ugfx_2.5/drivers/multiple/uGFXnet/gdisp_lld_uGFXnet.d" -MT"ugfx_2.5/drivers/multiple/uGFXnet/gdisp_lld_uGFXnet.o" -o "ugfx_2.5/drivers/multiple/uGFXnet/gdisp_lld_uGFXnet.o" "/usr/local/arm/ugfx_2.5/drivers/multiple/uGFXnet/gdisp_lld_uGFXnet.c" /usr/local/arm/ugfx_2.5/drivers/multiple/uGFXnet/gdisp_lld_uGFXnet.c:85:3: error: #error "GDISP: uGFXnet - The driver pixel format must match the protocol" #error "GDISP: uGFXnet - The driver pixel format must match the protocol" ^ Because it is building a driver I don't need. 3. Any drivers you need for your hardware. Again there are makefiles in each driver directory that you can include. Obviously you would only include one gdisp driver unless you intended to create a multiple display system. Alternatively you can use a makefile in the boards/base directory tree to include all the drivers and hardware io interfacing for a particular supported board (and any glue logic). I don't see a way for the application to decide what files to compile so everything is compiled using this technique. I tried an alternative approach, only including the directories into the project that are needed for my project. This went well to a point. I ran into problems when I added the ginput directory into the project and attempted to build it. But again, because there doesn't seem to be a way pick what gets compiled. At least I haven't figured it out yet. All 3 parts above rely on GFXLIB being set to the ugfx directory. The above makefiles build a GFXSRC and a GFXINC make variable which your outer makefile then uses to set the compiler include path and then build the source. The 3 parts are just linked together. I set GFXLIB as an environment variable in the project. The problem seems to be that the eclipse makefile doesn't know to use the GFXSRC and GFXINC variables to build. Our example makefiles (under the boards/base/xxx/example directories) just make this this combining task simple. They support building for a few embedded operating systems without the complexity of a complicated user makefile. Many people however (such as yourselves) want to include uGFX into their own makefile system. In such a case the process is the same, include the 3 parts above into your own makefile wrapper. If I don't include any of the source in the eclipse project. I clean everything out and replace the makefile with the one in the demo directory, and change the setting for the GFXLIB and run make it doesn't actually compile anything, just reports the compiler options. Link to comment Share on other sites More sharing options...
David George Posted July 8, 2016 Report Share Posted July 8, 2016 Hi quick reply, the problems I found where missing include paths in the gfx makefile (linker includes) (I'm using Autotools in Eclipse), it will build, here my Eclipse console output... 17:35:25 **** Build of configuration Build (GNU) for project gfx_autotools_eclipse **** make all make all-recursive make[1]: Entering directory `/home/david/workspace/gfx_autotools_eclipse' Making all in src make[2]: Entering directory `/home/david/workspace/gfx_autotools_eclipse/src' . C Compiler Options.... arm-poky-linux-gnueabi-gcc -march=armv7-a -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 --sysroot=/opt/poky/2.1/sysroots/cortexa9hf-neon-poky-linux-gnueabi -c --sysroot=/opt/poky/2.1/sysroots/cortexa9hf-neon-poky-linux-gnueabi -g -O0 --sysroot=/opt/poky/2.1/sysroots/cortexa9hf-neon-poky-linux-gnueabi -ggdb -O0 -fomit-frame-pointer -Wall -Wextra -Wstrict-prototypes -fverbose-asm -MMD -MP -MF .build/dep/fakefile.o.d -I. -Igfx/ugfx -Igfx/ugfx/src -Igfx/ugfx/boards/base/Linux-Framebuffer -Igfx/ugfx/drivers/gdisp/framebuffer -Igfx/ugfx/demos/modules/gdisp/streaming -DGFX_USE_OS_LINUX=TRUE -DGFX_USE_OS_LINUX=TRUE fakefile.c -o .build/obj/fakefile.o . Linker Options........ arm-poky-linux-gnueabi-gcc -march=armv7-a -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 --sysroot=/opt/poky/2.1/sysroots/cortexa9hf-neon-poky-linux-gnueabi --sysroot=/opt/poky/2.1/sysroots/cortexa9hf-neon-poky-linux-gnueabi -pthread -lrt .build/obj/fakefile.o -o .build/gfx_dmg . Compiling gfx/ugfx/src/gfx.c Compiling gfx/ugfx/src/gos/gos_linux.c Compiling gfx/ugfx/src/gdriver/gdriver.c Compiling gfx/ugfx/src/gqueue/gqueue.c Compiling gfx/ugfx/src/gdisp/gdisp.c ... Compiling gfx/ugfx/src/gtrans/gtrans.c Compiling gfx/ugfx/drivers/gdisp/framebuffer/gdisp_lld_framebuffer.c Compiling gfx/ugfx/demos/modules/gdisp/streaming/main.c Linking .build/gfx_dmg make[2]: Leaving directory `/home/david/workspace/gfx_autotools_eclipse/src' make[2]: Entering directory `/home/david/workspace/gfx_autotools_eclipse' make[2]: Leaving directory `/home/david/workspace/gfx_autotools_eclipse' make[1]: Leaving directory `/home/david/workspace/gfx_autotools_eclipse' 17:35:28 Build Finished (took 2s.570ms) Link to comment Share on other sites More sharing options...
Sting Posted July 8, 2016 Author Report Share Posted July 8, 2016 Did you have to write your own makefile or is it generated automatically by eclipse? Link to comment Share on other sites More sharing options...
inmarket Posted July 8, 2016 Report Share Posted July 8, 2016 Rather than linking the entire uGFX source tree which then causes eclipse source detection to include too much, try linking the "src" directory to get step 2, the "demos/gdisp/basics" directory to get the demo step 1 code, and then link to each individual driver that you want included in the build. Link to comment Share on other sites More sharing options...
Sting Posted July 9, 2016 Author Report Share Posted July 9, 2016 1 hour ago, inmarket said: Rather than linking the entire uGFX source tree which then causes eclipse source detection to include too much, try linking the "src" directory to get step 2, the "demos/gdisp/basics" directory to get the demo step 1 code, and then link to each individual driver that you want included in the build. do you mean that i build my own makefile and not have eclipse do it based on the source files in the project? Link to comment Share on other sites More sharing options...
inmarket Posted July 9, 2016 Report Share Posted July 9, 2016 Linking above refers to filesystem linking to fool the eclipse makefile generator. We internally always use a custom makefile in eclipse. For an example look at boards/base/xxx/example Ugfx is far more than just a collection of sources. I will be surprised but pleased if eclipse makefile generation can be fooled to make ugfx correctly. Link to comment Share on other sites More sharing options...
Sting Posted July 9, 2016 Author Report Share Posted July 9, 2016 I hope what I write here does not insult anyone, it is not my intent. I have total respect for the piece of work and all of those who built it. I think this is an awesome piece of software and am working very hard to figure out a way to make it work in the environment that I need. It will be in my favor to figure out how to make it work. My environment forces me to use eclipse. I am working on a project that uses the Xylinx Zynq processor on a board and the SDK for this board is a modified version of eclipse. I also cannot make my own makefile as the zynq sdk builds a makefile based on how I define the hardware for the application I am writing. The Zynq is a dual core arm processor with fpga fabric to allow me to build whatever piece of hardware I need. Add to this requirement the need for a real time os, the application will be an embedded application running the rtos as opposed to a linux kernel. It will be virtually impossible for me to keep all of the makefile differences between these three components in line and will be chasing makefile bugs as well as software bugs trying to integrate these environments with the added complexity of my application. I understand the ugfx is more then a collection of sources, it supports many different pieces of hardware so inherently exhibits a high level of complexity. I am not sure if I can sort it all out, but I hope to as I think this technology will enhance my product. To get to where I can use this in my production environment I am trying to build a prototype without all of the other complexity to find a pattern that I can make work without forcing me to manually pick the files I need to build my system. To build a successful system the application picks a board and a set of drivers for each of the subsystems they want to use. Is this assumption correct? If this assumption is correct then once the application has picked the hardware attributes of the system they intend to build then that set of choices would be implemented with the building of the src directory given hardware choices. This is defined by a set of defines and anything in the src tree that won't be able to work on that set of choices should not get compiled. This will eliminate the makefile chain and be much easier for eclipse to work. I have seen systems that support many different physical environments use a technique like this. In the application config file the use defines all of the switches to define the system they want and the defines prevent the system from attempting to build stuff that is not needed. Ugfx already has the defines like GFX_USE_GDRIVER and instead of using these switches to build a makefile they were used in the source to decide how it is built eclipse would work. Is there a know reason this will not work? I understand this is not a simple job, without some method like this my product will not be able to use this technology. Link to comment Share on other sites More sharing options...
Joel Bodenmann Posted July 9, 2016 Report Share Posted July 9, 2016 We ourselves (and a couple of our customers) are using µGFX on the NIOS-II platform. That is a SoC platform (hard- and soft-cores) for Altera FPGAs. They too use a modified Eclipse as an IDE. We have never encountered any issues using µGFX in those projects, it just worked out of the box. It too generates the makefiles automatically because, as you said, those change depending on the systems configuration. All we had to do was including the main µGFX makefile and the driver make files in that generated "main" makefile. We followed 1:1 our own guide on how to integrate µGFX using the makefiles and it works very well out of the box. It seems that the build system recognizes the changes in the makefile that were made manually and keeps them in there. As that will most likely be part of eclipse I assume that this should work for you just as well. So after all it boiled down to adding five lines to the generated makefile and µGFX was complied successfully with the rest of the system. So what keeps you from adding µGFX to your project the way it's explained here? Edit: All we had to do was adding these three lines to the top of the generated makefile: GFXLIB = \path\to\your\ugfx include $(GFXLIB)/gfx.mk include $(GFXLIB)/boards/base/Altera-MAX10-NEEK/board.mk C_SRCS += $(GFXSRC) APP_INCLUDE_DIRS += $(GFXINC) Of course the variables are not the same as you are working on a completely different platform. It's just to show you what we had to do to get it working, and that's really all. Link to comment Share on other sites More sharing options...
Sting Posted July 10, 2016 Author Report Share Posted July 10, 2016 I built a new project and put the main.c and the gfxConf.h file from the demos/modules/basic directory. I added all of the include directories so all that remained was the linker finding the object files that were not compiled yet. I then added the lines you suggested to the makefile and changed them to be for my system and to use the Linux_FrameBuffer driver. I was warned that i was modifying an autogenerated file. When I did the next make, the lines I added were removed. I then disabled the autogenerated makefile and added the lines to see if this would be suffucient. The only file that gets compiled is main.c. The only way to get the version of eclipse I am using to compile any file other then main.c is to add the directory to the project via a link. The version of eclipse I am using is: Mars.2 Release (4.5.2) Link to comment Share on other sites More sharing options...
Sting Posted July 10, 2016 Author Report Share Posted July 10, 2016 I got a version to work, but I don't think it is the best way and I am not sure it will work in all cases. 1) I started with the demos/modules/gdisp/basics, I copied the main.c and the gfxconf.h files to the project. 2) The project uses the Linux-FrameBuffer board and the X driver so I added links to those directories to my project. I also added a link to the src directory to my project. When I tried to build I would always get duplicate for every function so I created a define #define GFX_USE_ECLIPSE TRUE and surrounded the file gfx_mk.c with the following #include "gfxconf.h" // this will get the GFX_USE_ECLIPSE flag #ifndef GFX_USE_ECLIPSE Original source goes here #endif So the file will be compiled when not using eclipse and will not be compiled when using eclipse. I added the X and pthread libraries cross compiled for the beaglebone and ran it and I got exactly what I would expect. I don't have to muck with any makefiles Link to comment Share on other sites More sharing options...
Sting Posted July 10, 2016 Author Report Share Posted July 10, 2016 I forgot another change I had to make and that is I had to not use the following files in GFXLIB directory: mf_bwfont.h, mf_rlefont.h, and mf_scaledfont.h as they prohibited the header files by the same name from being used. I might be able to ssolve this easily by changing the include directory order. Link to comment Share on other sites More sharing options...
inmarket Posted July 11, 2016 Report Share Posted July 11, 2016 Glad to hear you got it working Link to comment Share on other sites More sharing options...
Sting Posted July 11, 2016 Author Report Share Posted July 11, 2016 I was just going to reply, it wasn't so fast. I tried a demo that uses fonts and had a bit of an issue. Because fonts use fancy macro manipulation the font's didn't work immediately. I had to disable the font directory from compiling as a directory because all of the fonts get built but none of them get added to the list. Currently I have to stop automatic makefile generation to get the fonts to work. If I am the only one who cares about this, I will move the macro stuff to each file, the ones I want to use at least. 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