为什么我们需要uCos

logo

接触ucos有段时间了，感觉之前以裸机的形式写程序浪费了不少时间，后悔知道晚了。在不断了解熟悉ucos的过程中也逐渐体会到操作系统的强大之处。
实际上我起初刚开始接触ucos是在10年前（2013年），那个时候买了一本UCOS-II，邵贝贝的书。


尽管当时我并不清楚上了UCOS以后相对裸机程序有什么好处，当时也是看网上有人用，就跟风学习。就好比学生上学漫无目的的学习，不知道所学专业将来有什么用的，这样就很难真正的学好。就相当于没有目标的在学习，那样学习的动力也不足。我也不例外。这本书买回来我大概翻看了下，感觉很陌生。就放那里吃灰了，压根没看进去。直到最后由于换工作搬家，觉得这书吸收不了于是给免费送给论坛网友了。之后也就不了了之了。
直到2022年看网上各种开发板配套的各种例程里面都带有UCOS，最关键我发现了使用UCOS以后相较于裸机程序，程序结构变的更加有调理了。而以往用裸机写的程序我发现随着功能的不断增加，每次修改感觉都很痛苦。程序各个功能之间耦合严重。正是在这种情况下，我决定把以往的裸机程序尝试修改为带UCOS系统的程序。
从一开始的买了一本书，感觉看着很陌生，不知道怎么下手。到后来的决定把裸机程序修改为带UCOS系统的程序。这中间时间将近过了10年（2013年到2022年）。
想要使用UCOS首先要解决的问题就是对应目标芯片的移植。正是这样一个移植的工作，把许多试着去使用UCOS的编程者拒之门外。我也不例外，UCOS给我的第一心里印象就是移植的繁琐。我一开始移植遇到各种问题，自己好几次都想放弃了。我只是想使用UCOS给我写程序带来的便利性。而不想去理解你内部是怎么搞的。比如什么信号量等等名词。对于刚开始接触学习UCOS的我来说感觉学习了解这些概念是个痛苦的过程。不过好在此时我已经属于有目的的学习了。因为我知道使用系统以后，让我们的程序编写更容易，或者说是更高大上一些。就这样一路磕磕绊绊，把原来的写的裸机程序逐渐改成了带有UCOS的程序。这个过程中也逐渐熟悉了解了UCOS的基本用法。后面有时间还要深入了解下。书读百遍其意自现。


以下转自网上的文章。我觉得写的也很好，如果我能早点发现类似这这样的文章，也会早点被启发入门上手UCOS，因为下面文章描述的内容也是我自己亲身经历过的。
****************************************************************************************************************************************
为什么我们需要uCos
知道uCos是在2010年的暑假，老师要我为毕业设计选一个课题，要求有关嵌入式实时操作系统，于是开始在网上搜索，顺理成章的就发现了uCos，于是开始了uCos之路，但后来由于硬件平台的问题，毕设没有用uCos，而用了另外一个不开源的。
毕业后，做的项目用到过RTX51，uCos，linux，当做linux下的项目时，研究过一阵子linux的源码，后来又一天，闲来无事再去看uCos的源码时，突然发现uCos里的一些原理，对于理解和构建一个操作系统这这么的经典和透彻！于是我觉得是时候再好好理解和整理下uCos里的一些原理了。
我相信这样的整理对于更透彻的理解RTOS定会有好处，如果确实没什么收获，就当是打法时间吧！
我觉得第一个要解决的问题是，为什么我需要uCos？就像最开始学C编程时，老师告诉我，指针很重要，我那时就有一个大的疑问，指针到底有什么好？还一边在心里嘀咕着：我不用指针不一样把程序编出来了？现在想想c语言没了指针，将寸步难行！回到正题，我们到底为什么需要uCos？
一般的简单的嵌入式设备的编程思路是下面这样的：
main
{
{处理事务1}；
{处理事务2}；
{处理事务3}；
.......
{处理事务N}；
}
isr_server
{
{处理中断}；
}
这是最一般的思路，对于简单的系统当然是够用了，但这样的系统实时性是很差的，比如“事务1”如果是一个用户输入的检测，当用户输入时，如果程序正在处理事务1下面的那些事务，那么这次用户输入将失效，用户的体验是“这个按键不灵敏，这个机器很慢”，而我们如果把事务放到中断里去处理，虽然改善了实时性但会导致另外一个问题，有可能会引发中断丢失，这个后果有时候比“慢一点”更加严重和恶劣！又比如事务2是一个只需要1s钟处理一次的任务，那么显然事务2会白白浪费CPU的时间。
这时，我们可能需要改进我们的编程思路，一般我们会尝试采用“时间片”的方式。这时候编程会变成下面的方式：
main
{
{事务1的时间片到了则处理事务1}；
{事务2的时间片到了则处理事务2}；
.......
{事务3的时间片到了则处理事务N}；
}

time_isr_server
{
{判断个事务的时间片是否到来，并进行标记}；
}
isr_server
{
{处理中断}；
}
我们可以看到，这种改进后的思路，使得事务的执行时间得到控制，事务只在自己的时间片到来后，才会去执行，但我们发现，这种方式仍然不能彻底解决“实时性”的问题，因为某个事务的时间片到来后，也不能立即就执行，她必须等到当前事务的时间片用完，并且后面的事务时间片没到来，她才有机会获得“执行时间”。
这时候我们需要继续改进思路,为了使得某个事务的时间片到来后能立即执行，我们需要在时钟中断里判断完时间片后，改变程序的返回位置，让程序不返回到刚刚被打断的位置，而从最新获得了时间片的事务处开始执行，这样就彻底解决了事务的实时问题。
我们在这个思路上，进行改进，我们需要在每次进入时钟中断前，保存CPU的当前状态和当前事务用到的一些数据，然后我们进入时钟中断进行时间片处理，若发现有新的更紧急的事务的时间片到来了，则我们改变中断的返回的地址，并在CPU中恢复这个更紧急的事务的现场，然后返回中断开始执行这个更紧急的事务。
上面的这段话有些不好读，事实上，这是因为要实现这个过程是有些复杂和麻烦的，这时候我们就需要找一个操作系统(OS)帮我们做这些事了，如果你能自己用代码实现这个过程，事实上你就在自己写操作系统了，其实从这里也可也看出，操作系统的原理其实并不那么神秘，只是一些细节你很难做好。uCos就是这样一个操作系统，她能帮你完成这些事情，而且是很优雅的帮你完成！
到这里，我们终于知道了为什么我们需要uCos了。事实上，uCos的用处远不止帮你完成这个“事务时间片的处理”，她还能帮你处理各种超时，进行内存管理，完成任务间的通信等，有了她，程序的层次也更加清晰，给系统添加功能也更方便，这一切在大型项目中越发的明显！
我们知道了uCos能给我们提供这么多的遍历，那么我们就开始使用uCos吧！

morning_enr6U

eric2013

经典