Touch reporting over I2C

[sean173]

Hello, I have a GTT70A and am communicating with it over I2C.

Since I2C is a master driven protocol and my microcontroller is the master and the LCD is the slave, what query or command do I need to send to fetch any touch events that may have happened from the LCD?

I can see that in the protocol manual that a message with message ID = 135 will be returned, with a prefix of 252, and I assume that this message is sent asynchronously from the LCD to the host when using the UART interface. However, it appears that over I2C I have to initiate all transfers and I can't seem to find a means of fetching any events that may have been registered and buffered in the LCD slave.

Maybe I am misunderstanding the protocol and/or its capabilities.

-Sean

[Raquel]

Hello Sean,

Thank you for posting on the forum.

When the GTT has events to report, such as keypresses, it puts the data in the appropriate communication buffer.
Since I2C is master driven as you mentioned, you will need to poll for data (simply sending a single byte reads).
You will also need to do some set up at init:
gtt_set_default_channel(); // set comm channel to I2C
gtt_set_key_auto_tx(); // set autotransmit off
gtt_set_auto_repeat(); // set repeat mode to hold

You might want to check the client code for the GTT and insert the read and write functions for I2C. There is a parser in the client code that takes care of the protocols like 252 135, 252 165. And you can define a handler to take care of the events.

Thank you,

[sean173]

Hi Raquel,

Thanks for the suggestions. I looked through the example code and it was informative. What interested me was the following functions, as I am trying to do something similar with my code:

gtt_setup_region() // sets up a touch region, should default to 'active on completion' according to the manual
gtt_get_region_activate_state() // should return 1 when run after gtt_setup_region completes
gtt_set_region_activate_state() // passing 0 should clear the activation state and a 1 should set it active manually

So I fleshed out my code with functions that correspond, in sequence to the following list, per your recommendation and got the following responses:

gtt_set_default_channel(); // successfully sent on the I2C bus
gtt_set_key_auto_tx(); // successfully sent on the I2C bus
gtt_set_auto_repeat(); // successfully sent on the I2C bus
gtt_setup_region() // successfully sent on the I2C bus with region ID = 1, x0 = 100, y0 = 100, width=100, height=100, up=1, down=1
gtt_get_region_activate_state() // read back {252, 147, 0, 1, 16}, expected five bytes of {252, 147, 0, 1, 1} indicating that the region was
// created and its state was set
gtt_set_region_activate_state() // sent with state=0 successfullly
gtt_get_region_activate_state() // again, i read back {252, 147, 0, 1, 16} incorrectly

I looked for an example in the code you suggested I download and didn't quite find anything in any of the files which calls these functions. I did find their declarations and definitions of course.

So to recap I was trying to define a region, clear it's activation state, set its activation state by command, clear it again, and then touch the screen (anywhere on it) to see if the state changes. No dice. If you have any, or can point to any usage of these functions or any other info that would be helpful. (it occurred to me that maybe I should be using other functions but I'm not sure which ones to accomplish what I outlined.)

Thank you,
-Sean

[Raquel]

Hello Sean,

The client code, and the examples included work best with GTT Designer output source files. If you look in the Client\examples\windows, GTTProject17.c and .h are output files from the GTT Designer projects.
All the graphic and button (touch regions) created will produce the corresponding GTT2.5 commands. You will not need to create them yourself.

The GTT supports 2 protocols: the legacy protocol (you can find this is the GTT Designer under Legacy Tools tab) with commands detailed in GTT Protocol manual and the 2.5 command set, detailed in the GTT Developer manual

As for your task "touch the screen (anywhere on it) to see if the state changes" have you successfully read back from the display?

[sean173]

Hi Raquel,

I was having some success reading and writing to the scratchpad register and drawing traces on the screen by updating individual pixels using the very basic commands in the Protocol Manual alone. But after reading the Developer Manual and output code from GTT Designer I get the impression that version 2.5 of the protocol is possibly all about defining objects within the display itself (using GTT designer) and using C++ to query and update object properties with the client application and not using the low level commands in the Protocol Manual alone as I was doing. Is this a fair statement?

I am new to C++ development and am a "hardware circuits" developer with extensive experience in VHDL and FPGA programing, and some experience in writing HAL drivers for the hardware I create in C. So it appears that I have some learning to do. Yuk yuk.

[Raquel]

Hi Sean,

Yes, you got it right.
You can keep using the legacy graphics using commands documented in the Protocol manual.

Since we have offered the GTT Designer for GUI development, we had made firmware revisions to accommodate newer graphics and their properties. We found that we needed to update the protocol structure.

Thank you,