I have no idea how uart communication happen between two microcontrollers.I need to clear some of my points that I do not understand.

Lets assuming we have two microcontrollers and each has UART inbuilt in both microcontrollers



This is generic process of UART communication.

UART hardware set up. 6900 8N1



What happens when UART of MCU 1 send first start bit to UART of MCU 2?

It seems to me that the first MCU generates one signal which enables the UART of second MCU like if there are two houses somewhere and the person of the first house sends his house servant to the second house and opens his gate

 

hi Dj,
Check out this AAC link for a UART tutorial.
https://www.allaboutcircuits.com/te...ersal-asynchronous-receiver-transmitter-uart/

E

 

This application note is old,but still applicable: http://ww1.microchip.com/downloads/en/Appnotes/00555c.pdf

Here's the PowerPoint version: http://ww1.microchip.com/downloads/en/devicedoc/usart.pdf

 

hi D,
I would suggest you don't see the Start Bit as a Lock, it is 'seen' by the receiving UART as an Enable signal Level.
After being Enabled the receiving UART expects the remainder of the Data Byte to be transmitted, ending with a Stop Bit Level.
E

 

Which MCU are you using? In PIC's, the UART (USART/EUSART) hardware is enabled in code. The start bit allows the enabled receiver to recognize the beginning of a transmission. I suspect it is similar in other devices.

 

Since the serial interface was relatively universal to talk to "dumb terminals" and later "smart terminals".

At work we had an HP85/HP86 computer. It pre-dates the IBM PC and even networking as we know it now. That computer used IEEE-488 or the HPIB bus to interface with external disk drives and instrumentation.

Computers with the S-100 bus came along and you needed to transfer files between this difference in hardware. You did it with modems and a serial port on each end. The protocal/program Kermit was available on multiple platforms to transfer binary files between them.

So, you used a free serial port and a modem as well as a modem and free serial port on the other side.

This is one of the first "high level" UART applications. One of the MAJOR differences between a lot of machines at the time is what was a line. You might have the "newline' character, a carriage return or a carriage return line feed combination

You would effectively send printable characters, could be HEX digits with the other machine's terminator. You would create a checksum and each line would be acknowledged as correctly or incorrectly transmitted.

You could turn off echo. You sometimes needed time for a carriage to return or a line to advance on a mechanical device, so nulls were used. A character 0. A character 0 is valid in a binary file.

For non-binary files, usually you would do terminator conversions. e.g. Macintosh, Unix and the IBM PC used different terminators for say a TXT file.

That probably isn't what your asking.

Even with UART communication, Baud, the number of stop bits 1, 1.5 and 2, parity (odd, even or none) have to be known ahead of time. Slower stuff needed 2 stop bits. Like the ASR33 teletype at 110 baud or close to 11 characters/s. Not really, because every character needed 11 bits.

There was one bizzare rate of 134.5 baud for IBM selectric typwriter terminals. See: https://en.wikipedia.org/wiki/IBM_Selectric_typewriter

The start bit starts the clock for the bits of the character or "byte". You signalled the end with a stop bit. Motors needed more time to stop, so sometimes two stop bits were used.

 

The UART on the receiving end must be enabled by software on the receiving microcontroller Once that is done, it watches the input, waiting to see it go low. This happens independent of the program running at the time, it just goes on as normal.

The UART hardware then samples the line at the baud rate, collecting the 8 bits that make ip the character received.

When the character has been received, it sets a flag that can be tested by the program, or, more commonly, causes an interrupt. The character is then pulled out of the UART by the program.

Meanwhile, the hardware may be receiving the next character. It will typically have at least one, and sometimes more buffers so that it can receive even before the program reacts to the previous one.

Hope this helps.

Bob

 

hi D,
I would suggest you don't see the Start Bit as a Lock, it is 'seen' by the receiving UART as an Enable signal Level.
After being Enabled the receiving UART expects the remainder of the Data Byte to be transmitted, ending with a Stop Bit Level.
E

As much as I know any microcontroller is a programmable device and we have to configure it to use its peripheral If we have to use the UART of the microcontroller then we configure it in code as baud rate , data bit , parity bit, stop bit etc

So for the first microcontroller , we write the instruction we say it code in which it is written that how UART communication will happen

This means that we write one code in which first we send a start bit, after that we send the data byte and a stop bit.

This means that the software program will enable/disabled the hardware of another UART. In my case I have to write a program for first microcontroller that enables a/ disables the UART of the second microcontroller.

 

hi,
When using MCU's as shown in your drawing, both MCU.s have UART software routines written to Enable them to communicate with each other.

So when MCU #1 sends the Start Bit MCU #2 senses the RXD pin and it expects the Data Byte and Stop Bit.
This Data is stored in MCU #2 RX register, another section of the MCU #2 software program then processes the Data Byte.

MCU #2 can then send a Start Bit to MCU #2 and transfer a Data Byte from #2 to #1.

Is this what you are asking.?
E

 

It may be a semantic problem, but I think you are looking at it wrongly. The UART on the receiving end must be enabled (by the receiving micro) before a character is sent on the other micro. It will be enabled and waiting for a start bit. If it is not already enabled, the character is lost.

Bob

 

Start bit, stop bit, etc. are included in the hardware protocol.
In a practical sense you can ignore all of this.
You configure both computers with the same protocol, for example, 9600b, 8N1, Flow Control = NONE.

MCU #1 sends a byte from TX to MCU #2 RX.

As simple as that.

 

I am reminded of one of my mentors who opined that: "Any sufficiently advanced technology is indistinguishable from magic". I'm pretty sure that was not an original thought on his part. but seems apropos.

 

Is this what you are asking.?
E

Exactly your answer has answered my question. Now I understand what happens Like suppose I have to transfer one byte data from MCU #1 to MCU #2 via UART Protocol.



MCU #1 send start bit to MCU #2 then send one byte data and then send stop bit to MCU #2

 

Protocol means an agreement. TX and RX both agree that this is how the data will be transmitted.
UART protocol is already done for you in hardware.
You do not have to worry about sending START and STOP bit.

Send 8-bit byte and 8 bits will be sent from TX to RX.

Here is the pseudo-code using flag polling.

TX send:
wait for TX not busy
send byte

RX receive:
wait for data available
read byte

 

hi Dj,

 

The hardware takes care of sending multiple characters for you. It performs all the necessary timing. If you need to know the time per character, you have all the information you need. The speed specifies the number of bits transferred per second. And one character is 10 bits, typically. 8 data bits, 1 start bit and 1 stop bit.

As far as confirming that the data is received, you can do that in software. Once a character or string of characters are received - send something back to the transmitter acknowledging receipt.

 

TX sends one character. TX does not know that the character was received. TX has to assume that the character was received.

9600 baud is slow by today's standard. At 9600 baud, it takes 1ms to send one character.
I can communicate between two MCUs at 500,000 baud with no problem.

Typically, you send n-characters at whatever baud in burst mode. You have to assume (by design) that the RX can handle n-characters without failure. I can send 1,000 characters all at once without missing a beat. At 500,000 baud, it would take 20ms to send 1,000 characters.

Usually, the protocol works likes this.
MCU#1 asks MCU#2 for 1,000 characters.
MCU#2 sends 1,000 characters. MCU#2 ends sending and waits for the next request.
MCU#1 reads in all 1,000 characters, process and analyze, and goes to the next process.

 

From a Microchip datasheet:



A flag bit is just that. It is a message that a character has been received. If interrupts are enabled, then there is also an interrupt, but you can leave interrupts disabled and monitor ("poll") the flag bit. Very important: The receive buffer is only big enough for two bytes. More than that, you get an overflow error.

With PIC's, you clear that flag by reading the receiver RCREG (FIFO) buffer. You cannot clear it in code like you can clear many other flag bits. You do not know how many bytes have been received. For example, if for some reason your polling is slow or the interrupt is delayed (unlikely, unless you have them turned off for a period), there will be two bytes in that buffer. Reading just one byte will not clear it. Thus, you have some options:
1) Read and check the flag. Keep re-reading until the flag clears.
2) Always read twice.

 

By the way? What MCU are you using? And what programming language?

In some cases, these details are taken care in the program compiler. We don’t know what you’re using, so some answers may not be applicable.

 

A flag is your basic hand-shake mechanism.

You place food into your microwave oven and you press START.
You don't know when it is cooked.
You cannot put another dish into the oven because it is already full.
You wait for the "beep" to go off. This is your "flag".
The flag tells you that your food is ready.

You are waiting for a parcel to be delivered to your house.
You keep checking through your window looking for the delivery truck. You don't see any truck.
So you just sit and read a book.
The doorbell rings. The delivery man is here. That is your "flag" to tell you your parcel has arrived.