|
From: | Larry Barello |
Subject: | RE: [avr-gcc-list] Re: Passing a string variable to lcd_puts |
Date: | Mon, 30 Mar 2009 10:44:03 -0700 |
The way I deal with this is to think of “char” as a
distinct type different than unsigned or signed char. The compiler
certainly thinks that way. So, either keep all your type’s
the same, or, cast. But don’t mix and match char with the others –
the compiler is complaining because it will mess your code up! To reiterate: don’t assume signed or unsigned for “char”
you will be bitten. I was, just yesterday, bitten where comparing a “char”
to 0xB0 failed, but comparing a uint8_t succeeded (and made for smaller code…) Another way to deal with the typeness of stuff is to make the
type explicit. Either cast the constant: #define cHeader ((uint8_t)0xB0) or make a local variable that the compiler will throw away
when it is done: static const uint8_t cHeader = 0xB0; In my case, yesterday, I cheesed out and just made the input
type “uint8_t” and moved on… If I was not in a hurry I
would have made the constants type explicit. I’ll probably pay for
that decision sometime in the future when the code breaks and I spend an hour
or four figuring it out, again… Oh, yeah: Job security! YMMV From:
address@hidden [mailto:address@hidden
On Behalf Of David VanHorn I am still very puzzled over why the compiler balks wether I
use signed or unsigned chars to feed lcd_puts. When I used "unsigned char" it balked. When
I used "char", it didn't. Now when I use int8_t or uint8_t, it balks. No virus
found in this incoming message. |
[Prev in Thread] | Current Thread | [Next in Thread] |