 |
 |
| View previous topic :: View next topic |
| Author |
Message |
KenMacfarlane
Joined: 20 Sep 2005
Posts: 23
Location: Glasgow, Scotland, UK
|
| Does the compiler doesn’t handle if(int1) properly? |
 Posted: Thu Feb 02, 2006 10:51 am |
 |
|
I've converted a bit of code to switch on the value of an int1, where it used to work correctly using an int8 instead...
| Code: | int1
bEndofPCPacket
#define BuffNotEmpty1 (RxWriteIndex1!=RxReadIndex1) // these are both bytes
If(bEndofPCPacket)
{
...is always followed, even when my ICD says that bEndofPCPacket=0
}
whereas
if(BuffNotEmpty1)
always switches correctly, dep upon whether BuffNotEmpty1 evaluates to TRUE or FALSE |
I'm using pcwh v3.235, on an 18f6621. Any comments anybody? Support @CCSinfo.com is bouncign my emails. |
|
 |
rwyoung
Joined: 12 Nov 2003
Posts: 563
Location: Lawrence, KS USA
|
|
| Posted: Thu Feb 02, 2006 11:58 am |
|
|
I take it you typed this in by hand because you don't have a semicolon after your variable declaration.
I don't have an 18F6621 handy but I do have a 16F877A handy.
| Code: | #include <16f877A.h>
#fuses HS, NOWDT, NOPROTECT, NOPUT, NOBROWNOUT, NOLVP
#use delay(clock=20000000)
#use RS232(BAUD=9600,BITS=8,PARITY=N,XMIT=PIN_C6,RCV=PIN_C7)
int1 mybit;
void main()
{
mybit = 1;
if (mybit)
puts("mybit = 1");
else
puts("mybit = 0");
puts("changing value of mybit...");
mybit = 0;
if (mybit)
puts("mybit = 1");
else
puts("mybit = 0");
while(1)
{
}
}
|
Works just fine, I get the following output
| Quote: | mybit = 1
changing value of mybit...
mybit = 0 |
Which is what I expect.
V3.236 compiler. I can back up a revision and test with V3.235 if you like but I don't have any 18F parts at hand to test with right now.
I suggest you look closely at you code to see that you aren't redeclaring or changing the value of your int1 variable accidentally.
_________________
Rob Young
The Screw-Up Fairy may just visit you but he has crashed on my couch for the last month! |
|
|
Ttelmah
Guest
|
|
| Posted: Thu Feb 02, 2006 3:22 pm |
|
|
What is not at all clear from the post, is how the single bit variable is being set to it's 'state' in the first place?.
There was an important change in this area some time ago, to make the conversion ANSI compliant, and this can have implications to functions that use 8bit variables, perform bitwise 'logic' on these, and then convert these to a one bit flag. If (for instance), you do this:
| Code: |
int8 val8;
int1 val1;
val8=16;
val1=(val8 & 16);
|
val1, will actually be set to 'false', not true.
The bitwise operators, do work fine (I use them a lot),but you must be very careful with this type of construction. I'd also not 'rely' on the debugger too much, there have been oddities in the past...
Best Wishes |
|
|
KenMacfarlane
Joined: 20 Sep 2005
Posts: 23
Location: Glasgow, Scotland, UK
|
|
| Posted: Fri Feb 03, 2006 7:15 am |
|
|
The int 1 is set in the last serial ISR of an incoming packet, and yes, I typed the code by hand to focus on my point...
I think that I got fooled by watching the ICD's execution pointer  - it seemed to go through the if's TRUE clause, but because that only really contained one line of code, it has actually stepped over it. So I think that int1's are correctly handled, but the problem was actually due to not having #zero_ram up top - I've come from an IAR C background, where the ram and the registers are zeroed by default.
Interesting point about int8's & int1's though! |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
