文件名称：神舟IV号的UCOS使用基本例程
文件大小：8.46MB
文件格式：RAR
更新时间：2014-10-16 16:23:58
UCOS STM32 STM32F107 神舟IV
本人原创，包括各个例程，希望与大家一起交流，转载请声明，谢谢！ BSP文件夹为各类驱动，各个工程文件夹里的APP对应着各自的应用程序及配置。 注意，这些工程是在IAR 6.10.5下建立的，请使用该版本或更高的版本打开， 否则原有配置将被重置，编译时会出错。当然，如果你知道怎么配置的话，也 就无所谓了。 1、FirstLED 只是将官方的例程的管脚重新定义了一下， 另外将原来STM32的库函数由2.0升级为3.4。 现象是神舟IV号上的3个LED灯以0.5s的间隔闪烁； 2、Sem 为UCOS II信号量的使用提供一个参考 任务AppTaskKeyScan每50ms扫描KEY2状态，若KEY2按键按下， 则释放信号量激活任务AppTaskSem，使LED2状态反转 3、Mbox 为UCOS II邮箱的使用提供一个参考 任务AppTaskKeyScan每50ms扫描KEY2状态，若KEY2按键按下， 则向邮箱发送1个字符，同时字符加1(即A->B->C...->Z->A)， 任务AppTaskMbox当邮箱非空时获取邮箱内容并通过串口1输出。 有一个细节在此说明一下，本工程中AppTaskMbox的优先级比 AppTaskKeyScan的优先级高，这样保证了在字符递增前输出 即AppTaskMbox会抢占AppTaskKeyScan。这间接地说明了， 发送邮箱时是把内容的地址指针给了邮箱，而不是内容本身。 读者可以自己试着把两个任务优先调换，会发现，第1个字母 A将无法输出。 4、Mutex 为UCOS II互斥型信号量的使用提供一个参考 任务AppTaskKeyScan每50ms扫描KEY2状态，若KEY2按键按下， 则向邮箱发送1个字符，同时字符加1(即A->B->C...->Z->A)， 任务AppTaskMbox当邮箱非空时获取邮箱内容并通过串口1输出。 由于AppTaskMbox的优先级比AppTaskKeyScan高，所以一旦 AppTaskKeyScan向邮箱发送了内容，系统会马上调度使 AppTaskMbox先运行。但本例中使用了互斥型信号量，在 互斥型信号量释放前，尽管AppTaskMbox优先级高，但并不 优先调度。读者可以这样进行验:该工程默认情况下使用互斥 型信号量，直接编译运行，可以看到串口先输出"Mutex Test" 而后输出字符'A'等；若将两个任务中的OSMutexPend，OSMutexPost 语句注释掉，则可以看到先输出字符后输出"Mutex Test" 5、Flag 为UCOS II事件标志组的使用提供一个参考,同时使用了邮箱广播功能 任务AppTaskTx向邮箱广播发送1个字符，而后等待两个接收 任务接收完成并将相应的标志位置1，当相应位均置1后， 字符递增，并广播，如此循环。为了验证标志组的作用， 读者可试着将其中的一个接收任务的OSFlagPost注释后观察。 6、Queue 为UCOS II消息队列的使用提供一个参考 任务AppTaskKeyScan每50ms扫描KEY2状态，若KEY2按键按下， 通过消息队列发送消息"Key Down!"，任务AppTaskQueue 将接收消息队列中的消息并通过串口输出。与邮箱类似， 消息队列也可广播，这里不具体示例，请读者自行编写程序 7、KeyExti 为UCOS II中断的使用提供一个参考 任务AppTaskKeyScan每50ms扫描KEY2状态，若KEY2按键按下， 通过消息队列发送消息"Key2 Down!"，任务AppTaskQueue 将接收消息队列中的消息并通过串口输出。该工程使能了 外部中断0，与按键WAKEUP相连，当该按键按下时向消息 队列发送消息"Key Wakeup Down!"。可以看到，中断比扫描 更灵敏，按一次，有时会发送多次消息(因为没有消抖) 8、StackCheck 为UCOS II检查堆栈和CPU使用率提供一个参考 程序运行后，串口每隔1秒打印出每个任务的堆栈使用情况 和该程序的CPU使用率。若不想检查堆栈并打印，将宏定义 #define DEBUG_CHECK_STACK 注释掉即可。 任务需要运行足够长的时间，并要考虑各种情况，才能得到 正确数据。最后确定的堆栈大小，还须考虑今后的扩展， 一般多分配10%－25%，或者更多。如果系统对稳定性要求高， 则应该多1倍以上。通过堆栈检查操作，得到的是曾经被使用 过的堆栈区域的大小，而不可能得到完全精确的实际使用情况。 本例中，读者可以对比一下按键按下前后AppTaskQueue的 堆栈使用情况，可以发现有明显的区别。 CPU使用率的精度是1%.