LPC2000 UART串口使用心得

针对zgpswh在串口使用上的一些难题，总结个人在前一阶段的理解，比较片面，不对的地方请高手指正。

1、LPC2000 系列芯片的串口的接收模块包括接收缓冲寄存器和移位寄存器。接收的数据进入移位寄存器后经移位处理并行传入缓冲寄存器，事实上，UART的FIFO是一个硬件环形的缓冲队列，物理上不可寻址，不可见，仅U0RBR这个FIFO出口可见。U0RBR就是接收FIFO的第一位。FIFO的长度是可设的，也叫触发点，低于这个长度的字符串不会引起中断，但在实际应用中，不可能串口读入的数据长度总为触发点值的整数倍，为此，引入了CTI即字符接收超时中断，当有不足触发点值规定的字符串读入时，将引起中断，其与串口的RDA中断具有相同的优先级，并会同时被使能。
那么，LPC2000的UART机制是如何判断串口读入数据的一次性容量呢？如果接收FIFO里已经有了1个字符，它可在一定的时间内等待下一个字符的读入，也就是说，不超过一定的时间就不会触发CTI中断，这个时间是在本次通讯协议设置的前提下，接收3.5到4.5个字符所用的时间。比如，需串口接收GPRS数传状态成功建立后的返回值“Ok_Info_WaitingForData”22个字符组成的字符串，FIFO触发点设置为14，在前14个字符读入之后，立即触发RDA中断，跳转至RDA中断服务子程序将这14个字符放入我所预设的缓冲区内，接着，后8个字符读入，这时CPU并不立刻中断，它需等待在本次串口通讯协议设置的前提下，接收3.5到4.5个字符所用的时间（需根据波特率和帧格式具体计算），这个时间一到，立刻触发CTI中断，换句话说，超过这个时间的等待，CPU就认为一个完整的字符串已经结束了，这才是字符串超时的真正含义。
   
2、为什么要用FIFO呢？我个人觉得，主要是为了提高串口的利用效率，同时可以避免一定程度上的丢包。比如，在用串口发送FIFO中断时，触发深度设为8，那么接收中断发生的条件是，FIFO里有了8个字符，但不是8个字节，因为串口异步通信的协议中，会加帧头和帧尾，但外表上还是以字符为单位。发送时，则是当FIFO里不满8个字符的时候要中断一次，所以利用FIFO发送时也要自建一个用来串口发送的缓冲池，发送中断服务程序里要做的就是从这个发送缓冲区里取数送进FIFO里，沿用上面的假设，触发深度设为8，一次性向FIFO里送15个字符，在送入第一批15个字符之后串口开始自动发送，当FIFO里只有7个字符时，立即发生中断，因此，在发送中断服务程序里要设个计数指针作为跳出中断的上限，这个上限不是8而是15。我认为，如果要发挥fifo的高效率，就必须把自设的缓冲区作成一个环状链表，即，不需要做移位处理使自设的缓冲区剩余的数据顶头。ZLG有详细的基于队列思想的例程。

3、个人觉得，当FIFO的触发深度设为1时和不用FIFO时的效果是一样的。

4、串口发送时，推荐第一个字符要在打开串口中断前送，否则可能中断只来一次。比如下面的这个用串口中断发送字符串的函数为：
/****************************************************************************************************
** 函数名称 ：UART0_SendStr()
** 函数功能 ：向串口发送字符串
** 入口参数 ：str    要发送的字符串的首地址指针
** 出口参数 ：无
*****************************************************************************************************
void UART0_SendStr( CHAR const  *str)
{ 
     Str_Send_P = str;
     U0THR = *Str_Send_P++;
     U0IER |= 0x02;      //开发送中断     
}
在中断发送程序中的处理为：
SWITCH(IIR & 0x0e)
       {
         case 0x02:              //利用串口发送中断，发送字符串
              if((*Str_Send_P)!='\0')
              U0THR = *Str_Send_P++;
              else
              U0IER &= (~0x02);   //关发送中断
              break;
这种做法的道理不太明白，但实验证明，不这么做就只发一次

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/liukun321/archive/2010/05/31/5636748.aspx