Leftyretro said:1) Whatever I type there, is it sent serially through the TxD pin of my serial port? So if I type letter 'A', the ASCI binary equavalent will sent serially with start and stop bits?
Yes
2) What if my uC sent the letter 'B' to the RxD pin of the serial port. Would the letter 'B' come up on the screen?
Yes
3) So its not about a special language on Hyperterminal, it is merely to display what is received, and display what is sent?
Correct
3) But who controlls the DTR, DSR, CTS and RTS pin of the serial port?
Hyperterm has properties to set up for utilizing or not utilizing control pins. Hyperterm will act as the DTE end so it will output (if configured to use) the DTR and RTS pins and input the DSR and CTS pins.
If any one knows any links to good beginners tutorials on this, please kindly pass it over.
Google on RS232 tutorials will supply more then enough information such as:
https://www.camiresearch.com/Data_Com_Basics/RS232_standard.html
Many people Don't care much for Hyperterminal, but is does come free with most windows installations. I use a free serial program called Terminal v1.9b by bray, but can't locate a active download site at the moment. There are tons of free serial terminal programs avalible on the web.
Lefty
AceOfHearts said:I am learning about interfacing the 8051 with my laptop.
I have a few questions, and as helpful as you all have always been, I hope you will kindly contribute in clarifying the matters for me.
Just reading up on what Hyperterminal is and what is does. I've managed to open up the blank text window where you can type.
Three questions I have at the moment:
1) Whatever I type there, is it sent serially through the TxD pin of my serial port? So if I type letter 'A', the ASCI binary equavalent will sent serially with start and stop bits?
Yes.
2) What if my uC sent the letter 'B' to the RxD pin of the serial port. Would the letter 'B' come up on the screen?
Yes.
3) So its not about a special language on Hyperterminal, it is merely to display what is received, and display what is sent?
Yes.
3) But who controlls the DTR, DSR, CTS and RTS pin of the serial port?
This depends, on the default setting the 8051 would be required to control them. Most people set flow control to None and just ignore these lines. If you really need flow control then the Xon/Xoff method is easier to implement.
If any one knows any links to good beginners tutorials on this, please kindly pass it over.
Many thanks.
donniedj said:Well known location for communication protocals https://www.beyondlogic.org/
1. Yes, and No. Yes what ever is typed is sent out. But no on start and stop because user may choose to not use stop bits. As long as you send out each character slowly, each will be transmitted one at a time. There are configuration settings that govern how many characters to send you in a packet. Hyperterminal is just a basic interface. A comport driver allow you to do all sorts of configurations and conditions.
2. Yes. If you send 0x41, decimal 65, or A'B' given your uC supports the A(ascii) macro.
3. Mostly true. Most terminal programs support mutiple types of emulators. The emulator will alter the visual effect of text. Yet still, there is no code like C, basic, or java involved.
And I thought I was the first to respond. Seems as if I need to hit "Post Quick Reply" quicker.
donniedj said:1. Yes, and No. Yes what ever is typed is sent out. But no on start and stop because user may choose to not use stop bits. As long as you send out each character slowly, each will be transmitted one at a time. There are configuration settings that govern how many characters to send you in a packet. Hyperterminal is just a basic interface. A comport driver allow you to do all sorts of configurations and conditions.
Pommie said:This is slightly wrong and could confuse people. In Hyperterminal the number of start bits is always one and the number of stop bits is at least one. Sending out character slowly effectively inserts more stop bits. In RS232 terms there is no such thing as a packet everything is just a byte (sometimes 9 bits). You as a programmer may choose to packetise your data but the hardware just sends bytes. Settings in things like MSComm control are PC specific and nothing to do with the RS232 protocol.
Mike.
Pommie said:Would you believe it, the above does not count as a message and so I had to type this to be able to post.
Nigel Goodwin said:Fairly obviously, you're not supposed to type your message inside a quote.
AceOfHearts said:OK,
I tried to send the letter A continuously from the uC and it worked.
But a little confused.
1) I did not have aything like a MAX232 in between. How did it still work? How did the serial port recognise +5 and 0V when according to the text book RS232 logic levels are completely differet?
2) I tried writing (inadvertantly) a letter to the uC and send it back to the laptop, without a MAX232 and it didnt work. I believe my uC did not recognise the voltage levels?
Nigel Goodwin said:RS232 works fine at 0-5V, but you need to be aware that MAX232's etc. invert the signal, so if you're using just TTL levels you have to ensure the signal is the correct polarity. For PIC's this means you can't use the hardware UART, you have to use an inverted software one.
Nigel Goodwin said:RS232 works fine at 0-5V, but you need to be aware that MAX232's etc. invert the signal, so if you're using just TTL levels you have to ensure the signal is the correct polarity. For PIC's this means you can't use the hardware UART, you have to use an inverted software one.
Pommie said:You must be using a software UART that sends and receives inverted signals. I am guessing that the reason it only works from PC to 8051 is because the 8051s outputs cannot drive the line high enough to provide a signal to the PC. Have you got a fairly low pullup on the output of your 8051? I would guess something like 300Ω would be safe.
Mike.
Pommie said:This is slightly wrong and could confuse people. In Hyperterminal the number of start bits is always one and the number of stop bits is at least one. Sending out character slowly effectively inserts more stop bits. In RS232 terms there is no such thing as a packet everything is just a byte (sometimes 9 bits). You as a programmer may choose to packetise your data but the hardware just sends bytes. Settings in things like MSComm control are PC specific and nothing to do with the RS232 protocol.
Mike.
donniedj said:Look who is causing the confusion.
Wrong! - "Sending out characters slowly does not effectively insert more stop bits." This only increases the intercharacter delay.
The World According to Pommie
**broken link removed**
Yes, data being sent and received is transmitted in packets. Chunks is a better description but an inelegant choice of words which may be misunderstood as a result of a failure to handle excess and other words, run on long winded superfluous sentences, and phrases helping not the original questions but intending to yet again show off one attempts to upstage others as a remedy for patching the lack of real world importances in ones existence.
The stream is not perfect and the packets pushed are not logically separated by inserted characters but by time. These packets usually originate from the device side because devices, even though stream their data, do not send the entire buffer inside of one push as a artifact of internal delays and processing time. Even PCs do not push out data in a perfect stream. If you fill a buffer with even a small 50 bytes, the time space between those bytes will not be equal which can be easily seen with a software port monitor residing between two PC's or a physical monitor between a device and a PC. And due this unsymmetrical time space, operating systems perceive the stream in packets. This is why intercharacter delays exist, so to serve as an indicator of when all the data has arrived. This is also why the value of data size are included in the front of the data stream. This is just sooo wrong. If an application uses a DataReceived Event and pulls the data, there is no guaranty that what was pulled is the complete stream. For long data, it may just be the beginning of the stream. Hence the use of data size concatenation in front of stream, and properties like intercharacter delay InbufferCount, and OutbufferCount.
Pommie said:Check the specification for RS232, quote "The start bit has always space value, the stop bit always mark value." There is absolutely no difference between having an intercharacter delay and sending more stop bits.
You are once again confusing PC operation and the RS232 specification. Even MSComm control does not packetise data.
Mike.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?