Simple Uart Process

Go To Last Post
20 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have studied about Uart  I would like to discuses about Uart how it works  I am explaining how uart works by a flow chart If you see any error then please give me proper guidance

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In ReadChar() what will you do when an error occurs ? (data overrun, parity)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Significant errors:

 

Same error, actually, for both receive and transmit. You don't want to look at whether transmit and receive are "enabled". Instead, you want to check whether or not there is a character in the receive register. On the transmit side, you want to check whether or not the transmit register is empty.

 

Yes, the enable bits are important, but they don't control going ahead with the receive read or the transmit write.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you read the UART tutorials in the Tutorial Forum?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Have you read the UART tutorials in the Tutorial Forum?

Yes I have been read tutorials Whatever I understood  I made it on paper 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I fear you misunderstood then. When sending the thing you (usually) wait for is the UDRE bit becoming set in the UCSRA register. When receiving it is the RXC bit you are waiting to see set.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

Significant errors:

 

Same error, actually, for both receive and transmit. You don't want to look at whether transmit and receive are "enabled". Instead, you want to check whether or not there is a character in the receive register. On the transmit side, you want to check whether or not the transmit register is empty.

 

Yes, the enable bits are important, but they don't control going ahead with the receive read or the transmit write.

 

Jim

it means when the transmitter register is empty then TXF will enable and when transmitter register is full then TXF will disable 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You keep saying TXF? Can you explain what TXF is? AVRs generally have a status bit called TXC, is that what you are talking about?

 

(and if you are then as I already told you it's more normal to use UDRE not TXC anyway)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
You keep saying TXF? Can you explain what TXF is?

 

I think the OP means to write TXC and RXC, but the datashhet refers to them as "flags" maybe there is some 'confusion' in interpretation?

 

Right Side Jim

 

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

Last Edited: Sat. Apr 4, 2020 - 01:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

You keep saying TXF? Can you explain what TXF is? AVRs generally have a status bit called TXC, is that what you are talking about?

 

(and if you are then as I already told you it's more normal to use UDRE not TXC anyway)

 

My diagram is not related to forum tutorials and I am not talking datasheet of specific AVR micro that's reason I have posted question to general electronics forum. I am referring  TXF as transmitter flag, and RXF as receiver flag 

 

I just wanted to understand basic process of uart and how it works. after reading I drawn diagram and I think that's common for any 8 bit, 16 bit and 32 bit micro 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

ansh11 wrote:
I just wanted to understand basic process of uart and how it works. after reading I drawn diagram and I think that's common for any 8 bit, 16 bit and 32 bit micro 
Yes, and no.  As noted, you do not want to check teh ENABLE bit in each pass of your TX or RX function.  Normally the Receiver and Transmitter are enabled in teh micros init function and left alone after.

 

And not all USARTS are created equally.  There are features in the XMEGA USARTS that are not in the AVR USARTS, and the AVR USARTS have or do not have features that are/are not in the 8051, or Freescale(motorola before they imploded), or NXP.

 

Yes, you certainly can create a generic flowchart(or google an image as they are plenty out there), but read how they work and get a clear understanding.  Take what has been already told to you and rework your drawing, then ask more questions.

 

Keep up the efforts!

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think it's a language thing. When he is "is XXX enable?" I think he really means "is XXX set?"
.
(sure would help to use the real bit names: UDRE and RXC)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

clawson wrote:
(sure would help to use the real bit names: UDRE and RXC)

 

 

Cliff, I think you are missing the OP's point he made in post #10:

ansh11 wrote:

My diagram is not related to forum tutorials and I am not talking datasheet of specific AVR micro that's reason I have posted question to general electronics forum. I am referring  TXF as transmitter flag, and RXF as receiver flag 

 

I just wanted to understand basic process of uart and how it works. after reading I drawn diagram and I think that's common for any 8 bit, 16 bit and 32 bit micro 

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

In any case, what ever you call the status bit, you need to wait until the UART has finished sending the current character before writing a new one. And, on the receive side, you need to wait for a complete character before reading the data register. These fundamental principles do carry across a wide range of micros. Names will vary, but the principles will hold.

 

Now, of course, it gets more complex if there are hardware buffers on either (or both) sides. But, we seem to be talking basic fundamentals, here.

 

It may help to clear some confusion for ansh11 to understand a bit about standard terminology in English. When we use the term "enable", it means approximately to turn something on or off. So, if you talk about the receive half of a UART being enabled, that means that it has been turned on and is able to operate. There are other bits, often called "status" that tell you about current conditions. Was there a proper stop bit? Is parity OK? Has a complete character arrived in the UART? These status bits are controlled by the UART, and NOT by you. There are no standard names for these various status bits, but their functions are standard. That is, no matter what the UART, there WILL be a bit that reports on parity and it will have different names. Likewise, there will be a bit that tells when a complete character has been received, and it will have different names.

 

For ansh11, please! You cannot just make up names for things and expect people to understand what you are talking or writing about, unless you define what those names mean or represent. So far, even with the explanation you have provided, I am still not at all clear what you mean. So, please help us help you.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Sat. Apr 4, 2020 - 05:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

For ansh11, please! You cannot just make up names for things and expect people to understand what you are talking or writing about, unless you define what those names mean or represent. So far, even with the explanation you have provided, I am still not at all clear what you mean. So, please help us help you.

 

Jim

correction 

 

 

 

I have shown my thinking, diagram is better to understand then theoretical explanations   What do you think ? How will you implement work of Uart on paper 

Last Edited: Sat. Apr 4, 2020 - 05:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In the UART transmit flowchart, check "Is TXC set?" before WriteChar().   The UART transmitter is a shift register with a single byte register of storage:UDR.  When the TXC flag is clear, a byte that is written to UDR goes immediately from UDR into the shift register.  This shift reg sends each bit to the TX pin according to the baud rate.  The user can send another byte to UDR and it will be stored there until the first byte is finished transmitting.  Then the second byte is transferred from the UDR to the shift register.

 

If the user sends a third byte to UDR while the UDR is storing the second byte, then this third byte will overwrite the second byte that is being stored in the UDR, and the second byte will never be transmitted.  To keep this from happening, the UART has a TXC (UDR TX is ready for a new data byte) that will be 0 when it's OK to put a new byte into UDR.   Read this TXC bit before writing to the UDR.  If TXC is set, then go back and read it again until it is clear.    TXC will never be set more than 10-12 baud periods, or the time that it takes to transmit one byte and the control/parity bits.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

UDRE not TXC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

The problem I see here is that the OP wants to make a generic flowchart for all microcontrollers, and those posting are pushing the flags/bits pursuant to the AVR line.

 

Either the OP must change their specifications, or the folks posting need to stop trying to change teh OP's spec.

 

The spec is:

ansh11 wrote:
My diagram is not related to forum tutorials and I am not talking datasheet of specific AVR micro that's reason I have posted question to general electronics forum.

ansh11 wrote:
I just wanted to understand basic process of uart and how it works. after reading I drawn diagram and I think that's common for any 8 bit, 16 bit and 32 bit micro 

 

A little bit of Google turned up a flowchart that looks amazingly like the OP's:

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

If you want a generic flow control diagram, you need to (a) use generic control indicator tags and (b) explain what they mean (e.g. TXC is a flag set when the transmit buffer is clear; that is, when a character may be written to it) (TXC is merely a name I chose at random; doesn't mean it exists in any given hardware!).

 

Without that, you end up in the morass you have in this thread, where people are either complaining that the flag you've chosen doesn't exist in a given processor, or that they don't understand what you mean. With it, you have a description of every signal and flag in your system (hypothetical or real).

 

On a basic serial port, you may find that there is no buffer, and you have to write to the output register directly; writing when the 'transmit is happening' flag will garble your transmitted character.

A more complex port may have a one byte buffer which is transferred automatically to the output register as soon as the output register empties, but you may be able to write to both the output register and to the buffer register - in which case, there will be flags to indicate when each is empty. In such a case, you would normally write to the buffer register (unless you have some very specific need not to) - but again you have to watch the flag and only write to the buffer when it is empty. If you don't watch the flag, you won't garble the byte being transmitted, but you will overwrite anything that happens to be in the buffer - i.e. the last character you wrote to it, if it hasn't been transferred to the transmit register.

Going up in complexity, there may be a multi-byte buffer - which acts the same as the last case, but with a more flags - maybe one to say that the buffer is empty, and one to say it has space(s). You might use the first if you're using interrupts and perhaps DMA to drive the port; the latter if you're polling it.

 

As you can see, there are an awful lot of options...

 

Neil

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A problem is that anyone who knows anything about embedded software would never write their code as outlined in the flow charts. A blocking 'UART_readchar' function is a sure fire way to bring your unit to a grinding halt.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."