Serial data sending in atxmega128

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

Dear all,

 

Hi , thanks for your time.

I'n trying to send response to a master and the response data byte count changes for each message. I am using "putchar" function but it seems a little bit slow, not in baud rate it has a standard value of 1200, but for the delay between every bytes. 

Is there a way to send, say 10 bytes, without delay among them with a constant baud rate ?

 

P.S: I'm using AtxMega128A1u in 32 MHz clock.

 

In the end it doesn't even matter ...

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

tzanti wrote:
it seems a little bit slow

Quantify that!

 

How long were you expecting?

How long is it actually taking?

What testing/investigation/debugging have you done to find the source of the delay?

 

Is there a way to send, say 10 bytes, without delay among them

Yes.

 

The limiting factor is how fast your code can re-fill the UART's buffer. 

 

Only you know anything about your code !!

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

1200 Baud is 1200 bps (bits per second). If the UART is set up for 8 data bits, no parity, one stop bit then for every character 10 bits will be transmitted (since there is always a start bit also). At absolute maximum you will then be able to transmit 120 characters per second, i.e. 1200 bps /10 bits. In reality it will be slower. How much depends, as awneil says, on how fast you stuff characters into the UART. You should be able to get close to 100 characters per second.

 

If something else keeps the AVR occupied so that stuffing characters into the UART is not keeping up, then it will of-course be slower.

 

Show a minimal but complete program that builds and runs.

State what performance (e.g. characters per second) you observe.

 

What performance are you expecting?

Happy 75th anniversary to one of the best movies ever made! Rick Blane [Bogart]: "Of all the gin joints, in all the towns, in all the world, she walks into mine."

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

JohanEkdahl wrote:
State what performance (e.g. characters per second) you observe.

Also state how you observe it.

 

The obvious way would be to use an oscilloscope (or logic analyser, or similar) so that you can see any gaps ...

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

Did you write the software, or are you using some canned libraries?

 

Some software includes a built in delay between characters, for "pacing".

The delay is to allow the receiver to process the incoming character, (stuff it in a buffer, perhaps actually parse the input data stream), without losing the next character.

These days that is generally unnecessary, the hardware is fast, and is often buffered.

 

Do you control the buad rate at each end of the communications channel?

Is the connection by wire, RF, telephone modem, etc.?

 

For short distances and hardwired links 1200 is a very slow data rate, and your time to send a packet could be greatly reduced by increasing the baud rate, (57,600, for example).

 

JC

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

I'll go with Johan on this one. 1200 baud is about 120 characters per second (at 8N1). Thus each character takes 8.3ms and 10 bytes will be slow enough to see. All this is set by just the baud rate. 

 

You have several choices:

 

1. Sit there in a loop, waiting for TransmitComplete flag to be set, then pop the next character into the transmit buffer. Just about the fastest possible but it is also "blocking".

 

2. Wait for a TransmitComplete interrupt. Thats a bit slower but at 1200 baud, you will NOT be able to tell the difference. Once in the ISR, stuff a new character into the buffer. This is non-blocking.

 

3. In your main loop, check (poll) the TransmitComplete flag bit. This is potentially the slowest, depending on how long it takes to process one pass though the loop. Non-blocking. You would still be hard-pressed to make it slow enough to visibly slow the character rate. 

 

4. On an XMega, you could probably use DMA. Probably fastest. Non-blocking. But at 1200 baud, who really cares. 

 

If speed is an issue, bump it up to at least 9600 baud. Better yet, something like 115.2Kbaud or faster. I do not think there is anything slowing down your character rate except for the baud rate you have chosen.

 

<EDIT> Yes, 1200 may be a "standard" baud rate, but so is 9600, and so is 19200 and so are a number of faster ones. There is no compelling reason to choose 1200 unless you are working with a modem-like device that only accepts 1200 baud. One such example is a short-range wireless module. </EDIT>

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Thu. Sep 7, 2017 - 10:09 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The OP's response is looking rather slow now ...

 

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

NO, not transmit complete.  You might want to use that when finished, if you disable the usart or go to power save sleep.  While sending, you should use output buffer empty interrupt (or flag, if you aren't using interrupts).  This will give you a whole character time to stuff the next byte in the output buffer and still keep the data flowing at full speed.  

 

If you are depending on the inherent freq. accuracy of the 32 MHz osc, you shouldn't.  You can use DFLL hooked up to the 32 kHz RC osc.

 

1200 baud is pretty slow these days, but I suppose there could be a reason to use it. 

 

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

Steve17 is correct. The best status to check is UDREn, not TransmitComplete. However, this is XMega so it might be called anything.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

Hi everybody,

 

first of all thanks for your kind responses, I should explain problem here in order to draw a better picture.

I need to use 1200 baud rate because the protocol needs it (HART), so changing the baud rate is not an option.

I have a tx_done bit, I manually set it every time and it clears every transmit finish and after that i send new character, is it efficient ? (I use a put_char in a loop until i finish all bytes)

If I use a pointer and fill the transmitter buffer with it, is that a good way?

 

Thanks again

 

 

In the end it doesn't even matter ...

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

You should use the "Data Register Empty Flag".  I guess you don't need to use the "Transmit Complete Interrupt Flag" at all.  I think you don't understand the transmit complete thing anyway.  When you think you are setting it, you are actually clearing it.  Anyway, it doesn't matter if you don't use it.

 

Fortunately the data register empty flag is simple.  It's true when the "data" register is empty and false when it is not. 

 

Of course the "data" register could be confusing too.  That same memory location is the output register when written to, and the input register when read.

 

The bottom line is you can stick a character in the data register whenever the "Data Register Empty Flag" is true.  I can't give a guarantee I haven't missed something because I use interrupts.

 

I don't use ASF.  It's too cryptic.  I guess the ASF name is DREIFn. 

 

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

@tzanti : Several questions where asked about actual and expected performance. Please provide an answer.

 

tzanti wrote:
I have a tx_done bit, I manually set it every time and it clears every transmit finish and after that i send new character, is it efficient ? (I use a put_char in a loop until i finish all bytes)

I can't understand that. Especially "it clears every transmit finish". Could you show actual code?

Happy 75th anniversary to one of the best movies ever made! Rick Blane [Bogart]: "Of all the gin joints, in all the towns, in all the world, she walks into mine."

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

The manual doesn't explain very well the buffering.  It says the output is buffered so you can keep sending without any delays between characters, but I don't think it gives details.

 

Here's how I think it works.  First, what Atmel calls the data register, I'm apt to think of as the buffer register.  When you start sending by putting the first character into the data/buffer register, it is immediately moved to some kind of shifter, where is it serialized and each bit is put on the TX pin at the proper rate.  As soon as the character is moved from the data/buffer register to the shifter, the data/buffer register is considered empty and the data/buffer register empty flag is set. 

 

So you could put the second character in the data register probably one microsecond after the first character.   Of course things slow down a bit now.  Whenever you put a char into the data register, the empty bit is cleared.  After the first char. is sent to the TX pin, the second char is moved to the shifter and again the empty bit is set.  So if you do it right, whenever one character is being serialized and sent, you can have the next character patiently waiting in the data register to be sent when the preceding character has been sent.

 

With your code, I don't think you have any need to look at the transmit complete bit.  You don't care when the usart has finished serializing the data.

 

Last Edited: Sun. Sep 10, 2017 - 01:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I fully concur with the view steve17 has of how the U(S)ART works.

Happy 75th anniversary to one of the best movies ever made! Rick Blane [Bogart]: "Of all the gin joints, in all the towns, in all the world, she walks into mine."

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

This is where I clear it, and I check it before put next char,

 

 

// USARTE0 Transmitter interrupt service routine
interrupt [USARTE0_TXC_vect] void usarte0_tx_isr(void)
{
tx_done=0;
if (tx_counter_usarte0)
   {
   --tx_counter_usarte0;
   USARTE0.DATA=tx_buffer_usarte0[tx_rd_index_usarte0++];
#if TX_BUFFER_SIZE_USARTE0 != 256
   if (tx_rd_index_usarte0 == TX_BUFFER_SIZE_USARTE0) tx_rd_index_usarte0=0;
#endif
   }
}

 

In the end it doesn't even matter ...

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

How to properly post code: http://www.avrfreaks.net/comment...

 

You still haven't answered the questions about expected & actual performance!

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

You are right about code, my bad.

 

The main problem is that I am not sure what is the right performance!

I know the baud rate should be 1200, but I'm not sure when I use "putchar" function (predefined function to send serial msg) to send lets say 30 bytes is it fast enough?

1200 means 1/1200 sec for each character but what about time between sending bytes. can this time be so long to interrupt the protocol procedure.

In fact I have problem when the micro tries to communicate continuously in the parts that i just send only one byte i have no problem.

 

Thank you 

In the end it doesn't even matter ...

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

tzanti wrote:
The main problem is that I am not sure what is the right performance!

So when you said, "seems a little bit slow", how long, exactly, was it taking?

And how long, exactly, did you expect it to take?

And on what did you base that expectation?

 

1200 means 1/1200 sec for each character

No!

 

Did you not read #3 ?

 

but what about time between sending bytes. can this time be so long to interrupt the protocol procedure.

Did you not read any of the replies? Many explained that any delay between characters is down to your code.

 

 

In fact I have problem when the micro tries to communicate continuously in the parts that i just send only one byte i have no problem.

So what "problem", exactly, do you have?

 

Remember: we know nothing about you, or your project, or your code other than what you supply in your posts!

 

We cannot guess what your problem/s is/are !

 

It sounds like you need to go back to basics with UART comms, though ...

 

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

tzanti wrote:
1200 means 1/1200 sec for each character

Sigh.. Please re-read #3.

 

Note these important specifics: 1200 is bits per second.

A character is 8 bits.

There is overhead in start and stop bits.

Theoretically you can at best get 120 (on-hundred-and-twenty) characters per second.

tzanti wrote:
The main problem is that I am not sure what is the right performance!

Re-read #3. Be aware you have  mis-understood some basics (e.g. difference between bits per second and characters per second). Do not make assumptions while reading. Ask if there is something you don't understand.

 

And again: What actual performance do you see? How are you measuring this? What performance do you expect/need?

 

tzanti wrote:
In fact I have problem when the micro tries to communicate continuously

Describe the symptoms.

Happy 75th anniversary to one of the best movies ever made! Rick Blane [Bogart]: "Of all the gin joints, in all the towns, in all the world, she walks into mine."

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Mon. Sep 11, 2017 - 11:13 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I read all the replies, and I meant bit by character. 

but my question is very simple , is "putchar" good way to communicate through serial port or is there better way ?

I'm not trying to find exact time delay between 2 byte I'm sending I want to know that feeling register by myself is faster or not

 

Thank you 

In the end it doesn't even matter ...

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

tzanti wrote:
I read all the replies, and I meant bit by character.

That is rather a gross mistake to make!

 

surprise

 

but my question is very simple , is "putchar" good way to communicate through serial port or is there better way ?

That, of course, depends on your definition of "good".

 

Your fundamental problem seems to be that you have not established the basic requirements of your project.

 

In particular, the transmission speed of your UART link.

 

You have mentioned the HART protocol - so you should start with the specifications of that protocol to find its timing requirements.

 

Your application may have other, specific, requirements.

 

 

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

you see, you don't answer , you just left comments on parts which are not the real question 

 

Thank you 

In the end it doesn't even matter ...

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

But, as explained, your question is impossible to answer!

 

"Good" is meaningless in the absence of any criteria by which to measure it!

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

I described it , faster .

In the end it doesn't even matter ...

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

Dear tzanti, please read through this whole post before getting angry. Then relax and think for a while. If you're still angry after that then there is nothing anyone can do to help you with your AVR problem.

 

tzanti wrote:
I read all the replies, and I meant bit by character. 

That statement too makes no sense.Did you mean to say "by bit I meant character"?

 

tzanti wrote:
but my question is very simple , is "putchar" good way to communicate through serial port[...] ?

Yes. It is a good way.

 

 

tzanti wrote:
or is there better way ?
 

If better means faster, then yes: Handling the registers explicitly in your code will be faster (if done right). But, it will only be marginally faster, and that margin will be smaller the lower the bps value you use. The actual cost is, more or less a few extra calls, to small-and-simple functions. Just to try to put some numbers on that: Lets say the extra cost is 100 clocks. You're running the AVR at 32 MHz, which means those 100 clocks take 0.003125 milliseconds. Compare that to the actual time it takes to shift out 10 bits at 1200 bps: 8.333 ms. So (assuming my guess of 100 clocks is correct) the extra cost is 0.003125/0.3333, which is roughly 0.03%. In practice "nothing". (And even if my guess is wrong and it's 1000 clocks it will still be something like 0.3%).

 

Generally, "better" is a meaningless criteria unless you become specific about "better in what way?" and "how much better?" Since you've refused to in any way quantify your performance requirements, the only answer that can be given is the one I've given above.

 

tzanti wrote:
you see, you don't answer , you just left comments on parts which are not the real question 

You probably don't even know what "the real question" is! The reason we are asking these questions, which you find irrelevant, is because it looks to us like your problems has little or nothing to do with the performance of putchar v/s writing the USART registers yourself, unless you've messed up big-time (but we can't check on that since we've only seen a part of the coded involved). Instead, even with the "fuzzy" symptom description you have given, it sounds more likely that you have a problem with some buffer overrun or similar. Again, we can't tell since we've not seen enough and since you refuse to answer on anything but the question you think will solve your problem.

 

You came here asking for help. When experienced users here try to really help you you become hostile and refuse to answer on the follow-up questions.

 

If you want to see how efficient or inefficient it is to use putchar then just study the code. The sources for avr-libc are here: http://savannah.nongnu.org/proje... . Combine that with a study of the generated code in your project and all shall be revealed. If you're not capable to do that then why not trust the people here who are?

 

You have not even answered how your problems manifestate themselves. Only that when you send many characters you have problems. So again, how are your problems manifestating themselves. Lost characters? Does the program hang? Do you see garbage characters in the transmission? Or what...?

 

Please take your time preparing your next answer. Better a good, thought through answer that takes an hour to get right than a hasty one that takes a minute. Give us some real, hard facts. And remember what awneil posted above:

we know nothing about you, or your project, or your code other than what you supply in your posts!

 

Happy 75th anniversary to one of the best movies ever made! Rick Blane [Bogart]: "Of all the gin joints, in all the towns, in all the world, she walks into mine."

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Mon. Sep 11, 2017 - 12:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

First of all , I really thank you all for your time.You are helping a lot.

But when someone using "gross" I don't believe that is appropriate.

 

all the information you provided is very useful for me, and you made me understand that sending serial characters through "putchar" function or by handling interrupts are not really different in the practice.  

 and that is all i wanted to know, now i know that any problem with timing should associate with other parts of my program. It is about 2K lines of program and I don't wanna bother you by sending you whole program and ask you to do the job I supposed to do.

 

At last I thank all the members who spend time and tried to solve my not completely described problem.

 

Best Regards 

In the end it doesn't even matter ...

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

tzanti wrote:
But when someone using "gross" I don't believe that is appropriate.

It is your English that is lacking. In that sentence it merely means "big and obvious". See e.g. https://www.merriam-webster.com/... . The "slang" interpretation of "gross", i.e. something that is disgusting or filthy is not applicable here.

Happy 75th anniversary to one of the best movies ever made! Rick Blane [Bogart]: "Of all the gin joints, in all the towns, in all the world, she walks into mine."

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

There is nothing "special" about putchar(). All it will basically be doing is:

void putchar(char data) {
    wait_until_UART_has_finished_previous_transmission();
    UART_DATA = data;
}

so if you have 30 bytes to send then there's going be very little faster than:

for (i = 0; i < 30; i++) {
    putchar(data_to_send[i]);
}

Because 1200 is such a slow baud rate the majority of the time "wasted" in doing all this is going to be in:

    wait_until_UART_has_finished_previous_transmission();

when i==0 then (assuming the UART was not already doing anything) there will be no wait here and the first character will be put into the data register and transmitted almost instantly. The putchar() will return to the for() loop, i will become i==1 and now it will call putchar() again with data_to_send[1] but now it will hit that wait_until...() because it will have got back into putchar() far, far, far quicker than the UART is going and it will not have finishded sending data_to_send[0] just yet. When that wait finally ends data_to_send[1] will begin to transmit. It will return back to the for() loop and i will move onto i==2. Then the wait will begin again.

 

Even at default speed an Xmega runs at 2MHz and will therefore execute TWO MILLION instruction cycles per second. Meanwhile at 1200 baud (1200 bits per second) and 10 bits to send a character the Xmega can only send 120 characters per second. So one character is going to take 1/120th of a second. In that time the AVR will execute 16,666 cycles. About 16,600 of those cycles will simply be wasted in the:

    wait_until_UART_has_finished_previous_transmission();

for each of the 30 characters sent. In total 30 characters at 120 characters per second is going to take 1/4 second which in AVR terms is a "lifetime"! It will have executed 500,000 machine cycles in that time and almost all wil be wasted simply waiting for the UART to finish transmitting the previous characters.

 

If you "need" those 500,000 cycles to get on and do other things instead of waiting for each character transmission to complete then you want to explore "transmission interrupts". With them code no longer waits. You send data_to_send[0] then the code continues on and does other things. About 16,666 cycles later the AVR will spot that the character has finally gone and will create an interrupt which (as the name suggests) will interrupt whatever the AVR is currently doing and will give it a chance to send data_to_send[1], then it will return to what it was doing until it's interrupted to say that one has gone and so on.

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

JohanEkdahl wrote:
It is your English that is lacking.
As moderator I agree. gross just means "big" - nothing more. You made a big mistake.

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

tzanti wrote:
 when someone using "gross" I don't believe that is appropriate.

My apologies if that caused offence.

 

As the others have said, I just meant "big".

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

 

You are using the transmit complete interrupt.  You should be using the "data register empty" interrupt.

 

Here is what my ISR looks like.  It's the second one.  The DRE thing, which I guess stands for Data Register Empty.  It's C++ but the ISR is the same, I think.

 

When I start sending a message, I enable the interrupt.  When I'm done, I disable it.

 

When the interrupt is enabled, the interrupt request flag will be true whenever the data register is empty.  It will go false when you write to the data register.

 


#include <avr/interrupt.h>

#include "usart_e0.h"

Usart* Usart_e0::usart_p;


ISR(USARTE0_RXC_vect)   {
   Usart_e0::usart_p->Process_in_interrupt();
   }


ISR(USARTE0_DRE_vect)   {
   Usart_e0::usart_p->Process_out_interrupt();
   }

 

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

Hello,

 

Thank you for your kind response , it was very helpful for me.

1 quick question, Do I need to handle interrupt every time I go through ISR or avr does it for me ?

 

Best Regards 

In the end it doesn't even matter ...

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

No need my friend, It was a misunderstanding.

In the end it doesn't even matter ...

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

tzanti wrote:
 Do I need to handle interrupt every time I go through ISR

The whole point of an ISR is to "handle" its interrupt - so not quite sure what you're asking here?

 

"ISR" = "Interrupt Service Routine" - also known, synonymously, as an Interrupt Handler.

 

or avr does it for me ?

In some cases, the hardware automatically clears the source of the interrupt; in others, you code has to do it - is that what you mean?

 

For details, see the datasheet.

 

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

in fact commands like 

" #asm("cli") , #asm("sei") "

 

should I use them every time I get an interrupt ?

In the end it doesn't even matter ...

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

First, understand what they do.

 

Then ask yourself, "do I need that here?"

 

Again, the datasheet is your reference for this stuff.

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

tzanti wrote:

in fact commands like 

" #asm("cli") , #asm("sei") "

 

should I use them every time I get an interrupt ?

No, on the contrary. It is very rare situations that require you to enable/disable interrupts explicitly once you are in an ISR.

 

The hardware disables interrupts when the interrupt event occurs. The compiler inserts code to (re-) enable interrupts at the end of the ISR.

Happy 75th anniversary to one of the best movies ever made! Rick Blane [Bogart]: "Of all the gin joints, in all the towns, in all the world, she walks into mine."

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Thank you so much. you helped me a lot. 

In the end it doesn't even matter ...

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

Yeah, the rule is pretty simple.  When you get this interrupt, stick another character into the Data register.  When you run out of data, you must disable the interrupt.  That's all there is to it.

 

If you don't disable the interrupt when you have no more data to send, that interrupt will fire continuously.