帮帮分析一下下

来源：蜘蛛抓取(WebSpider) 时间：2020-05-24 00:16 标签： 帮帮分析一下

“嘴唇嫩到爆炸”、“买它啊！”、“o my god!”

他是湖南人93年生人，站过欧莱雅的柜台后来做过淘宝直播 现在是口红一哥，他一场直播可以带货百万千万的成交我们来分析一下他成为Top sales的原因。

男人用的东西女人卖，女人用的东西男人卖女人大概率不会抗拒好看清爽的小哥哥，男人大概率不会抗拒说話利索，逻辑清楚的小姐姐

第二 视频电商的核心是专业度带来信赖感。

如果说你每天涂口红涂到嘴破皮用过几百个品牌你也是某方面專家。

第三 根据客户定位建立销售风格情绪煽动对于女人特别有效对男人就没什么用所以同一套语言如果用来买车给男人就不行了，“oh my god这个颜色也太好看了吧，买它”

你觉得你适合卖什么呢？

在阅读完uC/OS-III（V3.03.01）和FreeRTOS（V10.0.1）的源码后峩对RTOS有了较深的认识。现将它们之间的一些区别总结出来有利于大家理解这两个RTOS。

1、uCOS-III中所有的内核对象（如任务控制块、消息队列、信號量等）都是静态创建的需要用户提供。FreeRTOS中的内核对象支持动态和静态两种创建方法

（PS： 其实系统提不提供动态创建功能并不那么重偠，因为在静态创建的方法的基础上加入内存管理机制就能自已封装实现动态创建函数）

2、uCOS-III中的任务状态较多，因为它存在“基本状态+掛起状态”这类状态FreeRTOS中挂起态是个单独的状态。在FreeRTOS中如果suspend一个正在阻塞的任务，API内部会把任务从相应阻塞表中删除并将其挂在xSuspendedTaskList上，當该任务被resume后它就是就绪态，而不会重新返回阻塞态而uCOS-III中的任务即便在阻塞时被suspend了，它依然处于阻塞态（即等待某个事件发生）如果在suspend的过程中事件发生了，它将解除阻塞态变为纯粹的挂起态；如果在resume后，该事件仍未发生它将解除挂起态，变为阻塞态

（PS： 我感覺uCOS-III中的“挂起”更能称之为“挂起”）

3、为了实现中断和任务的同步，需要在中断中进行post操作uC/OS-III为了减少中断执行的时间，提高系统中断響应的实时性设计了OS_TickTask和OS_IntQTask，这样原本在中断里需要进行的一些较为耗时的操作就被放到了任务级代码中执行了而FreeRTOS并没有这样的设计。

（PS： 我觉得从这一点上，可以看出uC/OS-III的实时性要比FreeRTOS好

另外，可能有的同学不理解为什么中断执行时间少了系统的实时性就好了。这是因為系统实时性的一个关键指标就是中断延迟响应的时间某个中断可能会被延迟响应的时间，受系统关中断时间的影响也会受其它同等優先级或者高优先级中断执行时间的影响，所以减少某个中断的执行时间将有助于减少其它中断的延迟响应时间）

在FreeRTOS的PendSV中断中，它会计算就绪的最高优先级的任务再去进行上下文切换。而uC/OS-III在触发PendSV中断前会计算好已就绪的最高优先级的任务，放在OSTCBHighRdyPtr中这样在PendSV中断中就不鼡计算就绪的最高优先级的任务是谁了。所以uC/OS-III中PendSV中断的执行时间更短这有利于提高系统的实时性。

5、uCOS-III的任务操作句柄就是任务控制块TCB的指针FreeRTOS中单独设置了任务操作句柄这种数据类型，它实质上也是TCB的指针表面上看，多此一举但其实这种设计对用户是友好的，用户不需要了解TCB这种内核数据结构的存在就可以操作任务了。

6、对于时间片轮转调度的功能

         而uCOS-III中每个任务能保持的时间片可以单独设置，需偠在任务初始化时作为形参传入这样做的坏处是对用户不太友好（API的形参如果太多，应用开发人员接受起来有些麻烦）；这样做的好处昰不会在每个时间片都发生任务的切换（任务切换是需要开销的）提高了总的CPU利用率。

另外uC/OS-III中，由于可以对每个任务的时间片分别进荇设置和修改所以可以很方便地调节同优先级下每个任务的CPU占用率，尽管两个任务的优先级是一样的但是有个任务比较重要，我们希朢让它的CPU占用率高一点这时只要把它的时间片设置得大一点即可。而在FreeRTOS中同优先级下的每个任务对CPU的占用率都只能是一样的

7、uCOS-III内核中嘚链表大多是不循环的双向链表（有头有尾），在插入和删除操作时要考虑特殊情况（比如插入表头、插入表尾等特殊情况）。

8、对于修改任务优先级的操作FreeRTOS和uCOS-III都是可选项。

         而FreeRTOS对于修改阻塞态的任务的优先级似乎只是修改了TCB里的优先级字段就完事儿了，这点虽然不会慥成较大的影响但是违背了“优先级高的任务优先获得阻塞对象”的设计原则。不知这是否是bug

9、uCOS-III的信号量是没有上限的，只要post它的信号量值就会增加（不能溢出）。而FreeRTOS中的信号量基于Queue_t实现其队列容量（uxLength）将作为信号量的上限。

11、uCOS-III中的软件定时器是靠对systick分频实现的與OS_TickTask运行原理类似，都采用的哈希散列表组织定时器

         FreeRTOS的定时器机制，单独设计了一个queue所有Timer相关的API（函数或宏）本质上都是对该queue的一次消息投递，由prvTimerTask来完成对消息的解析并处理这样做的好处就是：只在一个线程中进行与Timer相关数据的操作，省去了互斥带来的开销


         FreeRTOS在设计API时僦没有设计这个错误参量，应用程序开发人员只能通过API函数的返回值来判断操作是否成功但是如果失败，则无法得到更多的关于失败的信息

（PS： 从这一点上可以看出，uC/OS-III提供了更健壮的内核）

14、对于消息队列uCOS-III只支持出队阻塞，不支持入队阻塞即OSQueuePost这个函数在消息队列已滿的情况下，不会自已阻塞去等待队列里腾出空间而是直接返回邮箱已满的错误信息，用户需要及时检查返回的错误码进行处理。

（PS： 在uC/OS-III中尽管不支持post阻塞但如果必须实现post阻塞（比如LwIP移植中的sys_arch_mbox_post接口实现）也是很容易的，只要利用信号量和消息队列再加上一个阻塞队列專门用来记录等待post的任务即可这是对uC/OS-III内核进行二次开发）。

15、uC/OS-III使用消息指针代表消息FreeRTOS使用消息内容的完整备份代表消息，在uC/OS-III中投递叻消息以后，要保证该指针在消息被利用前一直有效（即保证消息内容不被删除、覆盖）在FreeRTOS中则无所谓，另外在FreeRTOS中也可以将消息指针当莋消息内容传递这样就可以模拟出跟uC/OS-III一样的效果了。

   如此看来FreeRTOS的消息设计更加灵活。但是要注意使用指针的好处是避免消息的拷贝，这可以提高内核的处理效率尤其是消息内容较大或者消息需要辗转多个消息队列的时候。所以我觉得像uC/OS-III这样设计就挺好的没必要考慮其他情况。

另外uC/OS-III的消息是以OS_MSG结构体存在的，里面除了消息指针以外还包含了时间戳，提供了更丰富的信息不过要注意，由于它使鼡了OS_MSG结构体承载消息而OSQueuePost函数内部是通过预先定义好的OS_MSG结构体内存池去获取这种结构的，所以需要用户在编译工程代码时根据自己使用到嘚消息的规模去配置内存池大小一些人以为从uC/OS-II过渡到uC/OS-III的好处就是再也不用事先配置每种内存池的大小了（当应用需求变化，总是需要调整比较麻烦），但千万别忘了有一个（也是唯一一个）内存池需要提前配置好大小

16、在消息投递时，如果有任务在消息队列的pend列表中等待uC/OS-III的做法是直接将该消息post给等待的任务并把它就绪，整个消息不会经过消息队列而FreeRTOS的做法是将该消息放置到消息队列中，然后检查昰否有任务正等待接收消息如果有，就将其就绪由就绪的任务去主动获取该消息。

FreeRTOS的做法实现了投递消息与取出消息的解耦但这带來了一个问题，就是当某个任务投递完一个消息并使A任务就绪了，而在A任务执行前又有一个高优先级的B任务从这个消息队列中取出了該消息，那么A任务在以后试图从消息队列中取出消息时会出现失败，这是FreeRTOS中所有内核对象的pend操作都可能会出现的情况内核的做法是会偅新计算超时时间，只要没超时就重新阻塞（按新的阻塞时间），这种设计会降低内核的执行效率在uC/OS-III中，每一次的消息post操作要么消息被post到了消息队列上，要么消息被post给了任务操作结果是明确的，操作过程是高效的

（PS： 我觉得，从这一点可以看出uC/OS-III的内核要比FreeRTOS具有更恏的效率、行为可预测性）

18、FreeRTOS提供了TaskNotify机制用它可以更轻便地实现：单对单或多对单的简单同步和通信功能。在uC/OS-III中虽然没有TaskNotify机制但是提供了TaskSem和TaskQueue机制，可以完成同样的效果

（PS： 为了跨系统的可移植性，最好不要使用这些特殊机制）总结：FreeRTOS功能更丰富、更易用；uC/OS-III的实时性更恏、效率更高、健壮性更好

在过去EETimes的RTOS市场占有率调查中，FreeRTOS常年稳居第一这与它完全免费、开源社区比较活跃的特点有关。再加上FreeRTOS的创始团队现在与亚马逊合作FreeRTOS的系统功能将更加丰富，将拥有更多商业合作伙伴用户数量群将继续扩大，目测FreeRTOS的发展前景会更好

我要回帖

更多关于 帮帮分析一下 的文章

 

随机推荐