GTT Firmware Rev 2.0 capabilities, protocol manual issues

GTT TFT Support

Moderator: Mods

Post Reply
Fiery
LCD Geek
Posts: 36
Joined: Wed Jul 09, 2014 2:38 pm
Location: Budapest, Hungary
Contact:

GTT Firmware Rev 2.0 capabilities, protocol manual issues

Post by Fiery » Mon Jul 14, 2014 1:07 pm

Hi,

I've gone through many documents about GTT, but still not 100% sure if these things are supported by GTT 2.0, so I thought it's best to ask. I suppose most of them would be "not supported", but maybe there's a trick that can be used to achieve these:

1) Is it possible to programatically enumerate the SD card content, or check if a specific file exists on the SD card? I'd like to provide the (Windows PC) user of our software a combobox to select which font he wants to use for textual elements, and which bitmap images would he want to display at a certain (X,Y) position on the GTT LCD, but haven't found a way in the protocol manual to check which files can I offer the user on the software's GUI for use. For power users such a combobox wouldn't be necessary, but our software is used by less-experienced guys as well, so we wanna make sure we design the GTT LCD layout builder as easy-to-use as the GTT interface permits.

2) Is it possible to put a full-screen bitmap image as a background on the LCD, and then put some text on it, and then have the text updated e.g. once a second? Like a running digital clock in the format of "12:34:56" with 36-pixel font, with the text's background being the background image, rather than a plain colour of the selected background colour? I suppose the best way to have a non-constant (dynamic) textual element is by defining a label, but then as far as I can understand, labels cannot have transparency. What I'm looking for is something like this, with the digital clock rendered using a TrueType font:

Image

3) Is it possible to have 3D bars? Like the yellow and orange vertical bars on this screen shot:

Image

4) Is it possible to draw Windows XP Task Manager / CPU Usage History style line graphs with grids? 4 examples can be seen on the screen shot I've linked in #3 above.

5) Is it possible to draw partly overlapping PNG images over each other using their alpha channel to control partial transparency? Or only BMP transparent colour selection is possible?

6) Is it possible to programatically copy (or create) files on the SD card using XModem or some other protocol? With the GLK this was possible, but with the GTT I cannot see such a thing supported. With fonts and small bitmaps this would be a very convenient way to offer the user more flexibility while he's building a dynamic LCD image.

7) Is it possible to detect how much free space of the 32MB buffer memory the device has left?

8) Is it possible to clear label buffers using the "Clear A Buffer" (0xFE 0xD0) command? In the GTT Protocol Manual Rev 2.1, on page 18, section 5.6, there's a chart (Table 16) that lists Animations, Bitmaps, NineSlices and Fonts, but I cannot see labels there. Maybe value 4 is Labels? Are there any other buffer types that's missing from Table 16? ;)

9) In the same document, in the Revision History, for Rev 2.1 it says "Added Scripting, Label, and Strip Chart Features". But in the document I cannot find anything about strip charts. What are those, and why aren't they included in the document?

Thank you in advance.

Regards,
Tamas

Tino
Matrix Orbital
Matrix Orbital
Posts: 158
Joined: Wed May 22, 2013 9:04 am
Location: Matrix Orbital
Contact:

Re: GTT Firmware Rev 2.0 capabilities, protocol manual issue

Post by Tino » Mon Jul 14, 2014 2:34 pm

Hi Tamas,

To answer your questions:

1) At the moment this is not supported.

2) This can be accomplished with Labels. When you create a Label the label copies what is behind it as its background. So as long as the background you want is there than it will act as though it is transparent.

3) This could be accomplished using 9-slice bars.

4) This is possible. The line graphs with the GTT work the same as labels. Graphs will copy the background when it is defined. To accomplish this I suggest displaying a bitmap of a grid where the graph is going to be set.

5) This is possible, although PNG files use 2x the ram and drawing of it will be slower.

6) At the moment this is not supported.

7) At the moment there is no way to detect the free space of the buffer memory within the display protocol.

8) At the moment this is not supported.

9) This was meant to be Trace Graph. Thank you for bringing this to our attention I will forward this on to have the manual fixed.

We are currently looking into numbers 1, 6, and 8.

Thank you
Martino
Martino DeLeon
Matrix Orbital
Technical Support Representative

Fiery
LCD Geek
Posts: 36
Joined: Wed Jul 09, 2014 2:38 pm
Location: Budapest, Hungary
Contact:

Re: GTT Firmware Rev 2.0 capabilities, protocol manual issue

Post by Fiery » Tue Jul 15, 2014 2:51 am

Thank you for your reply, I'm glad 1, 6 and 8 are considered as a future addition to the GTT Protocol. I'm wondering, if the protocol gets updated and so enhanced with new capabilities, will I be able to update the firmware of my existing GTT50A device to gain access to the new "juice" free of charge? Or will I have to purchase a new device that supports those capabilities?

As for the other points:

3) I think it may be possible to make it with 9-slice, but since the 3D bar graphs we use could be any size, the 3D gradient could be a problem. Unless of course we copy a few dozen of different 9-slice variants to the SD card to cover different bar graph sizes :) Which would only be possible if we could programatically copy the files we need on the SD card to avoid filling the card up with unused files :)

4) The graph I'd like to display has a moving grid, so I'm afraid a constant bitmap background wouldn't work. I could of course clear the old grid after an update (using Draw Filled Rectangle), and draw the new grid using Draw Line command, but with e.g. a 400x300 pixel graph with a 10x10 pixel grid would be too many draw commands to issue :( I of course fully understand that you cannot design a protocol that covers every single developer needs, so all I'm doing in this topic is merely giving you an insight on what I'm trying to achieve, and I'm trying to find out what features may we expect that you make it possible in the future. Understanding the current protocol and the potential future developments of the protocol is crucial for us to develop the GTT LCD layout designer for our software.

Thanks again, you guys have an excellent tech support staff!

Tino
Matrix Orbital
Matrix Orbital
Posts: 158
Joined: Wed May 22, 2013 9:04 am
Location: Matrix Orbital
Contact:

Re: GTT Firmware Rev 2.0 capabilities, protocol manual issue

Post by Tino » Tue Jul 15, 2014 7:57 am

Hi Tamas,

When new Firmware comes out for the GTT you can find it here:
http://www.matrixorbital.ca/software/GTT2.0/

And yes it is free of charge!

What about using a 9-Slice Bar Graph? This may work for you.

Thank you
Martino
Martino DeLeon
Matrix Orbital
Technical Support Representative

Fiery
LCD Geek
Posts: 36
Joined: Wed Jul 09, 2014 2:38 pm
Location: Budapest, Hungary
Contact:

Re: GTT Firmware Rev 2.0 capabilities, protocol manual issue

Post by Fiery » Tue Jul 15, 2014 9:43 am

I'll check the 9-slice bar graphs, thank you for the tip.

One more issue I've run into: is it safe or advisable to issue the Reset Module command the first time you initialize the GTT LCD in a software? Does it have any impact on the lifespan of the device? And if it's safe to use, then how to know that the device is booted up properly? Do I have to simply wait for 2 or 3 seconds after issuing the Reset Module command to let the device boot up? Or is there a more sophisticated method to find out if the device is ready to accept drawing commands? Like right after the Reset Module command I'd send the Get Module Type command, and when the device is up and running, I'd get the response back from the device?

I've tried less drastic methods to get the device back to its "empty" mode, by emptying all read and write queues and then issuing the Clear All Buffers command, but it didn't help in many cases to get the device back to work 100% reliably. Fortunately the Reset Module command gets it back everytime, but it feels a bit too drastic to use that...

Tino
Matrix Orbital
Matrix Orbital
Posts: 158
Joined: Wed May 22, 2013 9:04 am
Location: Matrix Orbital
Contact:

Re: GTT Firmware Rev 2.0 capabilities, protocol manual issue

Post by Tino » Tue Jul 15, 2014 10:15 am

Hi Tamas,

The Reset Module command only resets the display, the same as if you were to cycle power. A good way to check if the display is ready to receive commands is to, as you said, send the Get Module command until you get a response from the display.

Thank you again for posting on our forums.
Martino
Martino DeLeon
Matrix Orbital
Technical Support Representative

Clark
Matrix Orbital
Matrix Orbital
Posts: 861
Joined: Fri Aug 17, 2007 10:58 am
Location: Matrix Orbital
Contact:

Re: GTT Firmware Rev 2.0 capabilities, protocol manual issue

Post by Clark » Wed Jul 23, 2014 10:56 am

Hi Tamas,

If you're looking for an alternative to the Get Module command, specifically for the GTT, you might consider adding an Echo command at the end of your autoexec file. That way, once the GTT has finished booting and executing all other autoexec commands, it can echo a response of your choosing back to your host controller.

Thanks,
Troy
Troy Clark
Design & Development
Matrix Orbital

Fiery
LCD Geek
Posts: 36
Joined: Wed Jul 09, 2014 2:38 pm
Location: Budapest, Hungary
Contact:

Re: GTT Firmware Rev 2.0 capabilities, protocol manual issue

Post by Fiery » Thu Jul 24, 2014 3:44 am

Clark wrote:Hi Tamas,

If you're looking for an alternative to the Get Module command, specifically for the GTT, you might consider adding an Echo command at the end of your autoexec file. That way, once the GTT has finished booting and executing all other autoexec commands, it can echo a response of your choosing back to your host controller.

Thanks,
Troy
Thank you for the tip. Problem is: we would like to minimize the number of actions the user (of our software) has to make related to the SD card, so creating or copying an autoexec file is not something we would want to do. Ideally, our software should be able to transfer every files it needs to work to the SD card automatically, and enumerate the files the next time (to avoid transferring such files that it has already copied to the SD card), but right now both such tricks are not possible. Our software is used by many enthusiasts who are perfectly capable of handling the task of copying files to the SD card of the GTT, but even those users would prefer our software to handle *.* automatically, without their intervention. With the GLK/GLT protocol it is possible for a software to transfer files to the module's built-in memory: something like that for the GTT protocol would be awesome to have one day ;)

Clark
Matrix Orbital
Matrix Orbital
Posts: 861
Joined: Fri Aug 17, 2007 10:58 am
Location: Matrix Orbital
Contact:

Re: GTT Firmware Rev 2.0 capabilities, protocol manual issue

Post by Clark » Thu Jul 24, 2014 4:51 pm

No worries Tamas,

We appreciate your insight and we will definitely look at changes and improvements for the GTT line in the future. With field upgradeability, updates are significantly easier than ever before.

If you have any ideas for your specific project that you'd rather not discuss in a public forum, please don't hesitate to contact me directly at tclark@matrixorbital.ca.

Thanks,
Troy
Troy Clark
Design & Development
Matrix Orbital

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests