user57669: I have a Vector Nav VN100 IMU sensor that sends data serially UART. I have interfaced it with ATmega32. It receives data (ROLL angel) from the sensor and according to the ROLL angel, it controls a servo motor.
My question, if the sending rate is faster than processing speed of the ATmega32, then  some data from the sensor will be dropped. How to overcome this problem?

user20245: When using an embedded processor's hardware implemented UART, it is often the case that the rate at which the software processes the data is a fraction of the Gross bit rate some times referred to as the Baud rate.  If the UART is configured to handle 8 bit RS-232 where the Gross bit rate is 10000 bits per second, the processor only has to handle data at a faction of that rate.  Perhaps 1/10 given several bits of over head and space between characters.  
Processor intervention can be further reduced if the hardware UART contains several bytes of buffering.  For every doubling of the number of hardware supported bytes of buffering, processor interventions events are cut in half.
Beyond this, there are embedded processors in which the UART supports DMA or Direct Memory Accessing.  This is where the hardware UART will write the received data directly into the processor's memory with out need of processor intervention.  This feature is usually only found on feature rich embedded processors.
Study this PDF to understand the abilities and limitations of the ATmega32 processor.  Specifically the USART section starting on page 140. 

57669: <p>I have a Vector Nav VN100 IMU sensor that sends data serially UART. I have interfaced it with ATmega32. It receives data (ROLL angel) from the sensor and according to the ROLL angel, it controls a servo motor.</p>

<p>My question, if the sending rate is faster than processing speed of the ATmega32, then  some data from the sensor will be dropped. How to overcome this problem?</p>
 20245: <p>When using an embedded processor's hardware implemented <a href="https://en.wikipedia.org/wiki/Universal_asynchronous_receiver-transmitter" rel="nofollow noreferrer">UART</a>, it is often the case that the rate at which the software processes the data is a fraction of the <a href="https://en.wikipedia.org/wiki/Bit_rate#Gross_bit_rate" rel="nofollow noreferrer">Gross bit rate</a> some times referred to as the <a href="https://en.wikipedia.org/wiki/Bit_rate#Gross_bit_rate" rel="nofollow noreferrer">Baud rate</a>.  If the UART is configured to handle 8 bit <a href="https://en.wikipedia.org/wiki/RS-232" rel="nofollow noreferrer">RS-232</a> where the Gross bit rate is 10000 bits per second, the processor only has to handle data at a faction of that rate.  Perhaps 1/10 given several bits of over head and space between characters.  </p>

<p>Processor intervention can be further reduced if the hardware UART contains several bytes of buffering.  For every doubling of the number of hardware supported bytes of buffering, processor interventions events are cut in half.</p>

<p>Beyond this, there are embedded processors in which the UART supports <a href="https://en.wikipedia.org/wiki/Direct_memory_access" rel="nofollow noreferrer">DMA or Direct Memory Accessing</a>.  This is where the hardware UART will write the received data directly into the processor's memory with out need of processor intervention.  This feature is usually only found on feature rich embedded processors.</p>

<p>Study <a href="http://ww1.microchip.com/downloads/en/devicedoc/doc2503.pdf" rel="nofollow noreferrer">this PDF</a> to understand the abilities and limitations of the ATmega32 processor.  Specifically the USART section starting on page 140. </p>
