reading Sbuf

i think you need a bigger processor to do it.

Think!

ha ha. i THINK that if a little baby was in the road and a car coming andrw would just shout to the baby THINK.

And you would just shout to it that it needs to be in a different road?

?????????

you are the saying we use. "my elephant with one tusk cant carry your tree"

ok any suggestion??

Thinking...thinking..... on peak point of project..need help from Experts!!

How do you you identify when something has been received...?

Think, then, about what criteria could be applied to determine that nothing has been received...

Look at all the facilities (peripherals) in your chip - which of those do you think could help...?

Here is code

/* /Program to interface RFID with 8051 microcontroller (AT89C51)
Program receiving character/Tag ID serially and security alarm system
baud rate 9600, no parity, crystal freq 11.0579 Mhz*/

#include <REGX51.H>
sbit s10 = P1^0;
sbit s11 = P1^1;
sbit s12 = P1^2;
sbit s13 = P1^3;

void green_led_on()
{ SBUF='*'; s12=1; s13=1; s10=0; s11=0;
}

void red_led_on()
{ s10=1; s11=1;
}

void main( )
{ char recID;
P2=0x00;
P1=0x00;
P0=0x00;
TMOD=0x20;
TH1=0xfD;
TR1=1;
SCON=0x50;
IE=0x90;
RI=1;
while(1)
{ if (RI=='1')
{ recID=SBUF;
RI = 0; if(recID==55) { green_led_on(); }

else if(recID==10) { green_led_on(); }

else if(recID==74) { green_led_on(); }

else if(recID==104) { green_led_on(); }

else { red_led_on(); }
} }
}

"need help from Experts"

Harzel Dimbaar is your man, bro.

Harzel Dimbaar is your man, bro.

thanks man,. you are not the elephant with one tusk

start a timer when ever u get a char with da RI

if timer gets to high u know u have not rx anything for a time

then u can light da led to say "notghing rx"

has da cpu got a good timer for this?

"And you would just shout to it that it needs to be in a different road?"

No - he would wonder if it can be put in an EEPROM or not.

Help me

This isn't a hard enough problem that experts are needed.

But you need to look at your code (of which we know nothing) and see if you see any logical errors. If not, then spin up a debugger and test the code and see if it someplace does something different from what you intended it to do.

Debugging is the way of figuring out why a system behaves differently from intended. It can't be avoided. But you debugging with real code and real hardware is way easier/faster than we trying to debug your unknown code without access to any hardware - and do it by correspondence.

Debugging is one of the most important things that the school wants you to know about before you leave. So don't skip your chances to really learn how to split a problem into two smaller, and analyze each partial solution. Then continue to break the problem into smaller and smaller sub-problems until they are small enough that you can grasp exactly what happens and why - and make sure that these individual sub-problems are correctly working.

Then work yourself up again, making sure your small boxes interfaces correctly with the other small boxes. Continue with bigger and bigger boxes until you are back at the full program again - it should now work, unless you skipped some step somewhere. Or unless you find out that your original problem can't be solved - maybe because of lack of CPU capacity or incorrect specifications.

Does your program have four valid codes that should result in "green"? Or does it require you to send the four character in proper sequence like a pin code?

By the way - you don't seem to like software comments much. How would a reader know what is controlled by your 4 bitmapped signals?

And your "green" function plays with four signals while the "red" function only plays with two. So what about the two signals that is only handled in green_led_on()? When will they ever get another state?