为什么要同ucos？

sxy4517

为什么要同ucos？ [复制链接]

 为什么我需要uCos？就像最开始学C编程时，老师告诉我，指针很重要，我那时就有一个大的疑问，指针到底有什么好？还一边在心里嘀咕着：我不用指针不一样把程序编出来了？现在想想c语言没了指针，将寸步难行！回到正题，我们到底为什么需要uCos？一般的简单的嵌入式设备的编程思路是下面这样的：main{{处理事务1}；{处理事务2}；{处理事务3}；
.......{处理事务N}；}isr_server{{处理中断}；}这是最一般的思路，对于简单的系统当然是够用了，但这样的系统实时性是很差的，比如“事务1”如果是一个用户输入的检测，当用户输入时，如果程序正在处理事务1下面的那些事务，那么这次用户输入将失效，用户的体验是“这个按键不灵敏，这个机器很慢”，而我们如果把事务放到中断里去处理，虽然改善了实时性但会导致另外一个问题，有可能会引发中断丢失，这个后果有时候比“慢一点”更加严重和恶劣！又比如事务2是一个只需要1s钟处理一次的任务，那么显然事务2会白白浪费CPU的时间。
这时，我们可能需要改进我们的编程思路，一般我们会尝试采用“时间片”的方式。这时候编程会变成下面的方式：main{{事务1的时间片到了则处理事务1}；{事务2的时间片到了则处理事务2}；
.......{事务N的时间片到了则处理事务N}；}time_isr_server{{判断每个事务的时间片是否到来，并进行标记}；}isr_server{{处理中断}；}我们可以看到，这种改进后的思路，使得事务的执行时间得到控制，事务只在自己的时间片到来后，才会去执行，但我们发现，这种方式仍然不能彻底解决“实时性”的问题，因为某个事务的时间片到来后，也不能立即就执行，她必须等到当前事务的时间片用完，并且后面的事务时间片没到来，她才有机会获得“执行时间”。
这时候我们需要继续改进思路,
为了使得某个事务的时间片到来后能立即执行，我们需要在时钟中断里判断完时间片后，改变程序的返回位置，让程序不返回到刚刚被打断的位置，而从最新获得了时间片的事务处开始执行，这样就彻底解决了事务的实时问题。
我们在这个思路上，进行改进，我们需要在每次进入时钟中断前，保存CPU的当前状态和当前事务用到的一些数据，然后我们进入时钟中断进行时间片处理，若发现有新的更紧急的事务的时间片到来了，则我们改变中断的返回的地址，并在CPU中恢复这个更紧急的事务的现场，然后返回中断开始执行这个更紧急的事务。
上面的这段话有些不好读，事实上，这是因为要实现这个过程是有些复杂和麻烦的，这时候我们就需要找一个操作系统(OS)帮我们做这些事了，如果你能自己用代码实现这个过程，事实上你就在自己写操作系统了，其实从这里也可也看出，操作系统的原理其实并不那么神秘，只是一些细节你很难做好。
uCos就是这样一个操作系统，她能帮你完成这些事情，而且是很优雅的帮你完成！
uCos的用处远不止帮你完成这个“事务时间片的处理”，她还能帮你处理各种超时，进行内存管理，完成任务间的通信等，有了她，程序的层次也更加清晰，给系统添加功能也更方便，这一切在大型项目中越发的明显！我们知道了uCos能给我们提供这么多的便利，那么我们就开始使用uCos吧！

247153481

这就是使用rtos的好处了，不过也会有一些相应的负担

战国风云儿

我现在在学习UCOS III，目前还在学习一些关键部分的源码。其实有时候也在想，这个操作系统能干嘛呢，我说不上来，毕竟在这方面没有使用过，没有很深的体验和思考。现在看了你的解释，有那么一点点理解了。

sxy4517

247153481 发表于 2015-3-5 10:42
这就是使用rtos的好处了，不过也会有一些相应的负担

比如呢？

sxy4517

战国风云儿 发表于 2016-8-9 21:22
我现在在学习UCOS III，目前还在学习一些关键部分的源码。其实有时候也在想，这个操作系统能干嘛呢，我说不 ...

开始学习III了啊，赞一个！

steven.zhang

sxy4517 发表于 2016-12-24 08:26
比如呢？

资源占用