Sting
-
Posts
77 -
Joined
-
Last visited
Content Type
Forums
Store
Downloads
Blogs
Posts posted by Sting
-
-
Easy question: I have the table mostly working but have a question. The standard seems to be to not draw horizontal lines for the rows of the List object. Does this mean it is best to not draw the vertical lines for the columns?
If no lines then it seems reasonable to implement
gwinTableSetOddBackground(...); and gwinTableSetEvenBackground(...); I have already implemented gwinTableItemSetBackground(=...);This allows for changing the background of the rows to make it easier to follow what is happening and doesn't incur the cost of more drawing, since the row has to be drawn anyway.
Also, the entire list is redrawn when a new row is selected, is there a reason I shouldn't optimize this, so only the two rows that changed need to be refreshed? Or doesn't this make a performance difference?
-
Here is the first pass header for the Table widget. There could be some comments not changed. I used an @warning at the top of functions I had questions about.
-
I actually had the idea this morning to build two version:
gwinTable: a row oriented widget that uses less resources, basically each element of the single queue is a row element and contains everything for a complete row. In this widget cells are not selectable. In this widget each row can have an image but not each cell.
gwinGrid: a cell oriented widget that uses a queue for each column and allows cell wise operations, each cell can have an image. row selection is not an option.
If there is no objection, this is what I will plan. I can have the header files done by the end of the day.
-
Do you mean a queue for each column and add items have to be for a complete row?
-
47 minutes ago, Joel Bodenmann said:
Earlier you mentioned that the number of rows and columns is known/fixed. Why would you mess with using queues then? To me it sounds like you should be using a static array instead. That saves a lot of overhead.
Only the number of columns are known for the current implementation. For my project I also know the number of rows, because they are database rows from a select. If that restriction can be lifted I could use an array.
-
I have a roughed out gwinTable interface definition. I basically took the gwinList and copied it to gwinTable, left in all of the copyrights, and changed the names. I changed how the list_head was allocated to use an array of pointers to gfxQueueASync structures. This will design make it easier to support table cell selection. I thought of leaving it as a single gfxQueueASync structure and have each element represent a complete row. This design will make row selection more convenient. The api is not totally flushed out yet, I figured I would get some feedback before I went too far.
Anyway, I want to build this for more then just me, is there a design review process for widgets? If the api is not correct, others won't use it and I will have wasted lots of time.
-
I think maybe I didn't give enough information
What I need is a board that I can connect to a device like a Zynq board where the zynq does all of the processing and then the graphics is output to some controller.
One way to use this board is for the STM32 be a uGFX server and the main processor sends uGFX requests across a connection and all of the uGFX is done by the server leaving the main processor to do what it does best.
Is this what you had in mind? Or how you use this board currently?
-
Is there a place where users can post widgets that they make? I either need to find or make a table widget. I have looked into making it and will start coding this weekend if it isn't available.
Basically I need a multi-column list with column headers for each row. The number of columns is know when the table is created.
-
Sorry, this isn't a stong area for me, I am just trying to sort it out to make better choices.
Are you saying if I buy the STM32F746G-Discovery card, after I get tired of the small area of the 4.3" display I can replace it with a larger one?
-
I want to build a project to get an idea of how the uGFX library performs on a larger display board. By larger I mean something around 7". I am building an embedded electronic brewery, but I want to use a board that I might want to use in a production environment. Since I am starting from scratch I can consider anything. Is there a way to understand the boards supported by the uGFX system and the performance constraints?
-
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.
-
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.
-
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
-
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)
-
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.
-
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?
-
Did you have to write your own makefile or is it generated automatically by eclipse?
-
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.mkWhen 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 moreIf 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.mkand 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.
-
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.
-
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/mcufontEverything 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.
-
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_pixelAny advise would be good, thanks
-
Victor:
I have made some progress on this if you read my parallel post. To get it to work you need to add directory links to your project and when you do this the autogenerated makefile gets all of the .mk files from all of the directories.
Hope this helps. I have a few more problems to hash out and will let you know when I get it. Or, if you come up with something different I would be interested.
-
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/basicsAnd 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’ -
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.mkI 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.
Widget Repository
in Support
Posted
I copied the List Widget to get a head start on the table widget and the list widget redraws the background and then redraws the text for each row. If there is a large amount of data the redraw shows every line being redrawn.