Re: [avr-gcc-list] Re: Passing a string variable to lcd_puts
Problem solved.. The LCD.C and LCD.H files I've been using are NOT part of the WinAVR distribution! This is my work PC, used by others, and someone switched out the fine coffee normally served in this restaurant with Folger's Crystals.. Let's watch. :-P Sorry for the confusion.. I got suspicious last night, and did a search on the machine this morning for all lcd.c and lcd.h files. I'll have to rethink a bit to use the one that came with WinAVR, but that's ok. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] Re: Passing a string variable to lcd_puts
From: david.br...@hesbynett.no
[...char vs. signed cahr vs. unsigned char...]
Don't look it up - if you learn the compiler's default behaviour, you
risk writing incorrect code. If it is in any way relevant whether a
char is signed or not, write signed char or unsigned char explicitly
in the code. The only reason one would ever use a plain char is to
hole a true character - a letter - such as in strings. Since it is (in
general) meaningless to do arithmetic on characters, it does not matter
if the compiler considers them to be signed or unsigned.
All true, but you need to be careful all the same. Consider the case I ran
into about 20 years ago, a custom terminal with Function keys (e.g., F1, F2,
etc) that returned values outside the standard ASCII range (0xF1, 0xF2, etc.).
Consider the following code, stubbed out for illustration purposes:
#define EXIT_KEY 0xF1
extern void process_key(char key);
char get_key(void) {return EXIT_KEY}
void handle_input(void)
{
char key;
do
{
key = get_key();
process_key(key);
} while (key != EXIT_KEY);
}
In this code, the handle_input function falls into an infinite loop if plain
char is signed. This is because key gets promoted (to signed int) before the
comparison with EXIT_KEY (which is already signed int). If plain char is
signed, and key is 0xF1, the sign is extended for key, but not EXIT_KEY.
There are numerous solutions, but I post it here as a warning to the wise.
Sometimes math is performed on character types implicitly.
Regards,
-=Dave
_
Express your personality in color! Preview and select themes for Hotmail®.
http://www.windowslive-hotmail.com/LearnMore/personalize.aspx?ocid=TXT_MSGTX_WL_HM_express_032009#colortheme___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Re: Passing a string variable to lcd_puts
Dave Hansen i...@hotmail.com wrote: In this code=2C the handle_input function falls into an infinite loop if pl= ain char is signed. This is because key gets promoted (to signed int) befo= re the comparison with EXIT_KEY (which is already signed int). If plain c= har is signed=2C and key is 0xF1=2C the sign is extended for key=2C but not= EXIT_KEY. I didn't try it, but wouldn't the correct solution be to declare #define EXIT_KEY ((char)0xF1) That way, EXIT_KEY must be promoted by the same rules, and the comparison ought to work again. -- 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] Re: Passing a string variable to lcd_puts
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. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] Re: Passing a string variable to lcd_puts
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: avr-gcc-list-bounces+larry=barello@nongnu.org [mailto:avr-gcc-list-bounces+larry=barello@nongnu.org] On Behalf Of David VanHorn Sent: Monday, March 30, 2009 10:15 AM To: avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] Re: Passing a string variable to lcd_puts 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. Checked by AVG - www.avg.com Version: 8.0.238 / Virus Database: 270.11.21/2014 - Release Date: 03/30/09 08:40:00 ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Re: Passing a string variable to lcd_puts
I know what *I* am missing - the source code! How is anyone supposed to
help you with your problem until you post the actual compilable code
snippet? We need a compilable code sample which demonstrates the problem,
along with the compiler flags you used and also the compiler version you
used. Getting a warning for int8_t but not for signed char is not
expected behaviour, and I think many people (as well as you) would be
interested to find out if that is really the case, and if so, if there is
some strange compiler issue. But we need the code so that other people can
test this.
Fine.. I thought I must be doing something fairly trivial wrong, this IS
only my second project in C...
I expected to be told that I was using lcd_puts wrong, or declaring
something improperly, or some other noob mistake.
What I'm seeing is certainly unexpected to ME.
I'm very reluctant to throw out bunches of code, when the problem is likely
to be some trivial thing that everyone knows.
/**
Special test case for lcd_puts.
Primary boggle: Compiler warns about mismatched signedness when I pass
unit8_t or int8_t but accepts char.
Secondary boggle, why does it want signed data at all?
FWIW: Same results when targeted for M32 or M644
**/
//System header files (in s)
#include stdint.h //
#include avr/io.h //
#include avr/pgmspace.h // Ability to put strings in pgm space rather than
ram
#include util/delay.h // from c:\WinAVR\avr\include\util
// Application specific header files (in s)
#include avr/interrupt.h //
#include lcd.h// Add lcd.c to the makefile in the SRC= line
#ifndef F_CPU
/* prevent compiler error by supplying a default */
# warning F_CPU not defined before MagSensor.c
# define F_CPU 2000
#endif
// LCD display support variables
//
#define LCD_Line_Len 16// Actual screen char length
// These two are accepted without warnings:
// char LCD_String[LCD_Line_Len + 1]; // Ram buffer for LCD display
// signed char LCD_String[LCD_Line_Len + 1];
// These all generate warnings.
//../LCDtest.c:55: warning: pointer targets in passing argument 1 of
'lcd_puts' differ in signedness
//int8_t LCD_String[LCD_Line_Len + 1];
//uint8_t LCD_String[LCD_Line_Len + 1];
//unsigned char LCD_String[LCD_Line_Len + 1];
//Shouldn't int8_t be the same as signed char?
//0123456789ABCDEF
uint8_t BootString[] PROGMEM = TEST MSG ;
void Delay_QS(void);
void main(void)
{
uint8_t i=0;
while (1){
lcd_init(LCD_DISP_ON);// init the display
lcd_clrscr(); //
lcd_home(); //
for (i=0; 16 i; i++) {
lcd_putc(pgm_read_byte_near((BootString[i])));
}
Delay_QS(); // Visually nicer than just dumping out
}
}
//
//**
//
// Delay_ms has a fundamental limit of 13mS at 20 MHz!
//
void Delay_QS(void)
{
uint8_t i=0;
for (i=0; i25; i++){ _delay_ms(10); }
}
Compiler flags: I tried not to change this from the defaults any more than
I thought absolutely necessary.
-Wall
-gdwarf-2
-std=gnu99
-ffreestanding
-Wextra
-Wunreachable-code
-g
-mcall-prologues
-W
-Wundef
-Wstrict-prototypes
-Wmissing-prototypes
-Wmissing-declarations
-save-temps
-mmcu=atmega644
-DF_CPU=2000UL
-Os
-funsigned-char
-funsigned-bitfields
-fpack-struct
-fshort-enums
WinAVR-20081205
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] Re: Passing a string variable to lcd_puts
From: j...@uriah.heep.sax.de Dave Hansen i...@hotmail.com wrote: In this code=2C the handle_input function falls into an infinite loop if pl= ain char is signed. This is because key gets promoted (to signed int) befo= re the comparison with EXIT_KEY (which is already signed int). If plain c= har is signed=2C and key is 0xF1=2C the sign is extended for key=2C but not= EXIT_KEY. I didn't try it, but wouldn't the correct solution be to declare #define EXIT_KEY ((char)0xF1) That way, EXIT_KEY must be promoted by the same rules, and the comparison ought to work again. That would work. Another way is to have get_key return int. Regards, -=Dave _ Express your personality in color! Preview and select themes for Hotmail®. http://www.windowslive-hotmail.com/LearnMore/personalize.aspx?ocid=TXT_MSGTX_WL_HM_express_032009#colortheme___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] Re: Passing a string variable to lcd_puts
From: i...@hotmail.com That would work. Another way is to have get_key return int. Oops. I mean, of course, make key an int. Having get_key return an int that is then stored into a char would accomplish... nothing. Regards, -=Dave Express your personality in color! Preview and select themes for Hotmail®. See how. _ Express your personality in color! Preview and select themes for Hotmail®. http://www.windowslive-hotmail.com/LearnMore/personalize.aspx?ocid=TXT_MSGTX_WL_HM_express_032009#colortheme___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Re: Passing a string variable to lcd_puts
Correction: The routine in question is lcd_putc not lcd_puts. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Re: Passing a string variable to lcd_puts
On Mon, Mar 30, 2009 at 2:48 PM, David VanHorn d...@mobilefusioninc.com wrote: I thought I must be doing something fairly trivial wrong, this IS only my second project in C... Dave, I have two recommendations for a beginner at C. 1) Buy yourself a copy of Gimpel Lint, even if you have to pay for it out of your own pocket, it will be money well spent in the long run. http://www.gimpel.com/ . It will be the best C tutor you could have. When you run your first piece of code through it you will be appalled at the number errors it finds. Not because you are a beginner, tho that might help, it is because in C it is so easy to shoot yourself in the foot. Alas there are few alternative languages for dealing at the bare metal level. Also you can learn a lot just by reading Gimpel's Bug of the Month: http://www.gimpel.com/html/bugs.htm 2) Get yourself a copy of the MISRA guidelines: http://www.misra-c2.com/ Right now someone on the list is reading that and saying Say what? Recommending MISRA to a new C Programmer?. Yes. Even if you don't try to write your code to MISRA, the explanation of the rules, ie. the landmines you don't want to step on will be beneficial to your C education. If you get truly and utterly stuck, I'm about 90 miles from you and can come down your way some weekend if you need any help. -- http://www.wearablesmartsensors.com/ http://www.softwaresafety.net/ http://www.designer-iii.com/ http://www.unusualresearch.com/ ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Re: Passing a string variable to lcd_puts
I learned to code C/C++ with the dummies book, it gave pretty clear examples. C doesn't have to be hard, just take the time to grock it and not rush it. Also, this is a great read for understanding social dynamics on how to ask people questions and get an answer. http://www.catb.org/~esr/faqs/smart-questions.html http://www.chiark.greenend.org.uk/~sgtatham/bugs.html Steve On Mar 30, 2009, at 6:32 PM, Bob Paddock wrote: On Mon, Mar 30, 2009 at 2:48 PM, David VanHorn d...@mobilefusioninc.com wrote: I thought I must be doing something fairly trivial wrong, this IS only my second project in C... Dave, I have two recommendations for a beginner at C. 1) Buy yourself a copy of Gimpel Lint, even if you have to pay for it out of your own pocket, it will be money well spent in the long run. http://www.gimpel.com/ . It will be the best C tutor you could have. When you run your first piece of code through it you will be appalled at the number errors it finds. Not because you are a beginner, tho that might help, it is because in C it is so easy to shoot yourself in the foot. Alas there are few alternative languages for dealing at the bare metal level. Also you can learn a lot just by reading Gimpel's Bug of the Month: http://www.gimpel.com/html/bugs.htm 2) Get yourself a copy of the MISRA guidelines: http://www.misra-c2.com/ Right now someone on the list is reading that and saying Say what? Recommending MISRA to a new C Programmer?. Yes. Even if you don't try to write your code to MISRA, the explanation of the rules, ie. the landmines you don't want to step on will be beneficial to your C education. If you get truly and utterly stuck, I'm about 90 miles from you and can come down your way some weekend if you need any help. -- http://www.wearablesmartsensors.com/ http://www.softwaresafety.net/ http://www.designer-iii.com/ http://www.unusualresearch.com/ ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Re: Passing a string variable to lcd_puts
David Brown david.br...@hesbynett.no wrote: That's true in C, but C++ considers all three as separate types (C++ is a little bit fussier about mixing types). C99 does as well, but it doesn't enforce it in a strict way. An application making assumptions about the signedness of the type char is simply no longer fully portable in C99 (it is conforming but not strictly conforming to the standard then). GCC can warn about that portability issue. -- 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
