Really it is just implemented as an array but the beginning of the queue does not have to start at the first element of the array, and the end does not necessarily end at the last element in the array. It is called a ring buffer because data can wrap around back to the beginning, provided there is space. The type of FIFO we will be implementing is called a ring buffer, also known as a circular buffer. In this tutorial we will implement on type FIFO which can be used for queuing all types of data. However, even with hardware queuing, it may be optimal to implement a software queue in conjunction to provide more flexibility. Some higher end MCUs provide a UART FIFO in hardware. The UCA0STAT field will be set if this condition, called an overrun error, occurs. In fact, the UCA0RXBUF register can be considered a FIFO of depth 1 (depth of ‘n’ means ‘n’ elements fits in the FIFO) which drops the oldest data once full. Using a FIFO to queue received data is very common. There are different types of FIFOs so I won’t cover all the possible designs, but we will look at one in detail shortly.
MSP430 APPLICATION UART DRIVER FULL
If the FIFO is full and there is another piece of data to enter, it is either dropped (the newest data is lost) or the oldest data in the FIFO is pushed out and discarded. A FIFO is a type of buffer (or queue) in which the data enters and exits in the same the order. The solution is twofold: detect incoming data using interrupts rather than polling and then store each received character in a first-in-first out (FIFO) buffer. If the software does not read the data out of the register before the next character is received, the value in the register will be overwritten. What happens here is each character received by the peripheral is placed into the UCA0RXBUF register. You will notice that characters are dropped, only one or two of the characters are echoed back. Try typing ‘1234’ quickly at the menu prompt. Compile the code with this delay and then run it. This delay is exaggerated but it demonstrates an important point. The menu_run function reads the UART input and is then delayed one second before checking for the next character. We can easily simulate this scenario by adding a big delay into the the main loop – say one second – by using the _delay_cyles function. Once we start adding in more functionality to the main loop, it is possible that characters may be missed because the CPU is busy doing other things. As we learned with the push button back in lesson 6, this is not the optimal solution for most drivers.
![msp430 application uart driver msp430 application uart driver](https://forum.43oh.com/uploads/monthly_11_2013/post-34423-0-82235400-1385388175.png)
![msp430 application uart driver msp430 application uart driver](https://e2e.ti.com/resized-image/__size/1230x0/__key/communityserver-discussions-components-files/166/Screen-Shot-2017_2D00_03_2D00_24-at-18.45.13.png)
MSP430 APPLICATION UART DRIVER DRIVER
In the last lesson, we created a very simple UART driver which polls the peripheral for received data.