janne_aac 0 Posted April 28, 2010 Report Share Posted April 28, 2010 Hi Folks, I am seeing a very odd behaviour. This is roughly my test program: void testFunc(char test) { if(test > 3) { LED0_on(); //Turn on LED 0 } else { LED1_on(); //Turn on LED 1 } } ….. testFunc(1); ….. I almost cant believe what I am seeing but what happens is that LED 0 is switched on. How can 1 > 3 be true??? This seems to work correctly: void testFunc(char test) { if(test < 3) { LED0_on(); //Turn on LED 0 } else { LED1_on(); //Turn on LED 1 } } ….. testFunc(4); ….. => LED 1 turns on When I look at the ASM file of the first program I see this which also looks odd: MOVF test_Func_00000_arg_test, W SUBLW 0x03 BTFSC STATUS,C GOTO label1 ..... {if...} label1 {else} Shouldn't SUBWF be used instead of SUBLW? Quote Link to post Share on other sites
Reynard 0 Posted April 28, 2010 Report Share Posted April 28, 2010 Can't see anything wrong here. Assembler code is correct as you are comparing against a literal. Your problem may lie somewhere else. Cheers Reynard ps. Give us a clue to the chip type. Quote Link to post Share on other sites
ppulle 0 Posted April 29, 2010 Report Share Posted April 29, 2010 Looks OK to me too. Lets look at the asm assume the argument is greater than 3, lets say 4; MOVF test_Func_00000_arg_test, W will move 4 into W SUBLW 0x03 will subtract 3 from W, leaving 1 in W and no carry in the status register. No need to use SUBWF, we possibly save some code space by avoiding any bank switching if it were needed. BTFSC STATUS,C tests carry flag, and skips the next statement 'goto' if the flag is clear (Bit Test F, skip if Clear) GOTO label1 goto will be skipped as expected and execution will begin in the main part of the if statement ..... {if...} label1 {else} Quote Link to post Share on other sites
davidb 0 Posted April 29, 2010 Report Share Posted April 29, 2010 Since you haven't shown us the code for driving the LEDs or the target being used I suspect the problem may be there if you are manipulating the port pins directly. In this case it is probably our old friend the read-modify-write problem. If you haven't come across this before then there are plenty of references available. Try here for a good description: http://embeddedadventures.blogspot.com/200...s-and-sfrs.html Regards davidb Quote Link to post Share on other sites
trossin 0 Posted May 4, 2010 Report Share Posted May 4, 2010 How does the debugger step through the code? I would guess that might help explain what is going on down in the LED helper functions. Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.