if in a interrupt rountine with a 80c51

[zweitakt1973]

hi there,

i have got a problem with a 80c51 processor and Keil C Compiler:

when i use a "if"-structure in a interrupt routine, it is ignored: the
part inside the if-structure will always be executed, even if the
state is false. Can anyone help me?Here a code example:

if (CCF1 = 1)
{
CCF1 = 0;

P0_5 = 1;
}

the code inside is always executed, even if CCF1 = 0.

???why

 

[Keith Thompson]

i have got a problem with a 80c51 processor and Keil C Compiler:

when i use a "if"-structure in a interrupt routine, it is ignored: the
part inside the if-structure will always be executed, even if the
state is false. Can anyone help me?Here a code example:

if (CCF1 = 1)
{
CCF1 = 0;

P0_5 = 1;
}

the code inside is always executed, even if CCF1 = 0.

Consider the difference between '=' and '=='.

The comp.lang.c FAQ is at <http://www.c-faq.com/>. See question 20.22.

 

[Martin Ambuhl]

hi there,

i have got a problem with a 80c51 processor and Keil C Compiler:

If those were the sources of your problems, then your question would not
be topical, since it is about particular hardware and particular
implementations, which have their own newsgroups, mailing lists, and
technical support. Luckily, your problem has nothing to do with the
80c51 processor or Keil C compiler.

when i use a "if"-structure in a interrupt routine, it is ignored: the

If interrupts were important to your problems, then they would not be
topical here. Interrupts are necessarily tied to particular hardware
and particular software to handle them. Luckily, interrupts have
nothing to do with your problem.

part inside the if-structure will always be executed, even if the
state is false. Can anyone help me?Here a code example:

if (CCF1 = 1)

^^^
A beginner's error. You are assigning the value 1 to CCF1, and the
value of the expression 'CCF1 = 1' is 1. You want
if (CCF1 == 1)
Many compilers have warning levels which will flag this, warning you
that you may not have meant to use an assignment here. Check your
compiler's documentation and turn on those diagnostics. Sometimes you
mean to do an assignment within the condition for an if statement. The
normal way to circumvent the warning in such cases (although the
compiler issue an diagnostics it wants to) is by hiding the assignment
within a parenthesized expression:
if ((a = b))

{
CCF1 = 0;

P0_5 = 1;
}

the code inside is always executed, even if CCF1 = 0.

???why

Because CCF1 is always set to 1 before the condition is checked.

As a stylistic aside, it has long been conventional to use CAPS for
macros and not for variables. A reader of your code would expect that
CCF1 and PO_5 would be macros, and wonder what in the world was going on
here.

 

[jacob navia]

hi there,

i have got a problem with a 80c51 processor and Keil C Compiler:

when i use a "if"-structure in a interrupt routine, it is ignored: the
part inside the if-structure will always be executed, even if the
state is false. Can anyone help me?Here a code example:

if (CCF1 = 1)
{
CCF1 = 0;

P0_5 = 1;
}

the code inside is always executed, even if CCF1 = 0.

???why

You are assigning 1 to CCF1, not testing for equality!!!
Then, since the result of the assignment is 1, the
if always succeeds and you always execute the if part.

 

[zweitakt1973]

hi there,

i have got a problem with a 80c51 processor and Keil C Compiler:

when i use a "if"-structure in a interrupt routine, it is ignored: the
part inside the if-structure will always be executed, even if the
state is false. Can anyone help me?Here a code example:

if (CCF1 = 1)
{
CCF1 = 0;

P0_5 = 1;

}

the code inside is always executed, even if CCF1 = 0.

???why

Thank you for answers. You helped me a lot!

 

[Mark L Pappin]

As a stylistic aside, it has long been conventional to use CAPS for
macros and not for variables. A reader of your code would expect
that CCF1 and PO_5 would be macros, and wonder what in the world was
going on here.

.... unless that reader was familiar with microcontroller datasheets
and manufacturers' liking for all-uppercase severly-abbreviated names
for the various special-function registers on those chips. The
identification of chip and compiler, while nominally off-topic here,
provides the context to explain these names.

mlp
(not at work yet, but this is what I do in my Day Job)