Sir, I am having trouble in saving the data received from the rxd of 89c52. when i debug the program and i checked the values and changed the SBUF value and on further checking the values of the temp=SBUF the temp value is still on 0.
unsigned char temp; void serial_read() // read byte { while(RI==0); temp=SBUF; RI=0; }
and there is a doubt that if we return the SBUF value this is not working.
unsigned char serial_read() { while(RI==0); return SBUF; }
Thanks in advance.
After reading the datasheet and all the forum posts related to SBUF, I am really amazed to see for all the questions they asked the answer is always the same "check the bible", read the datasheet, etc.. but no one tries to explain what it is and how to solve it. Even after reading the bible and i am not fully satisfied with the explanation, maybe am not able to understand it better, hence we come up with the feature of asking "people who knows it". Even then the answer by them is same. hence altogether -1(doubt) + 1(answered by ppl) = 0 ( no gain) :(
After reading the datasheet and all the forum posts related to SBUF, I am really amazed to see for all the questions they asked the answer is always the same "check the bible", read the datasheet, etc.. but no one tries to explain what it is and how to solve it.
how about this posted 2 posts up: "SBUF is actually two registers on the same address. A read-only register for picking up received data. And a write-only register for sending data. There is no "debugging" step possible to see what you just wrote to the write-only transmit register."
Erik
Thank you Sir, Now i understand it clearly that to check the SBUF data in debugging mode is not possible while receiving. Is there any other method to understand this ? Or this can be sorted out by practical methods(by making circuits and testing). Thanks in advance :)
Now i understand it clearly .... Is there any other method to understand this ?
if you "understand it clearly" why do you need "any other method to understand this "?
Actually i meant is there any other way to know what is happening (in SBUF- using some simulator or some other debugging modes) ? And i hereby do not mean that am fully knowing all the concepts and all the secrets behind it. If you consider it in that way, I am not. I am a beginner :) Hence clearing all the small doubts which i don't understand with the help of scholars like you :) Thank you
vishal
if you can't understand a separate write and a separate read register at the same address, then go find a broom.
I'm pretty sure he has already understood that. The issue now is probably more related to what to do to figure out why the program does not receive any data.
But to help there we need to know lots of things.
Is serial data really sent? At correct baudrate and # of data bits, stop bits? What is sending? Are RX and TX correctly connected to other side - including use of RS-232 transceiver like MAX-232? What clock crystal does the processor have? How is the serial port initialized? ...
I think this post got off on the wrong foot and Per and Erik muddied the waters. What they both posted is true. Both the xmit and the receive SBUF exist at the same SFR address. You can't write to the receive SBUF and you can't read the xmit SBUF.
But the SBUF is very seldom the problem in USART communication. Forget that approach. When you write to the xmit SBUF the data goes out period if you have the clocks enabled, etc.
So the first thing to do is to connect to a terminal such as Hyperterminal and look for data. If you get garbage data or no data you have a place to start debugging. Do you have a scope or logic probe of some type. Take a look a the data lines. Are you getting any signal transmission? Are you getting garbage data out? If so, you probably have a problem with baud rate settings.
The same approach with receive data. Are you getting data on the receive RX pin? Have your buddy punch the 'U' key over and over while you look for signals on the RX pin.
Are you receiving data on the RX pin? Are you using some type of eval board or a target board that you have fabricated? If you are using an eval board have you checked to see if there are jumpers or switches to set?
We could go on and on with this but you need to put a little more effort in asking more direct questions. Not questions like why can't I read the SBUF? Tell us what you have tested and verified.
The Keil examples have a number of good examples for serial UART communications. Have you tried any of the these examples?
From the simulator/debugger you can redirect serial communications out the PC serial port if you have a serial port on you PC. Half my PC no longer have serial ports.
What all this verbage is saying is move on past the SBUF. The chip hardware works. You don't need to trouble shoot the chip. You need to trouble shoot the target board and your software.
Bradford
Per got to the point while I w2as still typing.
:)
Easy to get side stepped there instead of trying to look for progress.
erik This is real discouraging reply. I didnt know help forums like this asks people to "find a broom" when they dont get the answer.
Bradford Thank you sir, that helped me a lot. Actually we are testing it directly with a RF module (315/434 MHz transmitter and receiver) on two separate circuits. And using 89c52 serial communication ports to send data through transmitter (in P3^1) and receive data via receiver (in P3^0). I think the problem is with the baud rates since this module is capable for 300 baudrate operation. And i am using 9600 baudrate.
I didnt know help forums like this asks people to "find a broom" when they dont get the answer. you got the answer from Per Westermark and two posts later you whined "why did I not get an answer" and I had to draw your attention to the answer from Per. If you can not understand the answer, there is none other, then you need go find a broom.
... in English, then please ignore my two posts. and, instead, go bu the rule "more words do not make you appear stupid, they make you appear clear"
The (currenly) last post by you is clear and on a totally different subject to your original post so, if that is what you have tried to get help with why did you not post that clear statement before.
I think the problem is with the baud rates since this module is capable for 300 baudrate operation. And i am using 9600 baudrate.
you should not dont think so, you should know so
is 300bps REALLY all the module can handle
why do you think a module only capable of 300 bps will get any information out of data sent at 9600?