<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>uart interrupt</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/27757/uart-interrupt</link><description> 
Hi everybody, 

 
Could you please help me: i need to use an uart interrupt routine
in a RTX code. I&amp;#39;ve already found some examples for the uart
interrupt routine, but i cannot make it work using tasks. 
Has anybody an example to show me how to use</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: uart interrupt</title><link>https://community.arm.com/thread/152234?ContentTypeID=1</link><pubDate>Sat, 15 Oct 2011 09:18:24 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:c6ff3d80-ccc2-4da6-87ae-888924e5c17c</guid><dc:creator>michele lattuada</dc:creator><description>&lt;p&gt;&lt;p&gt;
Hi everybody,&lt;br /&gt;
i left this thread for a couple of days and i&amp;#39;m very pleased. I&amp;#39;ve
learnd a lot of thing reading your posts.&lt;br /&gt;
But i still have a problem with my code.&lt;br /&gt;
I cannot receive anything from the Uart.&lt;br /&gt;
I wrote a very simple code: i want to receive a character sended from
Hyperterminal (it works, i&amp;#39;v already tested it), read it and managed
it in a specific task which print it on the LCD.&lt;br /&gt;
I&amp;#39;m using an STM32F103ZE.&lt;br /&gt;
I&amp;#39;ve looked at many example and i&amp;#39;m quite sure that the code is right
and i make some mistakes in the settings, i&amp;#39;ve putted a flag inside
the UART interrupt handler but it is never set to 1. What should i
check?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: uart interrupt</title><link>https://community.arm.com/thread/151456?ContentTypeID=1</link><pubDate>Fri, 14 Oct 2011 08:13:50 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:75ed1fb3-9afd-45a1-b371-535d0aec16bb</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
But the problem with having the read task polling for the rest of
the characters, is that the read task must have a high enough prio to
poll the UART so you don&amp;#39;t miss characters. But if the task
busy-loops while polling, then it would starve lower-prio tasks.&lt;/p&gt;

&lt;p&gt;
A better way is to have a state machine, where read task consumes
the number of characters that are available and then wait for more
data and continue. So instead of polling by checking the UART
directly, you poll by calling the RTOS wait function.&lt;/p&gt;

&lt;p&gt;
Polling by using a timer would also be &amp;quot;wrong&amp;quot;, since that would
still give a poll frequency that must be done faster than the maximum
character receive speed but without guaranteeing that there is a
character available on next poll. Keeping the interrupts enabled and
using the RTOS wait function means the task only gets enabled after a
timeout (if specified) or when there are one (or more) character
available.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: uart interrupt</title><link>https://community.arm.com/thread/146765?ContentTypeID=1</link><pubDate>Fri, 14 Oct 2011 07:53:20 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:f84352ac-5b46-42d7-80da-150a293d8a52</guid><dc:creator>@Marc Crandall</dc:creator><description>&lt;p&gt;&lt;p&gt;
Thanks Per and Tamir,&lt;/p&gt;

&lt;p&gt;
I see your points and I think I probably should change some of my
UART setups.&lt;/p&gt;

&lt;p&gt;
On another on of my setups I&amp;#39;m using a custom protocol where the
data in one message could be larger than my buffer (in RAM).&lt;br /&gt;
This is were I got to disabling the interrupt...&lt;/p&gt;

&lt;p&gt;
Basically my example was a little mis-leading because what I
really do is use the receive interrupt as a start message interrupt
and the task than polls for the rest of the message and processes as
it receives the message (basically writes a large file to &amp;#39;disk&amp;#39;.
Because the processing is faster than the double-buffered receive I
never really missed data.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: uart interrupt</title><link>https://community.arm.com/thread/153664?ContentTypeID=1</link><pubDate>Fri, 14 Oct 2011 07:34:07 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:4e535f61-484d-40b8-bd90-adfc4e2cbc5d</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
One thing here is that it is possible to use a mailbox feature and
send received characters as the mailbox &amp;quot;pointer&amp;quot; to the read task.
The size of the mailbox obviously controls the number of characters
that can be queued this way.&lt;/p&gt;

&lt;p&gt;
It is also possible to just signal the read task that there are
one or more characters available in the incomming circular buffer.
The read task then clears this signal when it starts processing data.
If the ISR is run during the processing, and inserts more data, then
the read task might get accidentaly activated once without any more
data avaiable. But that isn&amp;#39;t really a problem.&lt;/p&gt;

&lt;p&gt;
The concept of just flagging existence of data means that there
isn&amp;#39;t any issue of any queue depth for the RTOS. It&amp;#39;s just a question
if the read task should freeze or not when it has consumed all data
in the ring buffer and then performs a new wait. Has the ISR run
during the read process, then the task will not block (but might not
find more data). Has the ISR not run during the read process, then
the read task will get stuck waiting for a new wakeup signal.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: uart interrupt</title><link>https://community.arm.com/thread/145206?ContentTypeID=1</link><pubDate>Fri, 14 Oct 2011 07:26:56 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:533cff9a-5fa0-4c16-9633-74ae4295d4ae</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
When your only buffer is the receive buffer (single-character,
double-buffered or full FIFO) in the UART, then it doesn&amp;#39;t matter if
you turn off the interrupt. If the task isn&amp;#39;t consuming the data fast
enough and turns on the interrupt again (and the ISR has time to run)
before the hw in the UART suffers a overrun, you will lose data.&lt;/p&gt;

&lt;p&gt;
When you have buffer space in RAM, then keeping the interrupt
enabled means that the UART can generate a new interrupt and more
data can be buffered in your RAM even if the task hasn&amp;#39;t had the time
to consume the previous data. But this only works if the interrupt is
kept enabled - with interrupts disabled, you are removing the ability
to buffer a burst of data into RAM.&lt;/p&gt;

&lt;p&gt;
Some protocols can&amp;#39;t stand any jitter in processing, so it doesn&amp;#39;t
matter. But many protocols are packet-based and don&amp;#39;t care if 1, 10
or 100 characters are buffered, as long as the device has a
reasonable response time from the end of the packet until the
receiver reacts with an acknowledge or other response data.&lt;/p&gt;

&lt;p&gt;
When you only allow one character/interrupt and turns off
interrupts between receive and processing, then your receive task
must run with very high priority. When the receive task is allowed to
process data in bursts, you can reduce the receive priority as long
as all higher-prio tasks are guaranteed to leave leave some CPU time
with a reasonable max interval.&lt;/p&gt;

&lt;p&gt;
Next thing is that you often have both receive and transmit. And
then you normally have interrupts to inform that the UART can accept
more data - normally using FIFO or at least double-buffering. With
interrupts disabled, you will not keep the outgoing channel full. And
not all protocols have a 1:1 relation between incomming and outgoing
data.&lt;/p&gt;

&lt;p&gt;
If you make use of hardware handshake signals, you may want to get
interrupts for modem control line changes too, allowing you to block
transmission of more characters if the other side isn&amp;#39;t ready. Having
interrupts disabled, will slow down the detection of these modem
control line signals until your receive task have had time to
run.&lt;/p&gt;

&lt;p&gt;
Another thing to consider here is that if you activate a receive
FIFO in the UART, then a single receive interrupt need not mean that
you have one character available. You may have one (in case of a FIFO
timeout), but you might just as well have filled the FIFO past the
receive watermark. So with receive FIFO enabled, the ISR would have
to continue to pick up characters until the UART status claims it
doesn&amp;#39;t have any more characters.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: uart interrupt</title><link>https://community.arm.com/thread/148454?ContentTypeID=1</link><pubDate>Fri, 14 Oct 2011 07:22:25 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:7fe3ae8d-f2bc-44bf-aa89-94bbedb09f5f</guid><dc:creator>Tamiryan Michael</dc:creator><description>&lt;p&gt;&lt;p&gt;
Since &amp;quot;isr_evt_set&amp;quot; has a queue behind it (as far as I can
remember), there is no risk of missing signals even if your
application does not respond fast enough for short bursts of data.
Therefore, as long as the queue is big enough (RTX allows setting its
size up to a limit (at least, officially), FreeRTOS can offer an
arbitrary size and type) there is really no reason to disable the
interrupt source. Why did you do it in the first place? Maybe there
was some good reason for it that we are not aware of?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: uart interrupt</title><link>https://community.arm.com/thread/148220?ContentTypeID=1</link><pubDate>Fri, 14 Oct 2011 07:16:10 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:2a454ace-d0e8-4cbb-a268-59651eb8b82f</guid><dc:creator>@Marc Crandall</dc:creator><description>&lt;p&gt;&lt;p&gt;
I agree that you can&amp;#39;t &amp;#39;process&amp;#39; the data with the interrupt
disabled as this could obviously take too long but I see no reason
why you can&amp;#39;t have the circular buffer in the task space.&lt;/p&gt;

&lt;p&gt;
Basically this is how I set it up and this has always worked for
communication with terminals and also with machines using defined
protocols.&lt;/p&gt;

&lt;pre&gt;
__task void task_uart(void)
{
    for (;;)
    {
        os_evt_wait_or(CHAR_READY_EVENT, 0xFFFF);

        // ADD BYTE TO MESSAGE OR BUFFER OR WHATEVER STRUCTURE

         NVIC_EnableIRQ(UART_IQRn);

         //IF ALL DATA IS RECEIVED (Meaning will depend on application)
         // swap to second receive buffer post message received event...
    }
}


void UART_IRQHandler (void)
{
    uint32_t intsrc, tmp;
    /* Determine the interrupt source */
    intsrc = UART_GetIntId(UART_PORT);
    tmp = intsrc &amp;amp; UART_IIR_INTID_MASK;

    // Receive Data Available
    if (tmp &amp;amp; UART_IIR_INTID_RDA)
    {
        last_received_char = UART_ReceiveByte(UART_PORT);
        NVIC_DisableIRQ(UART_IQRn);
        isr_evt_set (CHAR_READY_EVENT, t_uart);     // Send Event Flag to task
    }

    NVIC_ClearPendingIRQ(TERNIAL_IQRn);   // Clear Interrupt
}

&lt;/pre&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: uart interrupt</title><link>https://community.arm.com/thread/147737?ContentTypeID=1</link><pubDate>Fri, 14 Oct 2011 07:08:58 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:ca2be09a-b859-4720-ab23-70e23c36e866</guid><dc:creator>Tamiryan Michael</dc:creator><description>&lt;p&gt;&lt;p&gt;
Disabling the interrupt also increased the chances that you will
actually miss a character, if you processing time is too long
resulting in hardware buffer overflow. Hardware flow control can help
with that, though.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: uart interrupt</title><link>https://community.arm.com/thread/146761?ContentTypeID=1</link><pubDate>Fri, 14 Oct 2011 07:07:15 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:78a78e61-795b-4bc9-ab8c-289a02aa78df</guid><dc:creator>Tamiryan Michael</dc:creator><description>&lt;p&gt;&lt;p&gt;
Notice how the ISR posts data in the buffer and &amp;quot;forgets&amp;quot; about
it, greatly reducing ISR overhead.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: uart interrupt</title><link>https://community.arm.com/thread/145211?ContentTypeID=1</link><pubDate>Fri, 14 Oct 2011 07:05:24 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:cadc6d4e-a0be-4a28-b392-e364fcd2b19f</guid><dc:creator>Tamiryan Michael</dc:creator><description>&lt;p&gt;&lt;pre&gt;
static void process_uart_irq(int32_t a_uart_source)
{
        int32_t l_bytes ;

        uint32_t l_now = T3TC ;

    // guard againt an overflow of interrupts

        if ( (l_now - s_uart_isr_previous_entry_time[a_uart_source]) &amp;lt; T3_x_MICROSECONDS(20) )
        {
                if (++s_uart_isr_flood[a_uart_source] &amp;gt; UART_ISR_FLOOD_RESET_THRSHOLD)
                {
                        // reset peripheral
                        reset_uart(a_uart_source) ;

                        s_uart_isr_flood[a_uart_source] = 0 ;
                }
        }
        else
        {
                s_uart_isr_flood[a_uart_source] = 0 ;
        }

        s_uart_isr_previous_entry_time[a_uart_source] = l_now ;

        switch ( (*sp_effective_IIR[a_uart_source]&amp;gt;&amp;gt;1) &amp;amp; 0x7) // interogate bits 3:1 to identify interrupt reason
        {
                case 0x6: // Character Time-out Indicator (CTI)
                {
            if (circular_buffer_enqueue(&amp;amp;g_data_interface.uart_rx_circular_buffer[a_uart_source], *sp_effective_RBR[a_uart_source] ) )
            {
                // buffer full

                // reset buffer
                circular_buffer_init(&amp;amp;g_data_interface.uart_rx_circular_buffer[a_uart_source], g_data_interface.uart_rx_circular_buffer[a_uart_source].size) ;
            }
                }
                break ;

                case 0x2: // Receive Data Available (RDA)
                {
            // collect frame characters

            l_bytes = BLUETOOTH_UART_RX_FIFO_TRIGGER_LEVEL ;

            do
            {
                if (circular_buffer_enqueue(&amp;amp;g_data_interface.uart_rx_circular_buffer[a_uart_source],
                                            *sp_effective_RBR[a_uart_source] ) )
                {
                    // buffer full

                    // reset buffer
                    circular_buffer_init(&amp;amp;g_data_interface.uart_rx_circular_buffer[a_uart_source], g_data_interface.uart_rx_circular_buffer[a_uart_source].size) ;


                    break ;
                }
            }
            while ( (--l_bytes) &amp;gt; 0) ;
                }
                break ;
&lt;/pre&gt;

&lt;p&gt;
There is no reason to disable interrupts - notice the usage of a
circular buffer (which is emptied somewhere else). The application
should be allowed to be interrupted while processing previous
received data. You probably never encountered problems but reduced
your program&amp;#39;s responsiveness.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: uart interrupt</title><link>https://community.arm.com/thread/143026?ContentTypeID=1</link><pubDate>Fri, 14 Oct 2011 06:47:35 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:8867f18b-61c3-45cd-a31d-35600752b8c5</guid><dc:creator>@Marc Crandall</dc:creator><description>&lt;p&gt;&lt;p&gt;
Hi Per,&lt;/p&gt;

&lt;p&gt;
I don&amp;#39;t understand why &amp;#39;turning off&amp;#39; the receive interrupt is a
bad idea? It&amp;#39;s not like the hardware will stop receiving the data?
I&amp;#39;ve often done this and never encountered a problem?&lt;br /&gt;
Am I missing something?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: uart interrupt</title><link>https://community.arm.com/thread/140081?ContentTypeID=1</link><pubDate>Fri, 14 Oct 2011 00:39:29 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:7e3d30fa-408e-4676-9b0d-44f4701d4993</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
You normally don&amp;#39;t turn off any interrupts because you have
received data. If the task can&amp;#39;t handle every single character in
real time, then the design must be able to live with the receiver hw
FIFO and optional application ring buffer. Since the hw FIFO has
fixed size, the ISR must handle interrupts to offload to sw ring
buffer. Besides, there are more than one reason for an UART to
generate an interrupt.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: uart interrupt</title><link>https://community.arm.com/thread/136633?ContentTypeID=1</link><pubDate>Thu, 13 Oct 2011 13:13:17 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:5f8e8ec1-6c92-44ec-9235-4d96c5d72b4e</guid><dc:creator>michele lattuada</dc:creator><description>&lt;p&gt;&lt;p&gt;
Yes, but i have some problems with them. I think i&amp;#39;ve to work a
little bit more with it.&lt;br /&gt;
Thanks for the link. i will cull it. Thanks.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: uart interrupt</title><link>https://community.arm.com/thread/127149?ContentTypeID=1</link><pubDate>Thu, 13 Oct 2011 13:04:29 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:b6935e20-d225-472e-8f36-dbfe0bb043c3</guid><dc:creator>@Marc Crandall</dc:creator><description>&lt;p&gt;&lt;p&gt;
Have you looked at the examples under:&lt;/p&gt;

&lt;p&gt;
C:\Keil\ARM\Boards\ST&lt;/p&gt;

&lt;p&gt;
Also try:&lt;/p&gt;

&lt;p&gt;
&lt;a target="_blank" href="http://www.st.com/stonline/stappl/resourceSelector/app?page=resourceSelector&amp;amp;doctype=FIRMWARE&amp;amp;ClassID=1734"&gt;www.st.com/.../app&lt;/a&gt;&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: uart interrupt</title><link>https://community.arm.com/thread/116533?ContentTypeID=1</link><pubDate>Thu, 13 Oct 2011 12:57:30 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:91017d06-8d1b-4ead-8099-ef3a66456d63</guid><dc:creator>michele lattuada</dc:creator><description>&lt;p&gt;&lt;p&gt;
I&amp;#39;m using an STMf103ze.&lt;br /&gt;
I tried to adapt a code that i found on the example provided by Keil.
I want to dialogue with an inertial platform, acquiring data each
time that it change the position. So i want to work using tasks and
an uart.&lt;br /&gt;
I&amp;#39;m trying to learn how to do it using hyperterminal for sending a
character to the dev kit and manage it, but i&amp;#39;m encountering come
difficulties.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: uart interrupt</title><link>https://community.arm.com/thread/105381?ContentTypeID=1</link><pubDate>Thu, 13 Oct 2011 12:49:46 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:30390441-0b5d-4186-aca7-5b053a9f61b3</guid><dc:creator>@Marc Crandall</dc:creator><description>&lt;p&gt;&lt;p&gt;
Yes, this is generic code you will have to adapt it.&lt;/p&gt;

&lt;p&gt;
What micro are you using?&lt;/p&gt;

&lt;p&gt;
NVIC stands for Nested Vector Interrupt Controller. This is
specific to Cortex-M devices.&lt;/p&gt;

&lt;p&gt;
If you are using a Cortex-M device search for the CMSIS drivers
for your device.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: uart interrupt</title><link>https://community.arm.com/thread/79660?ContentTypeID=1</link><pubDate>Thu, 13 Oct 2011 12:45:42 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:bc243578-361f-4c8e-9017-ace7b2748586</guid><dc:creator>michele lattuada</dc:creator><description>&lt;p&gt;&lt;p&gt;
Thanks, i&amp;#39;ll try it.&lt;br /&gt;
Just a couple of question: this is just an example, i&amp;#39;ve to adapt it
to my code. I cannot find anywhere the function UART_ReceiveByte,
right?&lt;br /&gt;
Other question. I&amp;#39;ve already seen the NVIC in other examples, but i
cannot understand how it works and what is it function.&lt;br /&gt;
Thanks&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: uart interrupt</title><link>https://community.arm.com/thread/59937?ContentTypeID=1</link><pubDate>Thu, 13 Oct 2011 12:36:21 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:90e169bc-93ae-47a8-88ec-06fc55fab3d6</guid><dc:creator>@Marc Crandall</dc:creator><description>&lt;p&gt;&lt;p&gt;
Hello,&lt;/p&gt;

&lt;p&gt;
Using tasks should not change things too much.&lt;br /&gt;
Often events are used to signal to a task that an interrupt has
occurred.&lt;/p&gt;

&lt;p&gt;
For example:&lt;/p&gt;

&lt;p&gt;
TASK -&lt;/p&gt;

&lt;pre&gt;
__task void task_uart(void)
{
    for (;;)
    {
        os_evt_wait_or(CHAR_READY_EVENT, 0xFFFF);

        // handle char...

        NVIC_EnableIRQ(UART_IQRn);

    }

}
&lt;/pre&gt;

&lt;p&gt;
IRQ -&lt;/p&gt;

&lt;pre&gt;
void UART_IRQHandler (void)
{
    uint32_t intsrc, tmp;
    /* Determine the interrupt source */
    intsrc = UART_GetIntId(UART_PORT);
    tmp = intsrc &amp;amp; UART_IIR_INTID_MASK;

    // Receive Data Available
    if (tmp &amp;amp; UART_IIR_INTID_RDA)
    {
        last_received_char = UART_ReceiveByte(UART_PORT);
        NVIC_DisableIRQ(UART_IQRn);
        isr_evt_set (CHAR_READY_EVENT, t_uart);     // Send Event Flag to task
    }

    NVIC_ClearPendingIRQ(TERNIAL_IQRn);   // Clear Interrupt
}
&lt;/pre&gt;

&lt;p&gt;
Hope this helps.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>