I've tried everything I can think of to replace text with new text, and all it does it overwrite what's there. I've tried outputting spaces to the same area, and also flushing the area before writing the new text. But it won't clear the area. It all juts piles up on top of itself.

Also, why are some parameters shown as signed short? With a display that starts at 0,0 and increments positively to the right and down, why would you ever use negative numbers? Is this just for compatibility with past or future devices?

I'm using I2C, and it's been an adventure getting it to work. How do I know when a command is done? Can I rely on clock stretching to hold off the I2C bus when it's not ready? Or do I have to figure out how long everything takes and wait that long?

Had another idea - tried creating 9 labels, one for each character position, then outputting a null to that label to clear it, followed by the new data. Not real sure how many pixels to allow for the font, but took a guess. There doesn't appear to be a way to set the font size when writing the text into the label. Anyway, that only works twice ("14" in display) and flickers when updated. Not sure if the display is just too slow to keep up, but it is acknowledging every byte correctly. Just doesn't display it.

I understand you are having issues displaying data the way you prefer on your GTT38A. In order to get your display to show data the way you want, there are a couple things you'll have to do.

--First, for ease of use, I suggest saving two "Aero" style fonts in different indexes. One will be font size 40, while the other will be font size 30.

You're on the right track using labels. I suggest using two labels, as you cannot have two different font sizes in one label.

--Use the Create a label" command to create two labels both in different positions on the display. You'll have to play around with the dimensions of the labels in order to ensure that they are the correct size for the font sizes you are using.

--The first label will display the integer-part of your data and will use the 40pt font saved previously.

--The second label will display the fractional-part of the data using the 30pt font.

Once the data is updated, you require a method of erasing the data. The "Flush region" you attempted to use previously is actually used to purge all bitmaps stored in the bitmap buffer to one region of the screen. It is used in conjunction with the "Manual Update" command. Also, as of now there is no command that can clear a specific region of the display. So here is a work around.

If you are using a single color back ground, drawing a rectangle will work perfectly for you.

--Use the "Draw rectangle" command to draw a rectangle of appropriate width and height over the labels you have updated. You can change the color of the rectangle drawn in order to blend with your back ground.

If you are using a more complex background, you may have to use the "Copy Rectangle" command.

--Specify a region of the display that you would like to copy, and that region will be copied and stored as a bitmap in your bitmap buffer.

--Use the "display bitmap" command and display the stored image over top of your labels to "erase" the data. Since the background is copied over from another region, it may be easier to blend in with the rest of the background.

When necessary, just use the update label command to update the data displayed on the screen.

As for your question regarding signed shorts, you've pinned the tail on the donkey! The reason we use signed shorts is so the firmware is compatible with previous products that used signed shorts.

As for knowing when the command is done, I believe my colleague Raquel has offered some advice. I'll post it here again just in case anyone who stumbles upon this thread is curious as well.

As per how long a command is processed, what I can suggest it to have a
'synchronization' command.
Say you have sent a command to write/update your label, follow it with a
'synchronization' command -
ie any command that would report back some expected data, for eg 254 3
Get Display Metrics, which in your case would always return 252 3 0 7 1
224 0 74 5 6 5 (Width=480 Height=116 and RGB bits =5, 6, 5).
As soon as you are able to read the expected data from your
'synchronization' command, then for sure you know that the previous
command sent has been processed.

-Raquel

I suggest giving this method a shot and seeing what you can do with it.

Thanks. That's a lot of work to just write new data to a spot. The Label command says that a null will erase it, and that seems to work, but I'm still having a heckuva time getting the timing right. I need to be able to update strings perhaps 10x/sec. (100ms) because it is the display for a main tuning knob. Is this possible?

"Use the 'Create a label' command to create two labels both in different positions on the display. You'll have to play around with the dimensions of the labels in order to ensure that they are the correct size for the font sizes you are using. The first label will display the integer-part of your data and will use the 40pt font saved previously. The second label will display the fractional-part of the data using the 30pt font."

I don't see a way to set the font size when creating labels. The only font size command is "Set Font Size" and it refers to the "current font". The "Update a Label" command says "The string...should be capitalized and one line in height". Huh? One line in height? What does that mean?

It did work to output a null string in "Update a Label" as a way to clear the characters.

You are correct. The null character will work to clear the labels. I apologize, as I misunderstood your previous message and thought you were unable to clear your labels with the null character.

As for creating the label, there is a parameter that allows you to select the font you would like to use in that label. I suggested earlier to upload two "Aero" fonts (One 40pt, the other 30pt) onto the SD card. Then you would have to load them into the buffer as font index 1 and font index 2. You would then select index font 1 for the first label (40pt) and use index font 2 for the second label (30pt). But as you stated, that is a lot of work.

Uploading one "Aero" font onto the SD card and using the "Set Font Size" command to alternate font sizes during update is another method that will work, similar to the code you show in your first post.

When labels were developed, they were meant to display values, and weren't developed with updating large text paragraphs in mind. Although updating longer length texts is possible, we recommend sticking to one line of data display on the label.

Using capital letters is recommended to prevent parts of letters being cut off. For example, with some fonts, lower case letters such as j and g would be cut off due to the label size and the pt size of the font used. You can adjust the label and font to your liking to ensure that lower case letters will fit in the designated region, but capital letters are a lot less of a hassle. But since you are only updating number values, this shouldn't be an issue.

As for the update speed of the display, the main concern with updating the strings is the actual rendering and drawing of them onto the display. Times can increase by minimizing what the display has to render, but during my tests using 40pt Aero font, and updating two labels with 5 characters each, I saw no issue updating the strings 10x/sec.

"As for creating the label, there is a parameter that allows you to select the font you would like to use in that label. I suggested earlier to upload two 'Aero' fonts (One 40pt, the other 30pt) onto the SD card. Then you would have to load them into the buffer as font index 1 and font index 2. You would then select index font 1 for the first label (40pt) and use index font 2 for the second label (30pt). But as you stated, that is a lot of work."

How would you upload two Aero fonts? It's a true type font, scalable real time. How would one do that?

BTW, if I stay with this font, I will probably have to create separate labels for each digit. Aero is a proportional font, and the number shifts back and forth as it creates different numbers. "1" is especially bad since it doesn't take much room. I tried right justifying, and that helped a little, but it will probably look better to just allocate the same number of pixels for each digit and center each digit. Might look awful too. Just gotta try it.

Anyway, it is working now, but I did insert a 50ms delay after every reasonable group of commands just to see if the issue was timing. It's harder for me to issue periodic read commands and then wait for a response. I queue up display commands as different parts of the program execute, and it is just better to know that they completed so the interrupt routine can move on to the next one. Having a "ready for data" interrupt would be real handy, or even an I2C clock stretch.

I apologize again for the false statement. You are correct, the Aero font is a scalable font meaning you'll only have to upload one font and change the font sizes when it is used. The method described above is more intended for using different font types.

The changing proportions of the Aero font was something I noticed as well. Separating each digit is one way of approaching the issue. I think it would work best aesthetically for your situation.

After talking to my colleague about the "ready for data" interrupt, he explained there are issues doing that through I2C due to the Master/Slave relationship. We have provided this functionality in serial protocol via the "Request to Send and the " Clear to Send" but it is a little more difficult to accomplish in I2C.

Again, I suggest using the synchronization command Raquel had described.

Got it mostly working. A few glitches, but got the basics down. When creating labels, I can update without having to clear first, so that's cool. Here's my first successful attempt to write the Aero font, using individual labels for each position, so I can center each character in the block. That gets around the problem with it being a proportional font, which makes the display jump back and forth as it writes a whole string. The color is a little off in the photo - it's actually orange, brown and white. Looks pretty cool!