-
Posts
130 -
Joined
-
Last visited
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
-
Sorry for the late response. It has been a while that I looked into this. You need to add #include "gfx.h" at the top of your board file "board_ILI9225.h".
-
Can you post your project again?
-
This is indeed an IDE feature. It's called the Indexer in Eclipse. The indexer will search through all files you tell it to search through in the settings and tries to warn you when something is missing/might be wrong. You can completely configure the error and warning levels of the indexer. But if the indexer gives an error/warning this does not mean that the project won't build. The compiler and indexer can be configured independently of eachother. You should read this to understand how the compiler and the linker work. In short, the compiler produces object files for each source file you provide (.c, .s, .cpp,...) and the linker puts them all togheter to get the final program. Due to the fact that the compiler compiles every file independently it will not complain if two files contain a function with the same name. However when the linker is putting everything togheter and it finds two different function implementations with the same name, it does not know what to do. If you call the _init() function in this case it does not know which implementation you want to call. The _init() function used here is already implemented in newlib I think (I could be wrong though, it has been a long time since I dug into this) so you should not implement it again in your own code.
-
-
Does the error change after you comment the _init() function in stm32f439i_raw32_ugfx.c? Anyway you should do a clean build to make sure there are no old binary files that get linked in. Can you give the compiler output? I doubt that the IDE is buggy. It's based on Eclipse which is a well known and widely used IDE. It can just be tricky to initially set up the project. If you post your project I can take a look to see if something is wrongly configured.
-
I should have looked closer.The compiler says exactly where it found the second defenition of the init function. The gnu arm libraries already contain an _init function. Just delete the _init() function from the stm32f439i_raw32_ugfx.c file.
-
The type name gU32 is defined in "gfx_types.h". You should include this in your build.
-
Everything you did look OK to me. Could it be that something is wrong in the file stm32l1152RE_raw32_ugfx.c? Can you attach it here?
-
In the last image you sent inidcates that you haven't correctly included the gdisp configuration file. Adding files to be included in the build is done in the Properties window of your project. Go to: C/C++ General > Paths and Symbols > Includes In that window you need to add all the folders that contain .h files that need to be included in your project for example the folder containing the "gdisp_lld_config.h". Sorry for my late reply. If you have any questions don't hesitate to ask.
-
With Makefile approach do you mean using the Makefile system provided by uGFX? Because then you need to make a Makefile project in Eclipse. When you create a C project in Eclipse, it will create a Makefile for you depending on how you configured the project. When you create a Makefile project, Eclipse will not generate any makefiles and use the Makefile you provide. What you are currently doing is manually configuring the whole Eclipse project to compile correctly. That is a very difficult process, but I think it is possible.
-
uGFX is a graphics library that makes abstraction from the hardware that you use. So you can write a prom that uses the uGFX library to draw things on the screen, reads user input etc.. without knowing what hardware you are using (in theorie). To make the program work with your specific hardware setup, a gdisp driver must be written for your hardware setup. All existing drivers can be found in drivers/gdisp (take a look there to get an idea). The display driver file is called gdisp_lld_xxx.c So in order to make uGFX work with your EPaper display you need to write a driver for it. An example of a driver for an EPaper display can be seen here: After writing the display driver, there is also a file needed that implements the interface between your specific MCU and the display. This file is called board_xxx.h The board file includes functions that send data to the display over a certain interface (depending on the display used). In your case the display uses SPI so the board file will contain functions that use SPI to send data to the display. For an example see the post above. To summarize, you will have to write a driver (gdisp_lld_xxx.c) for your EPaper display and a board file (board_xxx.h) that implements the SPI interface between your MCU and the display. If you have any questions don't hesitate to ask. EDIT: I did a quick google and it seems that the 2.9inch and 2.13inch EPapers are quite the same. It might be possible to copy the driver in the post above and just change the resolutions of the display in gdisp_lld_xxx.c
-
I would start by increasing the stack size of your intialization thread: osThreadDef(defaultTask, StartDefaultTask, osPriorityNormal, 0, 128); 128bytes might not be enough to initialize everything.
-
This is most likely caused because you don't have any file that implements the memory system calls. These calls are system dependent and normally the manufacturer of your platform provides these functions. You can also let µGFX handle memory management by setting GFX_OS_HEAP_SIZE to a non zero value.
-
In your board file, you drive the chip select pin of your display. You should not keep that line constantly low or anything because that can lead to unwanted situations. The chip select line should be lowered and raised in the acquire and release bus functions. Other than that I have no idea if the ST7735 driver is functional. Last time it came up there were some issues with it.