• State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 22 subscribers
  • Views 1683 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Pin reading Problem with at89c2051

shailesh patel

i use at89c2051 micro controller there is a problem with reading the pin value after declaring pin 1(input pin)......controller gives wrong execution...

i already declare pin as a input pin i also place meaningfull part of code..

i also do simulation for same in proteus it work ok but it is not work in real hardware,also there is not any problem in hardware please suggest what to do....

the problem is that both part is executed in superloop (while(1)) here auto is switch

#define ON   0
#define OFF  1

sbit AUTO=P3^4;
sbit LED1=P1^0;
sbit LED2=P1^1;

void main()
{
  unsigned char event,mevent;
  AUTO=1;LED1=0;LED2=0;

 if(AUTO==ON)
  {event=0;}
else if(AUTO==OFF)
  {event=1;}

while(1)
{
  if(AUTO==ON)
  {LED1=ON;}
   else if(AUTO==OFF)
  {LED2=ON;}
}

}

Parents
  • 0 in reply to shailesh patel

    But some interesting things here:

     if(AUTO==ON)
  {event=0;}
else if(AUTO==OFF)
  {event=1;}

    You do an assign to "event" that is never used for anything.

    Next thing - you treat "AUTO" as if it was a variable that can take more than two states. ON or OFF or something else.

    And you do two reads of AUTO which mean that a toggle of AUTO while you read it can actually result in your code neither setting event=0 nor event=1.

    while(1)
{
  if(AUTO==ON)
  {LED1=ON;}
   else if(AUTO==OFF)
  {LED2=ON;}
}


    You have no code line anywhere in your loop that assigns LED1=OFF. And no line that assigns LED2=OFF.

    And here too, you do two reads which means the state decision isn't atomic. And you treat the AUTO pin as potentially having more than two states.

    You haven't documented how LED1 and LED2 are connected - it isn't really obvious that
    LED1=ON (nonzero) actually means a lit LED. Note that it is more common to let processor pins sink current, so a high pin means the LED is off, and a low pin means current goes from VCC through a current-limiting resistor, through the LED and then into the processor pin and down to ground. Lots of microcontrollers can sink way more current than they can source.

    Have you looked at how much current your processor pins can actually source? Or do you help them by having an external pull-up resistor intended to supply the actual LED current and then have the processor pin short the LED?

    Another thing people forgets to think about: What state does the processor pins have when the processor is in reset state? Are the LED:s (or maybe relays or whatever is connected) expected to be active when the processor is in the reset state?

Reply
  • 0 in reply to shailesh patel

    But some interesting things here:

     if(AUTO==ON)
  {event=0;}
else if(AUTO==OFF)
  {event=1;}

    You do an assign to "event" that is never used for anything.

    Next thing - you treat "AUTO" as if it was a variable that can take more than two states. ON or OFF or something else.

    And you do two reads of AUTO which mean that a toggle of AUTO while you read it can actually result in your code neither setting event=0 nor event=1.

    while(1)
{
  if(AUTO==ON)
  {LED1=ON;}
   else if(AUTO==OFF)
  {LED2=ON;}
}


    You have no code line anywhere in your loop that assigns LED1=OFF. And no line that assigns LED2=OFF.

    And here too, you do two reads which means the state decision isn't atomic. And you treat the AUTO pin as potentially having more than two states.

    You haven't documented how LED1 and LED2 are connected - it isn't really obvious that
    LED1=ON (nonzero) actually means a lit LED. Note that it is more common to let processor pins sink current, so a high pin means the LED is off, and a low pin means current goes from VCC through a current-limiting resistor, through the LED and then into the processor pin and down to ground. Lots of microcontrollers can sink way more current than they can source.

    Have you looked at how much current your processor pins can actually source? Or do you help them by having an external pull-up resistor intended to supply the actual LED current and then have the processor pin short the LED?

    Another thing people forgets to think about: What state does the processor pins have when the processor is in reset state? Are the LED:s (or maybe relays or whatever is connected) expected to be active when the processor is in the reset state?

Children
No data