Re: [avr-gcc-list] Passing a string variable to lcd_puts
David VanHorn d...@mobilefusioninc.com wrote:
Recently, I've converted to the portable typedefs as
unit8_t and int8_t
There's no point in converting char (as in: displayable character,
rather than: small integer number used in calculations) to anything
else but char. Displaying a char is the exact reason it has been
designed for, so just write it as char, without any need to care
whether it is implemented as a signed or unsigned data type.
For anything you're doing calculations with, use int8_t or uint8_t.
Usually, when you're in the controller business, there's exactly one
transition between uint8_t and char: the lower hardware layer itself.
If you want, apply an explicit typecast there:
void lcd_putchar(char c)
{
...
LCD_DATA_PORT = (uint8_t)c;
}
Anything above that should use just char, and be happy with it.
String literals are of the implied type const char * (well, rather
just char * for hysterical raisins, but better treat them as const
char *), and again, the signedness of the small integers that
represent the underlying character set should never matter to you.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Passing a string variable to lcd_puts
In C there are 3 char types. char signed char unsigned char so maybe char isn't signed? Ok, so that leaves me VERY confused.. Correct me if I'm wrong, but signed variables use the high bit to indicate negative by setting it to a 1, correct? So, I can only see two options, either you do, or you don't. Char has to equate to signed char, or unsigned char, doesn't it? ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Passing a string variable to lcd_puts
On Fri, Mar 27, 2009 at 04:06:21PM -0400, David VanHorn wrote: In C there are 3 char types. char signed char unsigned char so maybe char isn't signed? Ok, so that leaves me VERY confused.. As you should be. Plain old char *is* either signed or unsigned depending on your choice of compiler. And in effort to build code that runs as expected better compilers have a compile time switch to control code generation when the signedness is specifically indicated. See -funsigned-char, -fsigned-char, and -fno-unsigned-char in the avr-gcc man page. So in short plain old char is only being sloppy in not explicitly stating signed or unsigned. -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Passing a string variable to lcd_puts
Sorry David for the second reply to you. I intended to reply to everyone. David VanHorn wrote: In C there are 3 char types. char signed char unsigned char so maybe char isn't signed? Ok, so that leaves me VERY confused.. Correct me if I'm wrong, but signed variables use the high bit to indicate negative by setting it to a 1, correct? So, I can only see two options, either you do, or you don't. Char has to equate to signed char, or unsigned char, doesn't it? char is either signed or unsigned. The standard leave it up to the implementation as to which is used with an unqualified char type. Traditionally under Unix environments a naked char type is signed, and that is what gcc uses as a default. I believe there is a compiler option that will change this behavior, but I'm too lazy to look right now. -Preston ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Passing a string variable to lcd_puts
David VanHorn wrote: Ok, so that leaves me VERY confused. Maybe it would help to think about logic levels in simulation. The three basic levels are low, high and unknown. The three variations of the char type are similar, signed, unsigned and unspecified. I think that the reason the unspecified variant of char got into the C language definition was political, not technical. The other basic integer types don't share this quirk. The compiler is probably warning you because a signed char and an unsigned char are both different from an unspecified or plain char, just like low and high are different from unknown. The reason that a function would take a char of unspecified signedness is that the writer of the function reasons that only the least significant seven bits mean anything, so why bother with what the MSB does. I think it's kind-of traditional that 7-bit ASCII is represented as a plain char. Personally, I use uint8_t. Graham. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Passing a string variable to lcd_puts
On Fri, Mar 27, 2009 at 04:21:15PM -0400, David VanHorn wrote: As you should be. Plain old char *is* either signed or unsigned depending on your choice of compiler. And in effort to build code that runs as expected better compilers have a compile time switch to control code generation when the signedness is specifically indicated. Ok, that's one of the reasons that I'm using the new types, but I still don't understand why I'm getting the signage warning when I use uint8_t or int8_t to feed chars to lcd_puts. Is int8_t not signed? Yes, int8_t is signed. Is defined in stdint.h as: typedef signed char int8_t; and uint8_t is: typedef unsigned char uint8_t; And why does lcd_puts want signed chars anyway? Isn't negative A nonsense? I think its nonsense, but the origins of convention date way back and might have something to do with the original practice of using signed int for everything. A value might move in and out of signed char out and in to signed int easier than for an unsigned char. Am not familiar with lcd_puts(). Have always written my own LCD code. Somethings are easier to write than to understand what someone else did. Meanwhile the point about -funsigned-char and family was a hint to look into what you are currently running and what was used when lcd_puts() was compiled. Sad, but current project is using Visual Studio 2008 Express where the C compiler has also thrown complaints for mixing signs. And for precision loss when stuffing 32 bits into 8. Generates exactly the same code without complaining if I write u8 = ( u32 0xff ); -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Passing a string variable to lcd_puts
On Fri, Mar 27, 2009 at 4:31 PM, Graham Davies ecros...@ecrostech.comwrote: David VanHorn wrote: Ok, so that leaves me VERY confused. Maybe it would help to think about logic levels in simulation. The three basic levels are low, high and unknown. The three variations of the char type are similar, signed, unsigned and unspecified. I think that the reason the unspecified variant of char got into the C language definition was political, not technical. The other basic integer types don't share this quirk. Right, the unspecified variant looks like a disaster waiting to happen, IMHO. The compiler is probably warning you because a signed char and an unsigned char are both different from an unspecified or plain char, just like low and high are different from unknown. Ok, but using the portable types, there does not appear to be an unspecified char, which seems like a very good idea to me. The reason that a function would take a char of unspecified signedness is that the writer of the function reasons that only the least significant seven bits mean anything, so why bother with what the MSB does. I think it's kind-of traditional that 7-bit ASCII is represented as a plain char. Personally, I use uint8_t. Right, and that's what makes the most sense to me, ASCII is unsigned, so unsigned char should be right, but the routine apparently requires signed! Previously, I was using the unsigned char and signed char forms, and the unsigned char form gave me warnings.. So I used signed char, which satisfied the compiler... Now I'm in the situation where I can't seem to satisfy it with signed or unsigned, in the uint8_t and int_t forms. I don't want to cast aspersions, but it seems to me like lcd_puts is buggy, if it's requiring sign. Graham. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list -- David VanHorn Hardware Engineer MobileFusion, Inc 2715 Sarah St Pittsburgh PA, 15203 Phone: (001) 412-481- Cell: (001) 765-215-8521 Fax: (001) 412-481-0220 d...@mobilefusioninc.com www.mobilefusioninc.com This communication (including any attachments) is for the use of the intended recipient(s) only and may contain information that is confidential, privileged or otherwise legally protected. Any unauthorized use or dissemination of this communication is prohibited. If you have received this communication in error, please immediately notify the sender by return e-mail message and delete all copies of the original communication. Thank you for your cooperation. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Passing a string variable to lcd_puts
David VanHorn wrote: ... the unspecified variant looks like a disaster waiting to happen I don't disagree. And: ... using the portable types, there does not appear to be an unspecified char ... Maybe that's why they're portable. I'm not sure that's the right name for them, though. I tend to call them fixed-length integer types. And: I don't want to cast aspersions, but it seems to me like lcd_puts is buggy, if it's requiring sign. I would agree that it's buggy in that it wasn't written with the same care that you're excercising, but you'll find an awful lot of that and the authors won't generally agree that it's buggy. When you say cast aspersions, are you making a pun? The solution that I would recommend for this problem is to use an explicit cast of the variable from your (well-chosen) type to the type the author of the function has used for the formal argument. Anyone reading the code should be able to see what the cast is for so this will self-document. Graham. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
