cpu20
-
Posts
130 -
Joined
-
Last visited
Content Type
Forums
Store
Downloads
Blogs
Posts posted by cpu20
-
-
Can you post your project again?
-
On 15/01/2019 at 11:52, tombalabomba said:
Hence, it looks like this is a feature from the IDE telling the user that there is something missing for building the particular source file.
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.On 15/01/2019 at 11:52, tombalabomba said:But I'm really interested in the root cause of this error in oder to understand how I can prevent such issues in future.
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.
-
Just commenting out the _init() function does the trick for me:
-
5 hours ago, tombalabomba said:
As I mentioned in my previous post commenting or deliting _init() in stm32f439i_raw32_ugfx.c doesn't fix the problem of getting the error of a multiple defined _init().
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.
5 hours ago, tombalabomba said:Additionally, I get now a lot of errors originating from non defined ST32F4 Hal symbols.
Can you give the compiler output?
5 hours ago, tombalabomba said:The fact that modification of stm32f439i_raw32_ugfx.c brings in this bunch of additional errors is an indication for me that the IDE is buggy. Apparently, source code exclusion doesn' t work out.
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.
-
On 03/01/2019 at 23:55, tombalabomba said:
/opt/Ac6/SystemWorkbench/plugins/fr.ac6.mcu.externaltools.arm-none.linux64_1.16.0.201807130628/tools/compiler/bin/../lib/gcc/arm-none-eabi/7.2.1/thumb/v7-m/crti.o:(.init+0x0): first defined here
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.
-
On 13/11/2018 at 14:21, Simon said:
is this the correct way to implement the makefile approach in Eclipse?
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.cSo 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
-
21 hours ago, Angus Schmaloer said:
After that i added the ugfx folder to "Source location".
I added multiple filters.From your screenshots it seems that you included all the sources correctly.
21 hours ago, Angus Schmaloer said:First i have imported the whole ugfx folder into the project under the "include" tab under "Path and Symbols".
Not only the uGFX folder has to be included under "Paths and Sybmols", but also your gdisp driver folder. In your case you need to add the drivers/gdisp/ILI9341 folder to your "Paths and Symbols". This should fix the error.
-
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.
-
13 hours ago, zhuantou215 said:
eabi-5_4-2016q3/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/libg_nano.a (lib_a-sbrkr.o): In function `_sbrk_r':
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.
-
That board file uses the Chibios HAL to drive the display. Make sure you have Chibios set up correctly first.
-
According to the datasheet of the ST7586 the controller has a built in GRAM. So in theory you should not need a full framebuffer on the MCU.
10 hours ago, Jens J said:So I’m not sure if one way would be to handle each line write by reading the line from controller into row buffer, updating and writing back out.
Reading from the displays GRAM is according to the datasheet only possible when using the parallel interface. So when using SPI it won't be possible to do this. Otherwise this would probably be the best solution to use the least resources.
10 hours ago, Jens J said:it doesn’t allow us to write individual pixels horizontally, only in groups of three (so very strange!]
Some designers make some very weird decisions...
When not using the parallel interface, I don't think it will be possible to omit the framebuffer.
I think the easiest approach is to keep the framebuffer but only do partial flushing. The controller supports setting a window for the GRAM. So set the window and only write the data that changed. -
Just to be sure: When using the gfxInit routine, does the object still get altered in your main? Maybe the problem is not your GuiLoop.
-
At first sight it seems that the xQueue you give to the xQueueGenericReceive function is not intialized correctly. Maybe something is going wrong with the heap manager when using µGFX?
Could you show us the code where you initialize FreeRTOS and µGFX?
-
6 hours ago, stechy1 said:
Program get stuck at line 179: pem = (GEventMouse *)geventEventWait(&gl, TIME_INFINITE);
That is normal behaviour as you ask to wait indefinitly for an event that never comes. Biggest chance is that the failure is somwhere in the STMPE811 driver.
I will look at your code tomorrow to see if I can catch something. -
On 19/01/2018 at 15:27, Dolence said:
How difficult would be to get it working with uGFX and what are the benefits (beside increased screen size and resolution)?
On embedded systems the increased resolution isn't always a benefit as it will increase your required RAM-size significantly and also the data throughput to your display. Be sure to consider those drawbacks also especially when dealing with animations.
On 19/01/2018 at 15:27, Dolence said:Between 1 and 2 (RA8875 and SSD1963) which one would be faster and better supported by uGFX considering they would be wired to 16-bit FSMC interface?
As the drivers for both displays are already included in µGFX they are both fully supported. As for the speed, my guess would be that the MCU will be the deciding factor.
On 19/01/2018 at 15:27, Dolence said:I want to buy a bigger and faster display for use in a future project.
If you are just starting to experiment which these things and want to experiment more I would recommend the STM32F746G-Discovery board. This board is fully supported by µGFX, is very popular and already has alot of peripherals on board. Also the display is already reasonably large.
-
After creating a program in SW4STM32 and experimenting a bit, it is clear that the method using the uGFXMain() will never work. As stated here no delays are possible before the scheduler is started.
The Init function you were using in your first post and starting the scheduler yourself will be the way to go.
While trying to get a project up and running it took me quite some tries to get everything right to work together and I bounced into a problem in the board_stm32ltdc.h
The stm32f7xx_hal_rcc.h and stm32f7xx_gpio.h need to be replaced with stm32f7xx_hal.h to work properly with the latest HAL libraries. Anyway here is the result if anyone would be interested. -
7 hours ago, Simon said:
like the attached file but I get a compile error when I try to include this.
Are the SCB_EnableICache() functions giving errors? I think to use those you also need to add #include "stm32f4xx.h"
8 hours ago, Simon said:However, using uGFX to initialise FreeRTOS still doesn't work
I have no idea what could still be going wrong. When I got some spare time, I will try to setup a project and see what could be wrong.
-
An example project is now available in the downloads section!
-
55 minutes ago, Simon said:
It is quite likely that my configuration is at fault so my next step is to take a working FreeRTOS demo and add uGFX to it.
I personally don't think your configuration is wrong, but the problem lies in the gfxSleepMilliseconds used before vTaskStartScheduler is called.
FreeRTOS doesn't initialize the scheduler until you explicitly call vTaskStartScheduler. So that means that any call of vTaskDelay before the scheduler is initialized will result in a HardFault (or a hangup). A simple thing you can try to see if this is indeed the problem is to use the HAL_Delay() function again. (Make sure the HAL SysTick is initialized and running by calling HAL_Init and putting the SysTick handler in the stm32fxxx_it.c)
Mutiple definitions uGFX + Eclipse + STM32L1
in Support
Posted
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".