Using uGFX in Kinetis Design Studio

[ForTest]

Hello

I'm trying to use uGFX with the KDS 3.2 of Freescale.

The purpose is to generate a GUI from uGFX and manage the code with KDS.

 

The GUI should work in standalone mode without any base OS.

 

I've followed the instructions about import and configuring (gfxconf.h) but i receive the following errors:

"c:\ugfx\ugfx_library\src/gos/gos_rules.h:20:3: error: #error "GOS: No operating system has been defined."

"c:\ugfx\ugfx_library\src/gos/gos_rules.h:24:3: error: #error "GOS: More than one operation system has been defined as TRUE."

etc..

 

Anyone has experiece with importing in KDS ?

 

[Joel Bodenmann]

Hello and welcome to the community!

As the error message tells you, you didn't enable any underlying system abstraction in the configuration file (gfxconf.h). Now that I am writing this I see where the confusion comes from: Even if you don't use an operating system you still have to specify which GOS implementation you want to use. In case of bare metal (no operating system), please enable the RAW32 port by setting GFX_USE_OS_RAW32 to TRUE in the configuration file.

You can find more information about how to use the µGFX library on a bare metal system (without any underlying system) here: http://wiki.ugfx.org/index.php/BareMetal

[ForTest]

Thank you very much Joel

 

I've made the correction and now it compile

I only receive this warning:

GOS: Raw32 - Make sure you initialize your hardware and the C runtime before calling gfxInit() in your application!"

 

I'm working with a SSD1963 display.

I've made some changes on the "board_SSD1963_template.h"

I Receive the error  `GDISPVMT_OnlyOne'

 

Suggest?

[Joel Bodenmann]

3 hours ago, ForTest said:

I only receive this warning:

GOS: Raw32 - Make sure you initialize your hardware and the C runtime before calling gfxInit() in your application!"

It's correct that you receive that warning. It tells you to make sure that you know that you have to initialize the C runtime yourself - our library doesn't do that.
You can suppress that warning by setting GFX_OS_INIT_NO_WARNING to TRUE in the configuration file. You can find the corresponding documentation here: http://wiki.ugfx.org/index.php/GOS#Warnings

 

3 hours ago, ForTest said:

I've made some changes on the "board_SSD1963_template.h"

I Receive the error  `GDISPVMT_OnlyOne'

You must copy the board_SSD1963_template.h file to your project and rename it to board_SSD1963.h.
Please do not hesitate to ask if the problem persists or if you have any other questions.

[ForTest]

Don't work for me

gdisp/gdisp.c:615: undefined reference to `GDISPVMT_OnlyOne'

I can't fine any definition of the class (i suppose is a class) GDISPVMT_OnlyOne in any file in gdisp

In attachment the files i use

 

board_SSD1963.h

gdisp.c

gdisp.h

gdisp_driver.h

gdisp_lld_config.c

gdisp_lld_config.h

ssd1963.h

[inmarket]

KDS is not an environment that we have currently played with yet so you are breaking new ground here.  As such I suspect the problem you are getting is related to how KDS has been set up to compile uGFX.

The following discussion should help you track down where the problem lies...

GDISPVMT_OnlyOne is a symbol that is created by gdisp_driver.h in the situation that there is only one display driver. The definition is the address of the VMT of that driver. gdisp_driver.h is also responsible for defining that VMT. For multiple display scenereo's the way of generating the VMT changes. Unfortunately it is all very complex. The fact that you are getting this error says that something is messed up with the way the driver or gdisp.c includes this file.

I suspect from the renaming of the driver file gdisp_lld_ssd1963.c to gdisp_lld_config.c and your use of undefined(?) symbols such as RD_TFT in board_ssd1963.h that you have moved files from their original location in the gdisp structure or customised one of the files. It is highly likely that that is the source of the problem.

The gdisp system is very sensitive to changes in this area and is complex in the way it handles its inclusions. This is due to its ability to be used in both single display and multiple display configurations. In single display configurations is auto-configures all the various display parameters for you.

You should look carefully at the makefiles (*.mk) in each directory to understand what should and shouldn't be compiled and replicate that within KDS (if you can't use the makefiles directly). The master makefile that kicks everything off is gfx.mk in the gfx main directory. The source files in the gfx directory should not be modified or customised without considerable care - particularly around the gdisp area.

In addition to the master makefile you will also need to include the driver. Look in the drivers/gdisp/ssd1963 directory to replicate the behaviour of the makefile for the ssd1963. The only driver customisation required should be to copy the board_ssd1963_template.h to your project directory, rename it to board_ssd1963.h, and then fill in the routines. Again the original structure and files under the gfx directory should not be modified.

Note that the top level gfx directory must be on your compiler include path and your driver directory (drivers/gdisp/ssd1963) should also be on your include path. If you look at one of the example project makefiles (under the boards/base/xxx/example... directory) you will see the master makefile that we use to pull everything together.

[ForTest]

It works!

It was quite complicated to reconstruct the right hierarchy of the modules but in the end it works.

Some useful tips:

- makefile don't work for me in KDS so i used the inclusion of "gfx_mk.c"

- many path into the g-directory have a wrong path ("../.." missing) so... enjoy & good luck to redefine them!

- try to change values from the top to the bottom of the "gfxconf.h" and see if compile errors decrease

- check to put "TRUE" the show of the widget ghContainerPage0  (into "gui.c")  because was set "FALSE" by default from the uGFX Studio

- "gl" is a variable set by the environment so it is necessary to change the name into the "gui.c" (GListener)

 

In attachment my configuration file for bare metal os

Tested on K64F with KDS 3.2.0 on ARM Cortex M4

Thank you very much

 

gfxconf.h

[Joel Bodenmann]

We are happy to hear that you got it working!

It's true that it's quite complicated to add the µGFX library to a project manually. That's why we try to encourage using the Makefile system whenever possible. Never the less we definitely have to improve the documentation for the other two solutions. If you have any feedback or ideas on this we are happy to hear them!

Regarding the missing "../.." in some files - is it possible for you to tells us where they are? That's something we should fix if that's really a problem.

We also put the two comments regarding the code generated by the µGFX-Studio on our ToDo list. We'll fix those things.

[ForTest]

I think some references in "gdisp/fonts" that point to "gfx.h"

 

[Joel Bodenmann]

Thank you. We put this on our ToDo list.

[inmarket]

The issue with needing the extra ../..'s is likely because you don't have the gfx directory on your include path.

 

[ForTest]

Yes, I realized later how had to work

I think that makefile also should work because KDS use Eclipse that support ".mk" files but i had compilation errors so i changed way and this workaround works for me

You can add "K64F" to your supported microcontrollers list

[Joel Bodenmann]

On 4/6/2016 at 14:58, ForTest said:

"gl" is a variable set by the environment so it is necessary to change the name into the "gui.c" (GListener)

This issue has been fixed for the 0.15 release of the µGFX-Studio (the variable has now been renamed to glistener).

[kengineer]

FYI it's "Kinetis Design Studio" not "Kinetics"

[Joel Bodenmann]

3 hours ago, kengineer said:

FYI it's "Kinetis Design Studio" not "Kinetics"

Thank you for mentioning this. I took the liberty to edit the topic title to prevent confusion and increase the quality of search results.

[ForTest]

Yes, sorry

KDS v.3.2.0 by Freescale

http://www.nxp.com/products/software-and-tools/run-time-software/kinetis-software-and-tools/ides-for-kinetis-mcus/kinetis-design-studio-integrated-development-environment-ide:KDS_IDE

 

 

 

[wctltya]

Hi guys,

Since I didn't guessed to put the library out of the KDS project folder as 'ForTest' did, I've done it in a different way. So here are "my two cents":

Shortly - put the library in the project folder and exclude it from the build except "gfx_mk.c".

Detailed, what I've done:

- Copy library to my project folder in uGFX folder

- Delete all *.mk files. That's probably not necessary, but I've done it. 

- Create my own display driver and my own touch screen driver, keeping the existing folder structure (for example uGFX/driver/gdisp/MyOwnDriver/). Then add these paths to the project properties. In the "_lld_MyOwnDriver.c" need to include proper "module_driver.h", for example in the "gdisp_lld_MyOwnDriver.c" include "../../../src/gdisp/gdisp_driver.h"

- Add the relevant files generated by uGFX Studio in uGFX folder (the library root folder - it must be in the project path as well)

- Exclude from build all sub-folders and files in uGFX/src, except "gfx_mk.c"! How? Right click > Resource Configuration > Exclude from Build

Enjoy

This approach shall work for any Eclipse based IDE, I guess.

[Joel Bodenmann]

Thank you for sharing your experience on getting uGFX working in Kinetis Desing Studio!
I am sure other people will appreciate this in the future. Ideally we would write a detailed step-by-step guide for the "Using µGFX with..." section in the wiki.