So I’m finally getting around to setting up my 3pi to be a wireless slave. I was a little puzzled at first, because I seemed to always get a “Bad cmd” response regardless of what I sent. After poking around the code, it looked like the is_command and is_data functions were testing against “0” rather 0x80.
From the download file and on line docs:
// Returns true if and only if the byte is a command byte (>= 0x80).
char is_command(char byte)
{
if (byte < 0)
return 1;
return 0;
}
// Returns true if and only if the byte is a data byte (< 0x80).
char is_data(char byte)
{
if (byte < 0)
return 0;
return 1;
}
A minor change, and all seems to work well now. After :
// Returns true if and only if the byte is a command byte (>= 0x80).
char is_command(char byte)
{
if (byte >= 0x80)
return 1;
return 0;
}
// Returns true if and only if the byte is a data byte (< 0x80).
char is_data(char byte)
{
if (byte < 0x80)
return 1;
return 0;
}
I consider myself to be still in the "learning stage with “C”, and thought this info might help other noobs avoid the problem.
Wow, that is interesting. Are you sure that it works your way and not mine? The code definitely worked before, and I expected that it would be okay to compare a signed char value to 0. I guess I should have remembered that in C it is extremely dangerous to do comparisons between different types, and I have no idea what type “0” is under avr-gcc. The way you are doing it is still dangerous, because it relies on a similar assumption about how “<” is going to work. Better would have been to write “if(s < (char)0)”, but the best thing is to do “if(s & 0x80)”.
What version of avr-gcc/WinAVR are you using? Something may have changed between my version and yours.
It feels really strange to have been using C for 19 years and still not be sure what “s < 0” means.
My C bible says that the “char” data type had the range of values -128 to 127, but who knows what the compiler does?
Gcc usually gives you a warning when you are making a comparison that won’t result in a choice (like asking if unsigned char is negative). Was such a warning given?
I started programming long enough ago that Fortran was the first choice of programming language. It has far fewer problems of this nature, but lots of others that the designers of C tried to eliminate. But by introducing so many new data types, and allowing programmers to mix them, they introduced many, many new headaches that are sometimes very difficult to detect and eliminate!
Jim, are you using avr-gcc with the “-funsigned-char” option turned on? By default, the compiler interprets “char” as “signed char” (-128 to 127) but if this option is enabled then it interprets “char” as “unsigned char” (0 to 255).
This would explain why the example code didn’t work for you but it worked for Paul.
Looking back at my original post, I see I was a bit off in my description - commands such as 0xC1 (motor 1 fwd) that required a data byte going to the 3pi was the problem, not “everything I send”. Single byte commands like 0x81 were working fine.
That being said, at Paul’s suggestion, I checked my version of WinAVR, which turned out to be 20090313. So I went ahead and installed the latest version 20100110, the latest Pololu Library, and you guessed it, everything works as advertised.
Color me embarrassed. I appreciate the help, AND the patience as well!
