Go Down

Topic: lcd.print and lcd.write at one line (Read 2 times) previous topic - next topic

bperrybap


My programming skills are in junior level.
i didnt unterstund that \010 has the same result that \000 must have!
my code now is lcd.print("\010EPMOKPA\001IA:"); and it is working perfectly!
thanks guys!


Just to be clear here.
From a programming point of view \000 and \010 are different.
\000 is zero and \010 is eight.

The reason it works is due to what Don pointed out.
The lcd treats characters 8 through 15 the same as characters 0 through 7.
So while the code is now sending 8 to the LCD instead of 0,
the LCD interprets 8 as 0 and so it works.

And to keep things even simpler did you try Don's other suggestion?
Using the built in values for theta and sigma?
It works on my lcd.
For theta I can use 0xf2 or \362
for Sigma I can use 0xf6 or \366

Using these you would save having to define and use custom characters
for the theta and sigma.

--- bill

bperrybap

Since you seem to doing something related to temperature, another useful
character when using temperature is the degree symbol.
This is often character 0xdf or \337
So if you are defining a custom character for the degree symbol, you could
try to see if your character set has the degree symbol built in.

--- bill

Tom Carpenter

#12
Jan 06, 2013, 10:24 pm Last Edit: Jan 06, 2013, 10:27 pm by Tom Carpenter Reason: 1
If you don't want to convert to Octal, you can add letters in hex:
Code: [Select]
char string[] = "\x30\x31\x32";
is equivalent to:
Code: [Select]
char string[] = "123";
is equivalent to (octal):
Code: [Select]
char string[] = "\060\061\062";
~Tom~

bperrybap

I just had a quick look at the ANSI standard for escaped character constants to see
what is in the latest standard.
I came away with a new understanding of the standard requirements
(which I think is different from how it worked years ago) and a
feeling that it is kind of a bummer the way it is defined since
it can create potential unexpected issues based on peoples assumptions
of how it works vs how it really works.
The ANSI standard defines these types of constants as:

Each octal or hexadecimal escape sequence is the longest sequence of characters
that can constitute the escape sequence.


So that can create unexpected issues depending on what follows next.
i.e. trying to print the degree symbol followed by 'C'.
"\xdfC"

Would be a problem since the C is a valid hex character.
the hex constant becomes 0xdfc which is too large and then either generates
an error or a warning. If a warning you get the single value 0xfc instead of degree symbol and 'C'.

Same is true for Octal.
While octal has the same issue, it gets "lucky" more often than hex
since octal only uses the numbers 0 to 7.
"\337C" would work as C is not a valid octal character.

Consider this example:
Suppose custom character 1 was an upside-down exclamation
and you wanted a phrase to start with that:

"\00142 is the answer!"

The constant again becomes too large as the compiler interprets
00142 as the value instead of just 001.


It means that you should always use multiple strings and let the compiler
combine them to avoid any potential issues.
i.e.

"\x30" "C"
"\001" "42 is the answer!"

So the safest way to handle escaped constants embedded in a string with other characters
is to always isolate the escaped constants inside their own quotes.

i.e.
Code: [Select]
lcd.print("\010" "EPMOKPA" "\001" "IA:");

lcd.print("\x08" "EPMOKPA" "\x01" "IA:");

lcd.print("\xf2" "EPMOKPA" "\xf6" "IA:"); // use theta an sigma from LCD character set



--- bill

Go Up