移植uCOS-II到C51 - 2

现在再来回顾一下要今天要弄清楚的几个问题：
1）任务堆栈如何设计，如何初始化（保存那些内容，放在什么地方）
2）任务切换何时发生，如何发生（现场保护和恢复）

先来看看uCOS-II移植到80x86PC的版本。
No.1 堆栈的分配
每个任务都分配了一块的RAM空间，这个没啥好说的。分配时数据类型为OS_STK，与编译器相关

No.2 堆栈的初始化
由OSTaskStkInit()函数完成，这一点从函数的名称就能看出来了。这个函数是在OSTaskCreate()中被调用的。“将堆栈的结构初始化成看起来好像刚刚发生过中断一样”，嗯，这句话说得太形象了。看看这个函数都做了些什么：从栈顶位置开始，顺次模仿任务的调用，模仿中断，模仿PUSHA，模仿PUSH ES，最后是模仿PUSH DS。那么，任务被调度的时候会发生些什么呢？以上的事情会被重做，只是顺序刚好相反。这个顺序应该要保证任务可以正常的、从第一条语句开始执行。看看OSCtxSW()后半部分的代码就会知道情况是不是这样。我们每个任务都有一个任务控制块OS_TCB，OS负责管理这些OS_TCB，当任务被挂起时，OS_TCB保存了任务的状态。OS_TCB的第一个成员就是一个指向任务栈顶的OS_STK*指针（这个成员在OSTaskCreate()函数中用OSTaskStkInit()函数的返回值初始化）。当确定要被调度的任务（已就绪的优先级最高的那个）以后，从对应的OS_TCB中取得栈顶指针，然后写入堆栈寄存器SS和SP，然后是POP DS, POP ES, POPA, IRET，正好与OSTaskStkInit()所做的相反。此时，CS:IP指向了任务的入口地址，而SS:SP指向任务的返回地址（实际没有意义，因为每个任务都是死循环，不会返回），SS:SP+4指向任务的参数地址。“看起来像是任务被一个普通函数调用了”，只是这个主调函数并不存在。

No.3 任务切换何时发生
这一点现在看也很清楚，每个任务都会在执行一段代码后主动放弃对CPU的控制权，这时候就可以进行任务切换了。比如OSTimeDly()函数会调用OS_Sched()，使就绪状态中优先级最高的任务恢复执行。

No.4 现场保护和恢复
现场的保护，我想应该和OSTaskStkInit()函数所做的差不多，只不过模仿中断的部分，入栈的应该是CS:IP。现在来看OSCtxSW()函数的前半部分代码：PUSHA, PUSH ES, PUSH DS...让我们把整个过程串起来看看到底怎么回事。首先，一个任务调用OSTimeDly()将自己挂起，OSTimeDly()调用OS_Sched()，OS_Sched()确定要恢复执行的任务，然后调用OS_TASK_SW()，这是一个被定义为asm{INT 0x80}的宏，而0x80的中断向量就是OSCtxSW()。由于在执行INT这条软中断指令时，中断返回地址和PSW已经被压栈了，因此在OSCtxSW()中省去了这些步骤。哈哈，果然是这样！至于现场的恢复，就是OSCtxSW()后半部分代码所做的工作，这在No.2中已经说明过了。　 

下午，测试通过了一个移植好的uCOS-II v2.52版本，虽然只是在PC上模拟，还是颇费了一番周折。这个版本来自Stuart Wright，可以从www.uCOS-II.com 下载（如果这个网站打不开，可是试试www.micrium.com ）。这份文件有些小小的错误，In my opinion，仅供参考：
1）文件 Readme.txt 第88、92、113行的 os_kcdef.h 应为 OS_KC51.h
2）文件 uCOS-II.h 第481、482行的 code 应为 const（否则编译时会发生redefinition错误，排除这个错误花了我可能有半小时时间。。。）

明天，看看C51的汇编指令参考，把SW的版本（MCU为Dallas 80C390）修改一下，应该就能在我自己的平台上工作了。工程模板也需要研究一下，那么多.C .H文件放在同一个文件夹下看起来实在是太乱了。。。