Go Down

Topic: Writing data from variable to GLCD. Getting errors (Read 4233 times) previous topic - next topic


OK, I seem to have sorted it. I was not defining a text area. I assumed that by not defining an area, the GLCD would use the full area as the default text area. Once I defined
Code: [Select]

gText  textTop = gText(textAreaFULL);

and pre-pended all my other calls such as print with textTop I found the scrolling now works



I think I understand what you were seeing.
I'm not convinced yet that using a separate text area solved the problem.
(Post note: I believe it is a sketch problem - see below)

There is no reason for a user declared gText object to work any different than
the gText area inside the GLCD object. A user defined text area will work
exactly the same as the GLCD object.

Sounds like you have changed multiple things at once, which is not good
practice when trying to debug or track down an issue.

I'm not sure what you mean by:
pre-pended all my other calls such as print with textTop

The library code does not have anything inside it that works by
clearing the screen instead of scrolling.
So something abnormal/unexpected is going on.

The GLCD object contains a gText object inside it.
The internal gText object is initialized to be the full display during the Init() function.
The when using the GLCD object for printing the text area (that covers the full display)
will behave as you expected. It wraps, if not enough room it scrolls all the other lines,
it erases the line that will contain the text after the wrap, and then it draws the character
that wouldn't fit prior to the wrap.

I ran the sketch you posted earlier and it wrapped and scrolled as expected.
I don't know what AVR you are using but I used a AT90USB1286 (teensy++ board)
which has built in *real* USB support so unread virtual serial port data is buffered inside the AVR
chip. This actually was a bit misleading.
A real Arduino board or clone which uses an FTDI chip or the newer Uno Arduino designs
will send data much slower (9600 baud as your sketch requested)
and potentially lose any unread serial port data if the serial RX buffer overflows.

Since I didn't know what messages you were sending over the serial port or how long they were
I couldn't totally replicate what you were doing.

The only way the display can be cleared and the text position homed, is if either
the sketch code did it itself, or perhaps the processor is crashing
and starting over due to a coding error (perhaps in a library) or memory corruption.

My guess at this point is that you are getting some unexpected behaviors
from your sketch.

There are some things to consider with the sketch code you have.
(Or at least the code that was posted a few entries back)

For example. After you receive a 't', you wait 100 ms before starting
to build your String object.
So that means if you are using a real serial port on the AVR at 9600 baud,
I will never "see" more than 100 characters a time
(it may be less depending on start & stop bits and which AVR chip you have)
Additional characters may be buffered in the serial RX buffer,
but this 't' command won't see it because it only waited 100 ms.
Also, each time you "detect" a string by seeing a 't' command, you build the String
object up and then clear the entire glcd display, and set the text position to (0,0),
and re-select the system font before you output the text.
So each time you receive a 't' command, you clear the screen and home the cursor.
The problem with this is that when the text area is the entire display using the system font,
the display will be 21x8 characters. That is more than 100 characters.

So with your code, using a real serial port on the AVR at 9600 baud,
there really is no way that you can send enough characters to fill the screen and scroll.
It worked for me because I'm not using a real serial port, the AVR chip I used has built in real USB support
so my characters come in USB packets at USB speeds.
"As is" when using a real serial port on the AVR at 9600 baud,
you will end up clearing the display every 100 hundred characters or less.

Also, if you send the AVR more than 100 characters, since the code won't see more than
100 characters, the remaining characters are then interpreted as further commands.
If you happen to see another 't' in the data stream, you will clear the screen and then
print the remaining characters after waiting 100ms.

You also have to keep in mind that the RX serial buffer is a maximum of 128 characters.
So if you send more than 128 characters you run the risk that some might be lost depending
on the timing of your the String object building code (which drains the RX buffer).
It will depend on the baud rate you use vs the delay you are waiting, how many characters you send
and the speed at which they are displayed on the GLCD.

Assuming you are using a real serial port on the AVR, it is definitely your sketch.
I just ran your sketch on a Mega328 AVR which uses a real serial port
and used a FTDI USB to TTL converter (this will be like official Arduino boards)
and it does not work properly. If you send it more than about 100 characters,
things go wonky and you don't get the scroll.
This is caused by the issues noted above.

So you definitely have a sketch logic problem.
You will have to figure out how you want to handle sending "large-ish" text data.
As is, the sketch clears the display on each 't' command and a 't' command cannot
receive more than 100 characters.

There are many ways to handle this, but if it were up to me, I wouldn't try to
buffer entire text messages.

--- bill


I have updated the glcd library to support the Arduino String class in
Printf(), StringWidth(), and Puts() and have created a new RC release for the library.

So if you go grab the RC2 release, it should now work as you wanted it to.

--- bill

Bill, where do I find the RC2 release?  I am running version 22 at the moment and it doesn't work with that.


I've been out of town. Did you resolve this?
The glcd v3 RC2 library release can be found on google code:

--- bill

Go Up