GTT Firmware Rev 2.0 capabilities, protocol manual issues

[Fiery]

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:



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



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]

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

[Fiery]

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]

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

[Fiery]

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]

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

[Clark]

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

[Fiery]

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]

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

[deanhuff1]

I know this is a several years old thread but I'm interested in deploying the same way as Tamas stated. Ideally a zero config environment where the controller running on the host computer sends 100% of the data to the GTT via serial communications.

For my needs, I've been able to draw everything manually except for the fonts. If there was some serial protocol that allowed me to send Asset files to the card it would be extremely useful. If storing files on the card isn't feasible. Loading them into RAM on the card would suit me just a as well.

Since this post has there been any additional feature in this area?

[Daniel Divino]

Hi Dean,

We do have a few commands that allow users to create/modify/delete files and folders on the SD card. I believe these commands are what you need to send asset files to the SD card without removing it from the GTT.

I'll see if I can send you a short example tomorrow.

Cheers,
Daniel

[Daniel Divino]

Hi Dean,

You can use the gtt25_filesystem_file_write command to create/write files directly on the SD card.

Below is an example of how to use the File write command to create a .txt file on the SD card

Command: 254 250 15 7
Pathname: 0 0 28 72 0 101 0 108 0 108 0 111 0 84 0 104 0 101 0 114 0 101 0 46 0 116 0 120 0 116
Index: 0 0 0 0
Data: 0 0 49 50 51 52 53 54 55

When these values are sent to the display, a file called "HelloThere.txt" will be created on the SD card. When the file is opened, you should find the files says "1234567".

Please give this a shot, and let me know if you are able to create the HelloThere.txt file on your SD card. From there, we can try uploading other assets.

Cheers,
Daniel

[deanhuff1]

Daniel,

Thanks for this. I will check it out Monday evening.

-Dean

[deanhuff1]

yep, that worked. I've got HelloThere.txt but mine has contents 234567. (not sure where the 1 went) . here are the bytes i sent:

WRITE FILE BYTES ARE: [-2, -6, 15, 7, 0, 0, 28, 72, 0, 101, 0, 108, 0, 108, 0, 111, 0, 84, 0, 104, 0, 101, 0, 114, 0, 101, 0, 46, 0, 116, 0, 120, 0, 116, 0, 0, 0, 0, 0, 0, 49, 50, 51, 52, 53, 54, 55]

Is there a way to write other file extensions? how about to other directories? can i create directories? and could this be used to send a firmware update onto the device and reboot it to make it install? (just trying to cover all of my bases for field upgrades)

thanks
-Dean

[Daniel Divino]

Hi Dean,

It looks like I might have left out a few values in my previous post.

The command is constructed as follows:

Command: 254 250 15 7 //Command Prefix
Pathname Text Encoding: 0
Length of Pathname: 0 28
Pathname: 72 0 101 0 108 0 108 0 111 0 84 0 104 0 101 0 114 0 101 0 46 0 116 0 120 0 116 0//"HelloThere.txt"
Index: 0 0 0 0//File Index
Length of Data: 0 7
Data: 49 50 51 52 53 54 55 //Data to write at the File Index Location

The File_Write command can be used to create new files on the SD card or modify old files on the SD card.

The Pathname dictates where the file will be created on the SD card, or which file will be modified. Please note that if you are creating a new file you cannot specify a directory that doesn't already exist.

Also, you can specify whatever filename and extension in the pathname.

The Index specifies where in the file you want to write data. If you are creating a file, you can simply specify 0. If you are modifying a file and you wan't to modify a specific portion of that file, you can specify the insertion point using the File Index.

The Data simply specifies the data that you are sending to the display.

For example, you can create a "FakeFont.doc" file, you can send the following:

Command: 254 250 15 7 //Command Prefix
Pathname Text Encoding: 0 // Unicode = 0, ASCII = 1, UTF-8 = 2
Pathname Length: 0 38 //38 Characters
Pathname: 83 0 89 0 83 0 84 0 69 0 77 0 92 0 70 0 97 0 107 0 101 0 70 0 111 0 110 0 116 0 46 0 100 0 111 0 99 0 //"SYSTEM\FakeFont.doc"
Index:0 0 0 0 //File Index: Beginning of the file
Length of Data: 0 16
Data: 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 //Data sent to the display "abcdefghijklmnop"

Using this method, it is possible to upload firmware, and other files directly to the display.

We do have a few commands that can create and delete folders on the SD card. It will operate similarly to the File_Write command. I'll see if I can build and example for you.

Cheers,
Daniel