this is my code for serial communication using 8051 iam trying to send letter B on serial port but iam not getting any thig on heperterminal though all setting are ok .so not getting what the problem is.
ORG 000H MOV TMOD,#20H MOV TH1,#0FAH MOV SCON,#50H SETB TR1 MOV A,#'B' ACALL DELAY A_1: MOV SBUF,A H_1: JNB TI, H_1 CLR TI SJMP A_1 DELAY: MOV R0,#255 L1: DJNZ R0,L1 MOV R1,#255 L2: DJNZ R1,L2 RET end
this is my code WRONG!!! NOTHING without comments can be called 'code' what you show is 'scribbles'.
Anyhow one of the problems you have is that you are not aware of how TI works, you mix 'knowledge' of interrupt driven UART in with your polled routine.
read up on the UART in 'the bible"
another issue is that a timer does not drive the UART if it is not running.
read up on the timers in 'the bible"
Erik
here are the links to "the bible" Chapter 1 - 80C51 Family Architecture: www.nxp.com/.../80C51_FAM_ARCH_1.pdf
Chapter 2 - 80C51 Family Programmer’s Guide and Instruction Set: www.nxp.com/.../80C51_FAM_PROG_GUIDE_1.pdf
Chapter 3 - 80C51 Family Hardware Description: www.nxp.com/.../80C51_FAM_HARDWARE_1.pdf
WRONG!!! NOTHING without comments can be called 'code'
void main(void) { printf("No comments, but action is obvious?\n"); }
Another silly statement
That's not even code. I'd call it pseudo-code pretending to be C.
Obvious ? Where's your printf going to ? UART ? Screen ? Some other interface ? How is anyone supposed to know ? Where's your printf coming from ? A library ? Did you roll your own ?
"Did you roll your own ?"
I don't indulge in such disgusting habits!
extern void My_Function_To_Send_String_To_Uart_At_9600_Baud(char *); void main(void) { My_Function_To_Send_String_To_Uart_At_9600_Baud("No comments, but action is obvious?\n"); }
Why you Need Comments What Micro ? Not all 8052's are the same. What Crystal. That determines the baud Rate. What baud Rate? You comments should say maybe your math is wrong.
baud Rate
Baud is a rate.
Although it is a common term, it is a silly term.
Like:
PIN number LCD display AC current
etc
A good engineer should really know this.
An even better engineer might even be able to get some work done without being bothered by people using there terms.
Hmmm ... So you might as well say, "whatever you do, and however you do your coding, it's OK with me"
A better engineer still, would take the time to teach their team to use good practices and terms in the first place!
Such an eengineer is likely to have to spend a significant amount of time explainging why data sheets, product overviews etc are using the above constructs. Thereby, such an engineer will have a hard time actually engineering.
"Such an eengineer is likely to have to spend a significant amount of time explainging why data sheets, product overviews etc are using the above constructs."
That is a false assumption - Re: likely, significant
"Thereby, such an engineer will have a hard time actually engineering."
Therefore, this is a false conclusion.
Training on such details should normally be done when the team is initially built - It should not be needed latterly.
A common word for this is induction.
You can only call an assumption false if you have the proof.
Without proof, you can only claim it to be an unlikely assumption.
Point taken - But there again, you can only claim a statement is true if you have the proof. Until that time it is a theory.
I think you're assumption is incorrect.
My reason - In our team, we DO have induction courses that show how documents, code (and comments) are expected to be done.
In general, team members DO follow the guidelines.
One very important rule we follow is: It is not so important which style the team use, but it is important that everyone is consistent.
"...you can only claim a statement is true if you have the proof. Until that time it is a theory."
Point taken, but that is why i wrote "Such an eengineer is likely to have to spend a significant amount..." Clumsilly, I unintentionally managed to loose the "likely" word in my second sentence.
In Sweden, it is very, very common to talk about an IC circuit. I have at a number of times responded with "Oh, you mean an IC?" just to either see a deer in the headlight, or hear a "yeah". A couple of minutes later, that same "IC circuit" phrase is used again.
Because of this, I have a lot of indication that it is very hard to break bad habits. Upgrading corrections from hints to company policy would be thought of as putting the energy at the wrong things. An R&D unit is better off making sure that the code is testable, maintainable, matching the customer requirements, ...
So, a good engineer can find a large number of areas where the pay-off is better.
"I think you're (sic) assumption is incorrect."
Clearly your induction classes don't include the proper use of apostrophe's (sic)...
;-)