Completely lost in getting started. Help?

[tphitonm]

There's no video tutorial anywhere in getting started, and the demo itself it sort of not helpful enough for me. I'm not very well versed in writing gui applications, but in my research I've seen how some other applications do it. It usually has this application where you can drag and drop into a box, and then the IDE generates code for it. (At least that's my understanding.)

 

Is there any way someone can lend a hand-- really holding my hand-- in how to learn to write with uGFX? (Perhaps I'll write a youtube tutorial at some point if I become really good at this.) I'm trying to use a TM4C123G (specifically a TI Launchpad at the moment-- TBD for the future) in Code Composer Studio with a capacitive touch 5.0" display. I'm just using a regular GCC compiler within CCS.

 

Someone mentioned somewhere about integrating QT with uGFX? Is that something that's possible?

Thanks for the help.

[Joel Bodenmann]

2 hours ago, tphitonm said:

It usually has this application where you can drag and drop into a box, and then the IDE generates code for it.

That's the µGFX-Studio: 

 

 

2 hours ago, tphitonm said:

Is there any way someone can lend a hand-- really holding my hand-- in how to learn to write with uGFX? (Perhaps I'll write a youtube tutorial at some point if I become really good at this.) I'm trying to use a TM4C123G (specifically a TI Launchpad at the moment-- TBD for the future) in Code Composer Studio with a capacitive touch 5.0" display. I'm just using a regular GCC compiler within CCS.

We are happy to help with whatever we can. The µGFX developers themselves actually maintain this forum in their spare time. Alternatively, you can purchase a support plan form our website.
You usually start off by having a working project for your platform. Once you have everything running, you'll just add the µGFX library to that as you would with any other library. There is a generic documentation that explains how to add the µGFX library to an existing project on the wiki. Additionally, there are many different IDE specific guides out there that you can have a look at. As far as I know, CCS is Eclipse based so the generic Eclipse guide or the IDE specific guides for IDEs that are Eclipse based (eg. ChibiStudio) will help.
Along these lines: @cpu20 is the IDE integration specialist of this community

 

2 hours ago, tphitonm said:

Someone mentioned somewhere about integrating QT with uGFX? Is that something that's possible?

We provide µGFX drivers that allow rendering to a QWidget and to retrieve user inputs from that QWidget to the µGFX library. It's basically a driver that makes a QWidget become a virtual display (with touchscreen).

[tphitonm]

This is the display that I am using for my project. http://www.newhavendisplay.com/specs/NHD-5.0-800480TF-ATXL-CTP.pdf

The touch driver is a FT5306, which is great because theres ../ugfx_2.8/drivers/ginput/touch/FT5x06

The TFT driver is an OTA7001A, and unfortunately in the ../ugfx_2.8/drivers/gdisp directory, there is no mention of an OTA7001A. Is there any advice on how I can port one of the existing working drivers to work with this driver? Perhaps this driver is similar to one of the already existing drivers?

On a secondary note, I am using the launchpad right now, and I can assign any pins to work with the display. Which file am I suppose to configure to assign any specific pins to map to the display?

[cpu20]

On 02/12/2017 at 17:37, Joel Bodenmann said:

CCS is Eclipse based so the generic Eclipse guide or the IDE specific guides for IDEs that are Eclipse based (eg. ChibiStudio) will help.

That is indeed true. All the Eclipse based IDE's can just follow the Eclipse/Chibistudio guides.

2 hours ago, tphitonm said:

Which file am I supposed to configure to assign any specific pins to map to the display?

The driver for the display you will use is divided into two parts.

There will be a GDISP driver that holds the "high" level logic to drive the display. This will send the right commands to the display, maintain the framebuffer, etc... (see other drivers as examples). The second part is the board-file. This file is the layer between the GDISP driver for the display and the hardware. This file will hold all the functions necessary to send the commands over the hardware interface to the display (I2C, SPI, FMC, ...). This way the driver only has to be written once for that display driver and only the MCU specific interface has to be rewritten.

I hope that makes things a bit clearer. Note that this is a very simplified drawing just for illustration. If you have any questions don't hesistate to ask.

[tphitonm]

Thanks for the explanation, cpu20. If I'm understanding this correctly, what you're saying is that:

• After the HAL layer, I should create a MCU-specific file, such as tm4c123g_ugfxConfig.h that assigns all the pins for functionalities to be used by GDISP and GINPUT
• Have an input file, such as ft5x06.h, that receives the defined names in the above file (tm4C123g_ugfxConfig.h)
• Have a display file, such as ota7001a.h, that receives the defined names in the above file (tm4C123g_ugfxConfig.h)

If this is correct, what is the best template to create a driver for an OTA7001A?

[cpu20]

7 hours ago, tphitonm said:

After the HAL layer, I should create a MCU-specific file, such as tm4c123g_ugfxConfig.h that assigns all the pins for functionalities to be used by GDISP and GINPUT

Yes, but this file does not only assign pin functionality, but also provide functions that use the HAL (or you could directly work with the MCU register whatever you prefer) to send commands to the display. Like write_data() and this function will send the data over the SPI interface using the HAL for example. This file will be called board_OTA7001A.h. If you look into the board/base folder there are alot of examples of this.

7 hours ago, tphitonm said:

Have an input file, such as ft5x06.h, that receives the defined names in the above file (tm4C123g_ugfxConfig.h)

This is the same as for the display. In the drivers/ginput/touch/FT5x06 folder there is a file called gmouse_lld_FT5x06_board_template.h that is used by the FT5x06 driver. This file contains all the function calls needed to communicate with the display. You have to copy this file, rename it to gmouse_lld_FT5x06_board.h and fill in all the functions. Again for examples see boards/base

Laslty is the driver itself. This will be a file gdisp_lld_OTA7001A.c which is the actual display driver. This file uses the function calls from the board_OTA7001A.h file to send all the nescessary commands to the display to configure it etc...
By using the board file you make an abstraction from the MCU, because the commands which are sent to the display to configure it are always the same. So you will write: write_data(OTA7001A_REG_CONFIG, 0x34) for example an this way the gdisp_lld driver does not need to know how the command will be send to the display. It could send this command over I2C, SPI or anything else depending on how you filled in the board file.

[tphitonm]

Thanks for the help.

I found the display driver model page, and I notice that it lists the three different models to implement. Even then, it lists functions at the end such as init_board, post_init_board, write_data, etc. Is there any guidance on how to write these functions, what they require, etc? (Besides the example functions, because they're not very clear to me.)

[cpu20]

I'll do my best to try and explain most of them. Someone correct me if I'm wrong.

• init_board: This function is responsible for configuring the peripherals on the MCU that will be used to drive the display. It should configure all the pins in the correct configurations, put them in a defined stat if nescessary (like putting the backlight/reset pins on the LCD in a known state). Also it should intialize the peripherals used to drive the display (like the SPI-peripheral or I2C-peripheral) and make sure all the clock settings are correct for the peripheral to operate. If external memory like SDRam is used to store the framebuffer it should also be initialized here.
• post_init_board: Anything that needs to happen after the display has been fully initialized should come here.
• setpin_reset: Set the reset pin in a certain state.
• set_backlight: Set the backlight to a certain percentage. Most of the displays have a PWM-pin that can be driven to set the backlight.
• aqcuire_bus: If the display is driven over a bus (like spi) become owner over the bus. In case of SPI lower the chip select (and when using an OS use a mutex)
• release_bus: Release the ownership when it is no longer needed.
• setreadmode: Put the display in read mode.
• setwritemode: Put the display in write mode.
• read_data: Read data from the display.
• write_data: Write data to the display.
• write_index: Send a command to the display.

[tphitonm]

cpu20, thanks a bunch for the descriptions! That's very helpful!

Going back to your graph, one thing that I have a question about is whether my C code should reference the ugfx api, or if I should be writing through the board file.

For instance, if I want to write to the screen, does my C code call out void write_data, which is in the board file, or does it call out void gdispDrawPixel, which is in the GDISP library?

Perhaps in the ugfx repository, there is a specific file that you can reference to? Again, thanks for your help. You've been not only helpful but also patient.

[cpu20]

1 hour ago, tphitonm said:

does my C code call out void write_data, which is in the board file, or does it call out void gdispDrawPixel, which is in the GDISP library?

Your application code should always use the functions from the GDISP library. These functions will use your display driver (gdisp_lld_OTA7001A.c ) to send the wanted pixels to the display, and the driver will then call the functions in the board file to actually send the data to the display.

For all the functions you can use in your application code you can use the API reference.

If there is anything you are uncertain about when writing the driver files, let us know. Always here to help

[tphitonm]

Wow, I get it now. I just noticed the top module "Application Code". It all makes sense now. Thanks a bunch!