实时系统的设备驱动实现

        第一是笔者看到了关于RTOS驱动开发介绍的文章，作者的特点是从系统的层次上分析问题（为大家铺路），好东西大家一起用（博大的胸襟）；第二是笔者能够看懂一些,分享一下，争取做到准确...

        笔者一位低一年级的同学参加过嵌入式软件的培训，告诉我他学过ARM板上写Linux驱动，我很羡慕，因为写驱动是比较难的事情，这里思考的是UCOS的驱动设计 ，至今没做过Linux驱动。
        设备驱动一般包含2个方面：一个是任务级的处理，另一个是中断处理。对数据的处理以及上述2个方面的协调，是非常重要的，而且需要解决很多细节问题。
设备驱动的两个方面
许多设备驱动都支持中断。事实上，如果设备驱动编写时不考虑中断，就容易很多。这是因为编写无中断支持的设备驱动更为简单，如果学会了怎样编写支持中断的驱动，那么其他的实现也就轻而易举了。先简单回顾一下设备驱动的基础：初始化，发送，接收，控制，关闭。这根本没什么难的！大多数情况下，设备驱动就这么些内容，当然也可以添加一些额外的错误处理，或者提供一个ioctl()函数，但最主要的就是能够收发数据。没什么太复杂的！那为什么我们在编写设备驱动时，总觉得被束缚而难以开始呢？这一般是因为，在正常工作之前，除非有一些适合的工具，否则不能看到设备在做什么。但是，如果有正确的框架，让设备工作起来还是很容易的。
        在RTOS下，我们所说的设备驱动的两个方面是指什么呢？一方面是任务环境的接口（API），另一方面是中断服务及相关处理。协调这两方面的潜在问题是什么呢？一个是数据破坏;另一个是任务调度。数据破坏如没有二次访问的保护；任务调度，不合理的任务调度，可能导致系统崩溃。

使用UCOS的互斥信号量机制实现串口驱动的设计

void OutputByte(char c)
{
 OSMutexPend(&Recmutex,0,&err);
 USARTSendChar(c);
 while(status);                //等待发送完毕
 OSMutexPost(&Recmutex);
}
这里串口资源只有一个，互斥信号也是一个，以下串口资源等同于一个互斥信号。
1.互斥信号量申请到资源时会锁定该信号（flag = 0），使用完成后用OSMutexPost来释放信号(flag = 1)。
2.如果当前任务申请该信号时，该资源未被释放（flag = 0），就将当前任务放到消息等待队列中并挂起当前任务。
3.OSMutexPost函数首先检查有无任务等待该信号，有则唤醒等待队列中优先级最高的任务，没有就释放信号（flag = 1）。

这里面为什么看不到中断服务呢？

Colin Walls给的中断例子
void OutputCharacter(char c)
{
 if(PortReadyFlag != TRUE)
 {
  AddToPortWait(ThisTaskID);  //
  SuspendTask();
 }
 PORTOUTPUT = c;
}
这段代码检查现在是否可以输出字符。如果不能，他将建立一个机制，使得当该端口就绪时，中断服务（ISR）例程能通知该任务，然后当前任务被挂起，直到知道端口有效，输出字符。这里所谓的机制（端口就绪时，触发中断服务，ISR例程能通知该任务）可以通过配置相应的串口中断实现。
针对这个端口的ISR
interrupt void WriterPort(void)
{
 TASKID tid;
 PortReadyFlag = TRUE;
 tid = GetFromPortWaitList();
 if(tid!=NULL)
 {
  PortReadyFlag = FALSE;
  ResumeTask(tid);  //使该任务就绪
  RunScheduler(); //任务调度
 }
}
这是另一种设备驱动的实现方式，由于使用了中断，实时性很高。这里也回答了上面的例子看不到中断，原因是UCOS是抢占式任务调度，只需将对应任务设为就绪状态，就能执行到该任务（当无更高优先级的就绪任务时），无需自行切换到该任务。

总结：这里介绍的是实时系统的设备驱动实现，当用到多任务调度时，应该对相应的外设包装，确保不会发生冲突和系统崩溃。对于Windows和Linux设备驱动的实现原理，笔者没见过。不论哪种系统，如果所以设备驱动都按统一的模板来编写，可以减少很多麻烦。
所涉及内容参考书籍

Colin Walls的《嵌入式软件概论》（我见过最好的“概论”了）

邵贝贝译的uc/os II （第二版）