## Could you help me to understand datasheet of ATmega 328 Atmel

32 posts / 0 new
Author
Message

I have come across datasheet of ATmega 328 atmel. I want to understand the usart features of this microcontroller and how it works.usart detailed exploration is given in page number 225.

Lets suppose I want to send n characters from atmega to computer at speeds of 1 ms

So how do I have to configure the usart so that I get 1 millisecond speed ?

## Attachment(s):

Hello -

First serial data rate is not measures in milliseconds. It is measured in baud. Standard values include 1200 baud, 2400 baud, 4800 baud, and so forth. A baud rate of 9600 baud will send a standard 8 bit character with no parity and 1 stop bit in slightly longer than 1ms.

Perhaps I should add that, in this context, 1 baud = 1 bit per second. So 9600 baud is 9600 bits per second. An 8-bit character with one stop bit and no parity has 10 bits (that includes the start bit). So with that kind of data, 9600 baud is 960 characters per second. That means that one character takes 1/960 seconds = 1.04ms.

The data sheet has a table in the UART section that lists register settings for various baud rates with different MCU clock frequencies. THAT is what you need to look at.

Cheers

Jim

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

Last Edited: Fri. Jul 31, 2020 - 04:53 AM

Here is a nice link..there are also some rather basic codes given to config the uart (you can use equiv ccode to similarly set your registers).

http://www.avrbeginners.net/    click on AVR ARCHITECHTURE & then click on UART

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Jim thank you

Given in datasheet

1 start bit
5, 6, 7, 8 or 9 bits
No, even Or odd parity bit
1 or 2 stop bits

As I have seen everywhere we mostly send 8 data bits but as given 5, 6, 7, 8 or 9 bits what does it means ? Does this mean that I can send 5, 6 ,7, 8 or 9 bits data to Computer or I can only send 8 bit data to computer

Last Edited: Fri. Jul 31, 2020 - 05:35 AM

One of the programs I use on a host (desktop) computer allows data bits 5, 6, 7, or 8 (but not 9). The choices depend on what both sides of the UART (serial) connection can do; eight is common.

my projects: https://github.com/epccs

Debugging is harder than programming - don’t write code you can’t debug! https://www.avrfreaks.net/forum/help-it-doesnt-work

It means you can send 7, 8, 9, or more bits to a computer, provided that's what the computer is expecting. But you can send *only* what it is expecting. If it wants 8 bits, you must send 8 bits. If it wants parity, you must send the parity bit (or not if it doesn't) and it must be the right sign - positive or negative. You must send at least as many stop bits as the receiver is expecting - though since the stop bit is the same signal level as sending a gap between characters, you can send more.

The receiver waits for the low-going start bit which it tests is of sufficient length. If it's not, it's considered noise and waits for the next one. Having found something that looks like a start bit, it waits for one bit period and then samples what should be a bit - and it assumes it is. It samples the next n - 1 samples, where n is the number of bits it is expecting to receive (not necessarily what is being sent!). If a parity bit is expected, it samples that, and in either case then takes a final sample of the stop bit, which must be high. It then waits until the number of stop bits should have ended and then starts looking for a start bit again.

Simple. What could possibly go wrong?

• Baud rate - if you have the wrong baud rate then there is obviously no way in which what you're sending and what the receiver is expecting can match up. You may get odd bursts when it detects what looks like a start bit, but what happens thereafter is all a bit theoretical. It certainly won't be what you expect and you may cause errors in the receiver - more below.
• Synchronisation - the system is designed to be asynchronous: you can have an indeterminate gap between characters provided (a) that the signal is kept high at the 'stop bit' level and (b) that it lasts at least as long as the number of stop bits the receiver is expecting. If the gap is too short, the receiver may not see the start bit and may interpret instead the first zero in the signal as the start of a character. It isn't, and that can cause receiver errors too.
• Accuracy - because there is no bit-by-bit timing pulse, the sender and the receiver both have to assume that the other is operating at the same speed they are. If a clock at the sender is over five percent slow, relative to the receiver, as the receiver samples each bit in where it thinks the middle is, it will end up sampling earlier and earlier in each bit until it takes two samples in the last bit, instead of one there and one in the stop bit. Similarly if the sender is fast, the receiver samples later and later in each bit until a bit is missed entirely. In either case there's a fifty percent chance - but not a guarantee - that you will trigger a framing error at the receiver.
• Noise - a spike of noise can cause a bit to be received other than as its actual value. Most receivers run a 'best of three' scheme these days and take multiple samples to reduce the chance of this happening, but it's possible. The obvious way to resolve, or at least reduce, this problem, is to transmit a parity bit. This ensures that an error in any single bit or in the parity bit itself is observed by the receiver, which triggers a parity error. However, it's by no means foolproof (e.g. an even number of errors don't show!) and it requires a higher level protocol by which the receiver can ask the sender to try again. It also depends on the receiver expecting to receive parity data - which is implicit where the protocol exists, but not otherwise: you can't just add parity to the transmitted signal and expect to improve matters.

This protocol was designed to be used in conditions where conditions were noisy, where the transmission path was not too far, and where processors and therefore data handling were significantly slower than currently available. Often, there would be further wires which would control which end could to talk to the other and when it could do it: Hey, I've got some data - you ready for it? Nah, wait one, ok, go ahead... Here it comes! Whoa, stop a moment, buffer is full, I'll tell you when you can continue... and so on. This is much more complex than what is usually done these days, but was very robust.

These days: almost every signal uses only the transmit, receive, and a common ground line. Most use simple TTL logic levels (at 5v or 3v3 or less) rather than RS232 levels (inverted, and higher voltage) or differential signalling. Eight bit, no parity, one stop bit (8-n-1) is almost universal and in most cases at standard rates: 9600 baud or 11520 baud. That's what you should probably start with.

Neil

(as an example of an oddball system I have an ECU which listens for a 5-baud 'wake up' signal and then expects data at 7812.5 baud. Why? It's an exact submultiple of the 4MHz system crystal...

In the datasheet shown , Transmitter buffer can only be written when the UDRE0 flag in UCSR0A register is set.

What happens when UDREO flag is not set ? Can we still load data in transmitter register. When is the flag set and when does this flag not set?

Last Edited: Fri. Jul 31, 2020 - 07:35 AM

Why did you waste bandwidth just copying Neil's post??

The first port of call should be Google. This will probably send you to wikipedia. That will explain the basics. Then you can make better sense of the information provided.

Top Tips:

1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...

I was trying to reply. I was editing my post till then you posted your comment.
I have noticed here that I am not able to access the entire website in mobile. If I am also attaching an image from mobile then it is not showing it, only the file is visible

You can write the transmit buffer at any time, however if you want the expected results, then you pay attention to the status bits. The datasheet explains how the bits work. Spend some time to understand the datasheet.

Djsarkar wrote:
I am not able to access the entire website in mobile.

Yes, you are - you have to get your browser to request the desktop site.

But, clearly, viewing the desktop site on a small mobile screen is never going to be a great experience!

Top Tips:

1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...

Djsarkar wrote:
Lets suppose I want to send n characters from atmega to computer at speeds of 1 ms
Where does 1ms come from?

The fact is that serial is timed by a "baud rate" and historically these are generally a multiple of 300 like 300, 600, 120, 2400, 9600, 14400, 19,200, 28,800, 38,400 etc

These days most people choose to use UART with 8 bits, 1 stop bit and no parity. So to send a "character" you need to transmit 10 bits. If your rate was really "1ms" then that would suggest 10,000 bits per second.

But 10,000 is not a common baud rate (quite possible the "other end" won't allow you to select 10,000 baud as an option). So you would probably pick something like 9600, 14400 or 19200 baud.

If you picked one of those your character rate (assuming 11 bits per character) would be 9600 = 1.04ms/character, 14400 = 0.69 ms/character, 19,200 = 0.52 ms/character.

So no, I wouldn't aim for 1ms. I'd pick a common baud rate that would put you somewhere close.

Let assume that the uart transmitter has a buffer register and flag. Whatever byte we have to send, we store the byte in this register. We cannot store the next byte until the previous has transferred.

How does it know, data load in the register has been transferred or not?

Does the flag indicate that the data is loaded in the register?

I want to understand what happens when flag is set? What happens when flag is not set? Is the flag set automatically and cleared automatically?

But from the version you linked the info. you ask for is in section  24.7.3. (232-233).

There are two transmit flags, one say that the transmission has STARTED and you can write a new char. (that way there will be no delay between multi char's).

And the other flag indicate that the transmission is DONE , this is probably not what you want (Mostly used when you also control a direction driver)

sparrow2 wrote:

Absolutely!

Always go to the manufacturer's website first for documentation - 3rd-party sites are often out-of-date, may be incomplete, etc.

https://www.avrfreaks.net/commen...

https://www.avrfreaks.net/commen...

Top Tips:

1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...

These are some questions i don't understand in new datasheet

what happens when flag is set?
What happens when flag is not set?
Is the flag set automatically and cleared automatically?
When does the flag set?
When does the flag not set?

But, surely, all those questions are answered in the datasheet?!

Top Tips:

1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...

The new datasheet say :

The Data Register Empty (UDRE) Flag indicates whether the transmit buffer is ready to receive new data. This bit is set when the transmit buffer is empty, and cleared when the transmit buffer contains data to be transmitted that has not yet been moved into the Shift Register.

So what is the real question ?

Djsarkar wrote:

These are some questions i don't understand in new datasheet

what happens when flag is set? Nothing until you or an interrupt acts upon it
What happens when flag is not set? Is this one of those philiosophical questions like "if a tree falls in a forest and no one is there to hear it, does it make a noise?
Is the flag set automatically and cleared automatically? It is set and cleared exactly as the datasheet tells you it is - so set once the UDR is no longer active and it's safe to write to, cleared while UART is consuming last byte written to UDR
When does the flag set? When the UDR is clear for writing and not currently involved in transmission
When does the flag not set? UDRE0 is not asserted while the most recently written byte is being transferred to the transmission holding register

Can't help wondering if you are maybe over-thinking this a bit. The situation is that once you have written to UDR there is a short period of time while that byte in UDR is "being used" and you can't write immediately as you would interrupt/corrupt things. So the UART helpfully holds a flag for you to say "OK to write". It is actually called UDRE ("UDR is Empty"). When the byte has moved on its journey and it's now safe for you to write another the UART helpfully clears the flag. So your typical transmit byte routines is going to look something like:

void UART_send(char byte) {
while (!(UCRSR0A & (1 << UDRE0)));
UDR0 = byte;
}

If you now call:

UART_send('O');
UART_send('K');

then the first call will likely find that the UDR register is empty so it won't even wait at the while() loop but will go immediately on to write 'O' to UDR0. But as the second call to send 'K' is made it's going to get there while the 'O' is still in the process of being consumed/sent. So the UART will have lowered UDRE0 and the while() loop will wait a while (maybe 500us or whatever is left in the sending time). When the 'O' has gone on its way the UART will raise UDRE0 to say "OK to write now" and the while() wait loop will end and the 'K' can now be written.

It really is not complex!

Last Edited: Fri. Jul 31, 2020 - 02:38 PM

Thank you very much

frame formats:

• 1 start bit
• 8, data bits
• even or odd parity bit
• 1 stop bits

What is use of parity bit ?

I found that parity bit is use to detect error But it is not clear in datasheet how parity bit detects error.

Any help
.

Last Edited: Sat. Aug 1, 2020 - 08:46 PM

? What is it that isen't clear?

And detect:

sparrow2 wrote:

? What is it that isen't clear?

And detect:

Even after reading the whole section, I do not understand how parity bits detect error.

Djsarkar wrote:

Even after reading the whole section, I do not understand how parity bits detect error.

It simple, really, when using Even Parity, the number of 1 bits in the character must be an even number(0,2,4,6,8), if it is not then an error has occurred,

the same works for Odd Parity, if the number of 1 bits in the character is not an odd number(1,3,5,7), an error has occurred in the exchange.

Odd/Even Parity is a simple, but not fool proof way to detect errors during the exchange of info.

You really should search out the wiki page on Async serial communications, as these are basic concepts and not specific to any micro.

Jim

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

Last Edited: Sat. Aug 1, 2020 - 09:35 PM

You don't *need* to understand it, so long as both ends are set to the same configuration. Unless you actually want to write a serial comms driver or library.

8N1 (8 bits, no parity, 1 stop bit) is a very common config. Why no parity ? Because most short serial links are so reliable that error detection is an unnecessary overhead.

Try this: https://en.wikipedia.org/wiki/Pa...

Last Edited: Sat. Aug 1, 2020 - 09:37 PM

In my book, the ONLY thing you need to know about parity is: What parity setting is being used at the other end of the link?

Once you know the answer, use the same setting at your end.

End of question...

Now, if YOU control both ends and want to know what parity you should use, the answer depends on the link error rate. If it is close to zero (as might be the case with serial over a USB channel), then choose NONE. That will save you one bit per character, which will make things go about 10% faster, and use less power (in many applications). If the link error rate is high enough, simply choose, arbitrarily, EVEN or ODD (one or the other). They are equally good (or bad) at error detection. Be aware that if the error rate is too high (as in the case of cheap 430MHz wireless modules), parity will NOT catch all the errors.

If you use parity to catch possible link errors, you need to know that YOU (that is, your code) has to check the parity on every character. Then, you have the question of what to do with the error. A common strategy is to request that the message be sent again.

Jim

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

Parity lets you detect an error in a single bit of either the transmitted byte or the parity bit (which is part of the calculation). An error in two bits won't be detected since the parity will then be the same. (And the same logic continues - it will detect errors in an odd number of bit and fail to detect errors in an even number of bits).

Whether you should use it or not depends a lot on the error rate you expect and the error rate you can tolerate, and to some extent on the type of noise that you expect to interfere.

• If the receiver expects a parity bit, send one. It won't work without it in that case, even though there may not be a protocol to handle any errors.
• If the transmission path is short and clean - e.g. between two chips on the same board at logic level, or between two physically close devices using RS232 level signals, you probably don't need to bother.
• If you can expect noise on the signal path, then what you need to do depends on your signal...
• if you can tolerate occasional incorrect bits, accept it. That is, an occasional glitched character on a serial terminal or an error in an audio stream is probably not an issue
• if you cannot tolerate any error; if the data must both be present and accurate at the receiver then you need both a method to detect an error *and* to correct it
• If the noise is likely to affect only one bit in a character (i.e. is very short period) and isn't expected to affect many characters (i.e. there isn't much of it) then parity will often allow you to detect the error; you will need to implement some sort of protocol that acknowledges each character has either arrived correctly or requests it be sent again (remembering that the return signal may also be incorrect due to noise). This is not very efficient...
• An alternate approach is to send sufficient extra data with each character to allow it to be reconstituted even if it arrives with error (think error correcting ram). This requires you to send extra bits with character, so (a) it's not very efficient and (b) you might need to design the hardware at both ends since normal UARTs don't allow this.
• Or, use a protocol where you send (e.g.) a larger packet of data - say 128 or 256 bytes - with sufficient error detection built in (say a checksum or hash code) such that the receiver can tell with a good degree of certainty that it has received a good packet. The acknowledgement can be a good deal shorter than the packet (but may still be structured) which keeps the efficiency up where the packet does not need to be received. This does not rely on the UART to do anything special, but as with all the other points above, does require a protocol which is understood by both ends of the train. (The internet IP system works like this).

But in most cases, the transmission chain is so good in many cases that the parity bit is pointless and you can assume that the 8-n-1 setting will work, even at high bit rates.

Neil

Parity bit is a thing of the past, where there was no or at least very small computer power (and RAM).

Today you would use a block protocol like XMODEM or YMODEM or ?

If check and speed matter.

(on a simple system just echo what you send)

Last Edited: Sun. Aug 2, 2020 - 09:57 AM

Parity bit is a thing of the past

I'm using it for the future...not as intended for error detection, but soon to fantastically double the hardware capacity ...this represents a major leap forward for man. I will share any rewards from this usage.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Timer0 interrupt.

I want to generate interrupts for 50 micro seconds. How many counts need for 50 micro seconds? Clock frequency 16 MHz

Atmega 382p has 8 bit timer0 that start from 0 to 255

Wilth 16MHz clock, every clock cycle is 1/16E6 = 62.5ns. Equivalentlly, you can think 16 clocks in a microsecond.

So 50us will take 50*16 = 800 clocks.

You cannot count 800 clocks in an 8 bit counter (without some help). The usual strategy is to prescale the counter's clock. The prescaler divides by powers of two (e.g. 2, 4, 8, ... ). We need to prescale by at least 4 to get a count under 255. But the best Timer0 can do is divide by 8. That turns the 16MHz clock into 2MHz clock just for Timer0. This gets you 1us for every 2 clock cycles. 50us would than take 100 clock cycles.

So, chose a timer mode with a settable TOP value, and load the register that controls TOP with 100-1 = 99. Create a interrupt service routine that triggers on overflow, and you are "in".

Jim

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