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;} } }
Sorry. Your program is too complex for me to understand.
I think there are too many lines of code in your function.
Very simple code. You could try it in the uVision simulator.
I don't much like code that can turn on a LED but not turn it off. Or who can turn off a LED but not turn it on.
Somehow, I feel there is a logic error introduced somewhere in the thought process.
yes, there are many lines but it is a short part of debugging....this code is created to analyze controller function or execution...which is nearly same....as main code.
yes per, i also not like such a code...which only turn on led......and also not like code which turn on led wrongly without taking care of pin reading value.....and that's why i posted a problem.
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?