写串口通信程序，第一反应是采用中断+队列方式。

然后再考虑能不能裁减、替换、简化。

学会了这些基本原理，做ARM、PC什么的驱动程序都简单了。
要牢记：这是基本设计原理。

以前也写过串口，总想用简单的printf或查询等待的方式，总无法想明白指针和数组的用法，有机会一定补补

得先保证接收的数据不发生溢出掉失。

在陈明计的书上有介绍,是刚开始的几页书的一个例子<嵌入式实时操作系统SMALL RTOS 原理及应用>

本来就该如此吗!
有啥讲头?

我的串口就是这种方式，不过速率低，4800，数据多，120个字节，所以分成了几组，保证每组数据不要超过通讯量，在增加一个协议。

采用fifo方式，有效地设计接收缓冲区的长度，一般来说，可以解决接收数据溢出的问题，

除非主处理程序对缓冲区的数据处理太慢。

俺对一下
“写延时函数，第一反应是采用定时器，用结构体管理”，采用定时器延时，优点只有用的人才知道，利用Nop循环来延时，太浪费了，而且有多个定时器任务要求同时启动，分时到达时，不用定时器几乎无法实现。

加入我的发送缓存是 20个字节
然后刚开始的程序不断的 printf向UART送数据
用FIFO将数据压入这20个字节的缓冲区
如果连续执行大量的 printf 函数的话（加入我需要送200个字节的数据）
这个缓冲一下子就满了。那么这个时候应该怎么做呢？
显然将数据压进去队列的时间比UART发送的时间短很多。
是不是应该停下来等待队列有空位的时候再插入数据？
如果是操作系统的话应该切换任务吗？
加大缓冲区是个解决办法，但是用的不多，浪费RAM（动态分配？）

请指教指教。

单任务（或只多任务中只一个任务）发送数据，可以先检查队列状况，用状态任务号进行状态之间的延时处理,分解发送。

多任务发送的时候，必定加大缓冲区。都多任务了，怎么可能一个任务中死占着串口不放？


switch( task )
{
   case....
}
就能办得到，而且支持多任务运行。

常见BOOTLOADER，原DOS下也这样，使用环境条件是一个最典型的单任务，这时候爱用查询就用查询。

采用中断+队列，可以支持多任务，几乎所有驱动都是这样做的。产品中更应该这样做。

中断+队列

我用的中断+数组.好原始阿..

还没有领会队列的精髓.所长传授哇