Issue Regarding Start and Stop bits during serial communication

[snel]

Hi Members,

I have an issue.
Consider the case of transmitting a value serially (for e.g. 10010010) via Tx of 8051 in mode 1.

Now as per the theories, the transmission begins with a start bit ( which logic 0), then the rest of the data bits and ends with a stop bit ( which logic 1)


Now my question is while transmitting how does 8051 (or any controller) figures out that the first 0/last 1 are start bit/end bit and not a data bit.


Any suggestion or links are welcome.
Thanks in advance

 

[lunatik96]

Hi Members,

I have an issue.
Consider the case of transmitting a value serially (for e.g. 10010010) via Tx of 8051 in mode 1.

Now as per the theories, the transmission begins with a start bit ( which logic 0), then the rest of the data bits and ends with a stop bit ( which logic 1)


Now my question is while transmitting how does 8051 (or any controller) figures out that the first 0/last 1 are start bit/end bit and not a data bit.


Any suggestion or links are welcome.
Thanks in advance

Vaguely recall the 8051C;
What most people think as serial transmission is actually called baud, which for simplicity purposes we will say is a change in bit value. bps and baud are not exactly the same thing but for any but the most technical discussion they are interchangeable. The main thing to understand is that for async comms is that each character is transmitted individually. So the line is silent (not really but for our purposes) then we get a 0 (start of transmission) then the data and then the 1 held for stop. This is understood as the speed of transmission is already established and so many bits are due. Long ago there used to be 2 stop bits as a signal, but that was when data was still binary. Due to hysteresis effects, the number of changes are limited. The hardware/ software combination figures this out and translates the transmission to binary data.

I suspect you are really interested in programming your micro-controller. In that case the serial port communicates to a modulation/ demodulation (modem) device. The modulation device converts binary to baud and back. You just need to read/ write to the port data register timely. There are many specialized chips to do this. If you are really interested (and don't fall asleep easily) then you can search for baud and try to understand the mechanisms involved.

In synchronous transmissions, the speed is set and then blocks of data are sent and at the end, the block has error checking and correcting block data checks. It is more efficient for more constant comms, but typing is always async due to irregularity in speed.

 

[snel]

Vaguely recall the 8051C;
What most people think as serial transmission is actually called baud, which for simplicity purposes we will say is a change in bit value. bps and baud are not exactly the same thing but for any but the most technical discussion they are interchangeable. The main thing to understand is that for async comms is that each character is transmitted individually. So the line is silent (not really but for our purposes) then we get a 0 (start of transmission) then the data and then the 1 held for stop. This is understood as the speed of transmission is already established and so many bits are due. Long ago there used to be 2 stop bits as a signal, but that was when data was still binary. Due to hysteresis effects, the number of changes are limited. The hardware/ software combination figures this out and translates the transmission to binary data.

I suspect you are really interested in programming your micro-controller. In that case the serial port communicates to a modulation/ demodulation (modem) device. The modulation device converts binary to baud and back. You just need to read/ write to the port data register timely. There are many specialized chips to do this. If you are really interested (and don't fall asleep easily) then you can search for baud and try to understand the mechanisms involved.

In synchronous transmissions, the speed is set and then blocks of data are sent and at the end, the block has error checking and correcting block data checks. It is more efficient for more constant comms, but typing is always async due to irregularity in speed.

Well, I appreciate the descriptive answer provided.

Thanks so much for bringing to light certain points that i was not aware of.
Let me explore a bit more on these points as suggested by you.

 

[andre_luis]

snel,


Despite UART transmission is categorized as asynchronous, the sensing of each byte is synched with falling edge of first bit, an all further bits are read at middle of its level.


+++

 

[snel]

snel,


Despite UART transmission is categorized as asynchronous, the sensing of each byte is synched with falling edge of first bit, an all further bits are read at middle of its level.


+++

Thanks andre for the valuable suggestion.
It got me to understand the concept better.

- - - Updated - - -

However,

I have one more serial programming issue, that seems quite challenging to me.

I have to write a program for 8051. The program has to pass a value serially.
This program will be used to send command to a Robot to control its movements.
( This value could be like MOV-LEFT60-CAPTAIN or MOV-RIGHT40-CAPTAIN or MOV-BACK20-CAPTAIN)

Now for this, my program could be divided into three section.
Section 1) to send MOV- values serially by using an array (since hese values would always be fixed/hardcoded).
Section 2) To send these dynamic values LEFT60/RIGHT40/BACK20 serially based on user requirement.
Section 3) to send -CAPTAIN values serially by using an array (since these values would always be fixed/hardcoded).



So now the issues comes in Section2. Since section 2 is completely dynamic and is based on users wish for controlling the movement of robot.

So there must be some way for for 8051 to check Rx pin for the last character.
Consider a case of LEFT60
So how the controller knows that there is nothing after 0and it should break the loop.

(I mean how to write a logic to wait for half a second or some miliseconds after transferring the last character.
If a character is not received at Rx for half a seconds the loop should itself break out and proceed to section 3.)


I have writte a code below in which section 1 is complete but i am not able to come out of section 2 based on the last character recieved at Rx.
Section 3 is not yet mentioned in my program.


#include <reg51.h>

void SerTx (unsigned char);
void SerRx (unsigned char *);

void main (void)
{
char byteBuf;
unsigned char z ;
unsigned char y ;
int flag=0; // making the initial value of flag to 0
code unsigned char atxb[]="MOV-";

TMOD = 0x20; //Timer 1, 8 bit auto reload
TH1 = 0XFD; // or: TH1 = -3, 9600 baud
SCON = 0x50;
TR1 = 1; //start timer

while(1)
{
while (flag==0) //checkin the condition based on flag
{
for (z=0;z<=3;z++)
{
y=atxb[z];
SerTx;
}
flag=1; // changing the flag value to break the loop
}
while (flag==1)
{
SerRx(&byteBuf); // read byte from serial port
SerTx(byteBuf); // send byte back to serial port
}
}
}

void SerTx(unsigned char x)
{
SBUF = x; // put the char in SBUF register
while(TI==0); // wait until transmitted
TI = 0;
}

void SerRx(unsigned char *pX)
{
while(RI==0); // wait until received
RI = 0;
*pX = SBUF; // copy the data in SBUF to px
}


Please let me know the modification that i should make in the code to come out of the second while loop if the last character has been received at the Rx.

 

[betwixt]

There are several methods you can use:
1. send an 'end of transmission' marker. This is often a CR character.
2. if you know the number of characters arriving, just count them and stop when the last has arrived.
3. use the delay after the last character and before the next command to 'time out' the data, marking the end of command.

Method 1 is most commonly used, often you don't see it on a serial monitor because it's not a displayable character.

Brian.