if statement doesn't work..???

Jody · Joined: 08 Sep 2006 Posts: 182

Hallo,

When debugging I get to a point where the variable is set (string_ready=1) and the if statement just steps over it...

[code]
while(TRUE)
{
if(string_ready)
{
printf("Alive");
}
}
[/code]
[img]http://home.casema.nl/elselinde.wisman/Debugger.jpg[/img]

Thanks in advance,

Jody

SLo · Guest

The code in the If statement does nothing.
You're testing a variable that can never change within the infinite loop in main().
So the compiler is allowed to, and is more efficient to remove the code.
My guess is that if you look at the assembler listing of the output, that there will be no code generated for the If statement concerned.

Jody · Joined: 08 Sep 2006 Posts: 182

In mine ISR routine is it possible to change the variable.. and in the main function I reset the variable..
[code]#int_rda
void serial_isr()
{
string[next_in]=getc();

output_toggle(ERROR);

if(string[next_in] == '\n') //Einde string
{
output_high(CTS); //Stop communication
string[next_in] = '\0';
output_toggle(HARTBEAT);
string_ready = TRUE;
}
}[/code]

Neckruin · Joined: 17 Jan 2006 Posts: 66

In your serial interrupt you dont manage your next_in counter. Anyway a don't think thats the problem.
Maybe the condition within the ISR is never TRUE. I mean, maybe, you never detect the end of the string '\n' for some reason.
I suggest you to force a clear_interrupt(INT_RDA); and try to add disable_interrupts(INT_RDA) at the beggining of your code and enable_interrupts(INT_RDA) at the end.
It may help but is not sure, I'm just suggesting things that you may have already tried.
Good Luck.

Juanma

PD. I hope someone else more skilled than me helps you as well.

Jody · Joined: 08 Sep 2006 Posts: 182

When I watch the variable with the ICD I can see that it is set. But it steps OVER the if statement. See the picture.....[img]http://home.casema.nl/elselinde.wisman/DEBUGGER2.jpg[/img]

Neckruin · Joined: 17 Jan 2006 Posts: 66

Unfortunately I'm not used to the debugger you are using. I can't help you if the problem is the debugging process.
Maybe the problem is in the next "if" statement, not in the first one.
Sorry for being so few helpful Sad

Good Luck,

Juanma

SLo · Guest

You didn't mention the ISR in the original post, so I was unaware of it.
As your code looks fairly short, please post your full code, the version of the compiler that you are using and the target PIC device.
If possible also post the assembly listing for the code.
When you post code into the forum remember to check the 'Disable HTML in this post' selection.

Jody · Joined: 08 Sep 2006 Posts: 182

Ttelmah · Guest

Some debuggers have problems stopping on certain lines, and handling logic on bit fields. It may be that yours is one that shows this behaviour. Look at the .lst (assembler) file. The if statement, certainly should exist, but probably as a BTFSC, or BTFSS instruction, which will 'skip' the next line depending on the test.
It is relatively easy to find the code, since the compiler inserts the C code as comments into the file.
If you don't understand the assembler, or it does not make sense, post the 'snippet' covering this line. (one line in front, and a little after).

Best Wishes

Jody · Joined: 08 Sep 2006 Posts: 182

SLo · Guest

The code appears OK at a glance, your compiler is a later version than mine so I can't try it as mine does not support this PIC.
The assembler extract is indeed the correct one, though this does not match exactly the code you posted as the assembler is
if(string_ready == TRUE)
and the code is
if(string_ready)
But, the assembler means Bit Test in File, Skip if Set (BTFSS)
so if the bit in position zero is set then the next instruction will be skipped.
From this we can deduce that the compiler is using Bit 0 of memory address x3A as the int1 (boolean) variable string_ready.
If this is true (set, or =1) then the code will continue to run into the next instruction after the BRA 1434, but if the bit is not set, the next instruction is not skipped, so the BRAnch to address 1434 is executed.

This apart, Ttelmah may be correct in that the instruction is really a sort of 2 instructions in 1 - test the bit & skip if required. This may make it impossible to stop the debugger - the 2 parts can't be seperated.

So, if you run the code without the debugger does it work, if not what do you see on the serial port - I guess that you quickly fill your terminal with '.' characters, you might consider removing this.

Also you are in danger of writing into memory that you did not intend in the serial receive interrupt as you don't test that you've reached the end of string[] and copy the received character into string[next_in] even if next_in is larger than the size of string[].
'C' will happily assume that you know what you are doing and will glibly write over whatever happens to be really in the memory - we've all done it and some of still do it!

Ttelmah · Guest

You may find that if you insert the debugger stop on the assembler line, rather than the C line, it'll then work. The code required for the 'if', is there.

Best Wishes

Jody · Joined: 08 Sep 2006 Posts: 182

I have run the program without the debugger... The result is the same...
It doesn't go into the if statemant... I printed out the value over the serial port.. so I know for sure the variable has the value = 1.

I think the problem is in the interrupt routine... And I am happy to rewrite the serial routine, but I don't know what you mean about it and what I must do....

When I use a variable (in the if) that is not comming from the interrupt routine it is working like it should be...
But then again, what I have done should work....???? I think

ckielstra · Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands

Strange that your code is working when you use a variable that's not inside the interrupt routine. In your interrupt routine I spot two errors that might have to do with the strange behaviour:

1) You are storing data in the string array but you are not testing for exceeding the array limits. When receiving more than 16 characters you will be overwriting other data (variables) in RAM with unknown behaviour as a result.
2) You never reset the next_in variable. Same result as 1.

And...which compiler version are you using?

sjbaxter · Joined: 26 Jan 2006 Posts: 141 Location: Cheshire, UK

Jody,

You do have one potential problem...

the string buffer 'string[]' is allocated as a 16 char array, but the index you use to write to it is never checked to ensure that it only has a value between 0(zero) and 15 !!! (the bounds of this array).

You could be overwriting the array buffer and corrupting the string_ready flag and other variables in memory that are allocated after the string[] array.

Edit : ckielstra ... you beat me to it ! Smile

_________________
Regards,
Simon.