Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

New to serial communication, Hyperterminal?

Status
Not open for further replies.

AceOfHearts

New Member
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 be sent serially with start and stop bits?

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?

3) So its not about a special language on Hyperterminal, it is merely to display what is received, and display what is sent?

3) But who controlls the DTR, DSR, CTS and RTS pin of the serial port?

If any one knows any links to good beginners tutorials on this, please kindly pass it over.

Many thanks.
 
Last edited:
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
 
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

Many thanks for your contribution. I appreciate it very much. I will hopefully get something programmed into my 8051 tommorrow and check out if I can get anything communicating with my laptop tommorrow.

:)
 
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.

Would you believe it, the above does not count as a message and so I had to type this to be able to post.

Mike.
 
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:
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.

Ok thanks for that!

I am sure I will have more questions soon, just as soon as I get some hands on experience going!
 
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.

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:
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.

"Slightly wrong"

You sir are are a gentleman ;)

Lefty
 
Nigel Goodwin said:
Fairly obviously, you're not supposed to type your message inside a quote.

Your right, it is fairly obvious :eek: . Next time I'll delete the quote tags.

Mike.
 
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?

thanks.
 
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?

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.

Unless you are using some of the newer pics that have the ability to use inverted signals. A very useful feature. See the 18F2550 data sheet for more details.

Mike.
 
Thanks for the posts.

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.


Sorry, being very new to Serial comms, I am kind of confused now.

Ok let me get this streight! I was able to send letter 'A's, which meant RS232 port CAN READ 0-5V as logic 0 and logic 1 respectively.

HOWEVER,

RS232 port outputs (according to my textbook) -3V to -25V as logic 1 and 3V to 25V as logic 0, which my uC (8051) wont understand.

So the reason why a Maxim chip is necessary is so that my uC can understand the signal from the serial port, and not for my laptop to understand my uC?.........

thanks.
 
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:
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.

You got it the other way round, I can send 'A's from my 8051 uC to the laptop, but not from the laptop to the 8051 uC (unless something is wrong with my code for the latter).

My curiosity was of the fact that I did not need a Maxim chip in order to send from 8051 uC to the laptop, yet seem to require it to send from laptop to 8051 uC.

thanks for your help. :)
 
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.

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. 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.
 
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.

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.
 
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.

Again you are correct.

RS232 is just a hardware serial interface standard. How many characters, how few, how lumped or chunked or packetized is strickly a function of the application software and has no relationship or is even specified in the orginal RS-232C standard. It was designed as a character based digital communications standard, with no predefined minimum or maxium block size.

This standard was first used with ASCII Teletype machines in the 60s where people would type at the keyboard and send the characters one at a time to the recieving teletype at whatever speed the operator could handle up to the limit of the machine, usually around 100 words per mins (yes mins!) One could also send via a pre-punched paper tape message that someone typed ahead of time. Later video terminals started to utilize the standard to hook to modems for communicating with central time sharing computers.

The RS-232 standard predates the introduction of microcomputer or PC computers and was used for many forms of early digital communications used by the telecommunications companies and well as the military.

I don't even think the 'standard baud rates' (...2400,4800,9600,etc) used is defined in the standard and one is still within the standard to send at a 1,111 baud rate and not violate the standard. Of course the recieving end has to be configured to expect this odd ball baud rate.



Lefty
 
When I type something into Hyperterminal, it should come up on the screen and be transmitted right?

But how come nothing happens when I press a key (I am checking using an oscilloscope the serial port output). Nothing comes up on the screen, nor is anything transmitted through the port?? :confused:
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top