392|4

4209

帖子

233

资源

管理员

颁奖:跟着cruelfox,打卡学习FreeRTOS的获奖者们、他们的学习分享

活动详情:点此查看

首先,特别感谢cruelfox在赶公司项目的同时,及时给出了每站思考任务。

稍晚些,cruelfox还会解读一下每站任务,我会更新整理到此帖内,感兴趣的网友可以关注本帖更新。

同时也要感谢网友们的积极参与,欢迎大家跟帖反馈对本活动的意见感受和建议,我们都会认真查看并在策划相关活动时参考、借鉴。综合cruelfox推荐意见,本次活动评选结果如下。

 

优秀打卡奖

*以下网友更新个人信息后,跟帖告知已更新信息。我们将按照论坛资料里的相关邮寄信息,安排礼品邮寄

abc9981 所获奖品:小米蓝牙耳机Air
我的学号 所获奖品:小米蓝牙耳机Air
superstar_gu 所获奖品:小米插排

 

他们分享的笔记如下:

网友用户名 第一站:应用场景 第二站:栈—任务切换的关键 第三站:任务状态及切换 第四站:任务间的通信 第五站:中断与任务切换 第六站:实验-串口后台打印 第七站:大作业
abc9981 应用:数据网关(数据集中器)
功能:故名思意,主要功能就是汇总终端设备数据,统一上报之后台,根据终端设备的类型不同,数据网关将调用的硬件资源也是不一样的
例如:2路串口,1路无线,1路iic采集数据,1路spi数据存储,同时还要处理后端发送的指令,及定时上传数据至后台
在没有rtos情况下,可按流程进行数据处理,但是数据采集过程中肯定会出现通信超时等情况导致资源分配不均,以及无法及时处理后台数据等问题
引入rtos架构
1、能合理分配等待的空闲时间的资源
2、代码简单化,在硬件资源独立的情况下只需要考虑当前任务的处理逻辑
3、机动性更高了,当需要添加一路数据采集是,直接添加一个任务,并不影响其他任务运行
具体任务划分
任务1,串口1数据采集,由于串口资源属于硬件资源,为了减少硬件资源在不同任务间调用可能会出问题,所以独立开一个任务
任务2,串口2数据采集,
任务3,无线数据采集
任务4,iic数据采集
任务5,数据汇总及数据存储
任务6,后台通讯处理
个人觉得这章应该是RTOS的核心

正常裸奔基本不考虑堆栈问题,只有调用中断的时候会调用到栈的功能,正常使用比较多的也是定义变量,动态内存使用的也比较少

当使用了RTOS就无时不刻的在调用堆栈,TCB基本就是动态获取堆,任务切换就要一直压栈出栈,同时还要考虑到系统中断的堆栈调用

这里RTOS针对各任务的整个堆栈操作,就要是由任务调度器来完成,整个过程大概就是

保存任务1现场,恢复任务2现场,保存任务2现场,恢复任务1现场不断的切换

 

什么是现场呢,就是CPU运行状态寄存器

51与contex-m核其实比较大的区别就是现场的不同,51的资源相较于contex-m的资源要少,cpu调用的寄存器也少,可以理解为现场小,所以在保存现场的数据上,contex-m是会比51要大一些的

 

以上为个人理解,如果理解有误,请大家指正,其实看这章也是挺懵的,查了很多资料,希望大家相互交流共同进步
思考题: 在FreeRTOS任务程序中,常使用 xTaskDelay() 函数来达到延时执行的目的。若在某一个任务里调用了 xTaskDelay(20), 想等待20个时间单位,结果这一回延时操作却超过了25个时间单位。请分析有可能是哪些原因造成的?

答:首先这个xTaskDelay(20),20个时间单位肯定是硬吃的,毋庸置疑,主要是要分析后面这个多出来的5个时间单位被谁吃了。

1、被更高优先级抢占,就是当前任务到等到19个时间单位时,有一个高优先级任务抢占资源,运行了6个时间单位才释放资源

2、被同优先级抢占,当前任务到等到19个时间单位时,有一个同优先级任务正好在就绪态,肯定时可以接手资源运行6个时间单位再释放资源

3、被中断吃了,不管是裸奔还是,上rtos硬件中断始终优先级是最高的,正常编程过程中,我们是不会再中断中做了很多东西,但不排除有些人在中断中写了应用代码,甚至写了延时函数
本次学习主要针对的是任务间通讯
正常来说想计算器这样的程序一般裸奔是很好解决了,但是为了更好的了解本章的内容做了以下修改
原本的裸奔扩展为几个任务
任务一,扫描键盘,识别键盘输入,将数据传输至运算任务,与显示任务,优先级最高(由于该程序是计算器,使用到的按键会比较多,而且并无其他实时任务占用资源,所以这里使用扫描键盘的做法,节省硬件资源)
任务二,运算任务,存储任务一传输过来的数据,进行存储或运算,具体更具传输指令触发动作
任务三,显示任务,显示其他任务传输过来的数据,及指令触发动作

 

根据本章学习到的内容定义了三个方案

 

方案一:任务通知
个人理解,每个任务都有相应的任务通知,应该是可以触发某个任务的任务通知,如果以上不成立,该方案不可行,

任务一,实时在扫描,识别到触发信号,通知到任务二,与任务三,执行相应动作
任务二,等待任务通知,并执行相应动作,运算结果发送至任务三
任务三,等待任务通知,并执行相应动作

 

方案二:队列
任务一,实时在扫描,识别到触发信号发送队列数据到任务二
任务二,做相应触发动作,并发送队列数据到任务三
任务三,根据指令执行相应动作

 

方案三:信号量
前提定义全局变量
任务一,实时在扫描,识别到触发信号,发送与任务二的信号量
任务二,识别信号量,获取相应数据,并发送与任务三的信号量
任务三,识别信号量,获取相应数据,并触发相应动作
他的回复含代码和图片,直接点击看帖回复比较方便:http://bbs.eeworld.com.cn/forum.php?mod=redirect&goto=findpost&ptid=1138152&pid=3005191&fromuid=530227 在FreeRTOS环境下,要设计一个UART接收指定数量字符的函数,可以用怎样的途径?请描述你的思路,并分析优缺点,以及还可能怎么改进。
审题:UART接收指定数量字符,然后触发后续任务
方案一:中断收到UART数据,将UART数据存入消息队列,统计数量,达到数量任务通知或信号量触发后续任务
方案二:中断收到UART数据,将UART数据存入环形缓冲区,统计数量,达到数量任务通知或信号量触发后续任务
方案三:中断收到UART数据,将UART数据存入DMA,统计数量,达到数量任务通知或信号量触发后续任务

方案一,可能导致数据丢失,方案二,解决方案一的数据丢失问题,方案三,释放了CPU
http://bbs.eeworld.com.cn/thread-1139972-1-1.html

第二题,设计考虑,后期有时间在验证补充
我的学号 用简易示波器的设计进行思考,在我看来示波器可以分为三个软件相关的模块:

1. 数据实时性采样,示波器需要根据已设定的采样精度和存储深度对数据进行完整采集,实时性要求高;

2. 数据存储和处理,需要有足够的空间存储数据并能够根据需要进行信号处理,保证数据处理速度和存储速度赶上采样速度,避免数据丢失甚至混淆;

3. 数据重现,重现的终端可以是屏幕或者上位机,数据刷新时间不能太慢;

此外的考量还有:

信号正常显示和触发功能可以设计成两种不同的工作模式;

如果考虑多通道示波器,还需要做到通道间的采样数据平行,互不干扰;

如果期望通过U盘,串口或者网口等介质取走数据,则有文件操作方面的要求;

另外诸如整机运行时内部自检,采集到的数据是否需要补偿,数据存储失败如何处理等,这些也是每个周期运行时需要考虑的问题

功能方面,能靠硬件完成的事情MCU 就不要参与,留下宝贵的算力资源参与数据处理和任务调度;例如在硬件采集和显示的读写空档进行数据存储和处理,这需要精准的时间测量;不使用实时系统也能实现上述功能,但弊端有:1.不利维护,代码复杂度高;2.不利改进;若有新功能的添加,需要重新考虑程序架构;3.可移植性差;不同平台,甚至是不同元器件带来的延时,都会影响到原本的时序安排.

 
感觉这期难度稍微有些高,ARM 的指令集不常用也就忘得差不多了

直觉上的概念是:无论8 bit  或32 bit 的单片机,放在RTOS 进行任务的切换,实际上做的都是同样的工作:A任务切换到B任务时,把当前A任务相关的变量的值,函数的执行位置等信息压入到A 相关的堆栈中;然后开启B任务生成变量和执行程序;切换到A任务时,同样需要将当前B任务相关的变量的值,函数的执行位置等信息压入到B 相关的堆栈中,然后从A 的堆栈调出之前的信息使用,如此反复;

至于C51 和STM32 对这个操作的差异,由于架构不同记载信息的寄存器会不同,此外可能用不同的机制进行实现。具体有多不同,还需要再查看多些资料。。。。
1.存在比原本任务更高优先级的任务,在原本任务准备开始延时被就绪,且执行时间为5个时间单位;

2.存在和原本任务同等优先级的就绪任务,不同任务穿插用了 5 个时间单位;

3.硬件有问题,导致计时不准
可以分为三个任务进行:
任务一负责实时监听按键输入信息,正确地读取信息的输入是很重要的,而信息输入的时机是不可测的。可以通过中断的方法让监听事件处在就绪状态,按键输入后将信息传递给储存计算任务;

任务二负责输入信息的存储和计算;考虑存输入信息快且多的情况,或者需要进行的运算比较复杂,可以专门开辟一个存储信息和进行计算的任务;这个任务在输入信息达到一定数量后被启用执行,执行完毕后输出结果交给显示用的任务三,再将自身挂起等待通知;

任务三负责结果输出,该任务实时性要求不高,主要响应任务二的通知,将计算结果输出到1206,完毕后将自身挂起等待通知。
该宏函数主要用于上下文切换的申请,本质上是通过操作中断控制和状态寄存器(ICSR)的相关位置实现 PendSV 异常;然后再PendSV 异常中设置其他任务的上下文返回,这样在高优先级异常处理完毕后会立即进入PendSV 异常,该异常又将开启新的任务

 
在数据收发的时序是已知的情况下,直接在程序里边定时查看取走UART 接收寄存器内容即可;
如果数据的接收拾不定时的,最简单的方法是不停地查询,但这样无疑会浪费系统宝贵的资源;
可以采用中断的方法,同样是分为两个任务进行,任务一负责接收中断的响应和接收数据,任务二由任务一唤醒,取走数据并进行后期的处理,在DMA 加入的情况下能够省下更多时间;使用系统存在版主提到的数据刷新过快,任务切换开销过多反而得不偿失的可能


选择了第二个题目,个人的一点愚见
http://bbs.eeworld.com.cn/thread-1139991-1-1.html
superstar_gu

由于单片机程序运行都是单线程,所以多任务应用必须应用中断。但是,在并发的多任务调度,CPU空闲管理,操作系统(比如RTOS)相对于中断,就比较有优势。我构想下列案例:

逆变器控制

任务A:现场电流/电压传感器数据实时采样

任务B:逆变器PWM占空比计算与调节

任务C:上位机通讯

应用中断,选择PWM中断优选,依次调用任务A,任务B,任务C,然后等待下有一个PWM中断信号,

优点是:单线程,方便调试,CPU任务节点方便跟踪,

缺点是:CPU”空闲“时间较长,实时性略差。

改用操作系统(比如RTOS),三个任务A,任务B,任务C”并行“执行,

(1) CPU得到充分利用,任务深入改进

比如,任务A,数据采集,加大采集数据的深度与广度,提前预防采集数据丢失,增加电压/电流失调或故障预警。

(2) 外界交互“实时性”

比如,任务C,由于任务脆片化,缩小时间周期,逼近实时性

(3) 需要提升CPU性能

任务B,”中断“处理单线程将所有资源最大化偏向任务B,这是操作系统任务处理难以达到的。但是操作系统在任务的PWM处理算法,尤其人工智能算法会有优势,因为多变量多任务是操作系统的优势。

(4) 操作系统RTOS任务调动的多样性

操作系统的任务调动多样性,决定着模式选择多,下列两幅图,一幅为任务优先,一幅为时间片管理。

本案以任务优先考虑,依次为:故障(任务A预警),任务B,任务A,任务C,




 
堆栈这部分我还要深入了解。
以c51为例,
1. 我们需要知道两个任务占用内存大小,这样才能给任务分配内存。
2. 创建任务堆栈和tcb,初始化。
3.  任务调度,全局句柄获取tcb地址,读取任务1堆栈指针,同时保存任务2堆栈值;
4. 由于任务堆栈是连续的,堆栈先进后出,任务调度过程中,内存任务逐渐释放。
vTaskDelay()是相对延时函数,任务每次延时都是从调用延时函数vTaskDelay()开始算起的,延时是相对于这一时刻开始的。如果执行任务A的过程中发生中断,那么任务执行的周期就会变长。
(1)高级别的任务抢占

(2)任务A与任务B,甚至更多任务同时执行,也会造成任务A的延时函数延时

(3)任务本身在,调度时的损失时间,如阻塞,挂起至执行,也会导致延时。
   

1. 键盘扫描任务 

        使用时间片进行周期性任务调动,每隔一段时间执行一次,单次周期执行任务完成,给计算器程序发送消息队列

    2. 计算器程序任务

        使用 getchar() 函数和 putchar() 函数分别进行输入输出,周期性任务调动,每隔一段时间执行一次,每次周期执行任务完成,若不为空,给显示屏接口任务发送消息队列

     3. 显示屏接口任务   

        等待消息队列任务
执行系统调用,比如普通任务可以使用taskYIELD()强制任务切换,中断服务程序中使用portYIELD_FROM_ISR()强制任务切换。

portYIELD_FROM_ISR函数的参数,如果为pdTRUE,退出中断就会切换到高优先级任务执行。那是因为这个portYIELD_FROM_ISR函数在参数为pdTRUE时,会调用portYIELD()函数强制上下文切换。如果为pdFALSE,不执行上下文切换。
任务:FreeRTOS环境下,要设计一个UART接收指定
数量字符的函数
(1) 创建UART 接受任务
(2) UART接受函数RX,考虑采用系统中断实现,
(3) 若字符数量比较长,考虑利用队列实现。
xRxedChars=xQueueCreate(uxQueueLength,(signedchar)sizeof(signedchar));
(4)UART接受函数
ISR( USART0_RX_vect )
{
signed char cChar;
signed portBASE_TYPE xHigherPriorityTaskWoken;

    cChar = UDR0;

    xQueueSendFromISR( xRxedChars, &cChar, &xHigherPriorityTaskWoken );

}

上述方法基于字符队列与中断实现,UART存取过程中完全占用CPU,效率不高,资源利用率差。
DMA存取更好。
简单做了STM32F107如何移植FreeRTOS并创建任务:http://bbs.eeworld.com.cn/thread-1139796-1-1.html

 

 

瓜分红包奖

共5人参与,奖池内共100元,最终按时完成的网友为3名,平均会瓜分到34元。

 

@我的学号,@superstar_gu @abc9981 挑战成功,论坛微信公用号“helloeeworld1”将与您联系,通过微信转账的方式转给您。

@俺还活着,差2站没有打卡

@role_2099  差6站没有打卡

此帖出自单片机论坛

扫一扫,关注 EEWORLD 微信订阅号

行业资讯、电子趣闻、技术干货、精彩活动……尽可掌握~


回复

100

帖子

0

资源

一粒金砂(中级)

已更新信息,通过本次学习也算是入门了FreeRTOS,浅尝FreeRTOS,后续有时间还是要深入了解


回复

5

帖子

0

资源

一粒金砂(初级)

感谢


回复

233

帖子

0

资源

一粒金砂(中级)

非常羡慕坚持打卡的同学们,有时间和精力坚持学习,值得敬佩!


回复

403

帖子

0

资源

一粒金砂(中级)

信息确认,感谢EE 和 CRUELFOX 组织这次活动;纸上得来终觉浅,还是需要找个实际的项目练练手

个人签名君应有语,渺万里层云,千山暮雪,知向谁边?

回复
您需要登录后才可以回帖 登录 | 注册

关闭
站长推荐上一条 1/6 下一条

About Us 关于我们 客户服务 联系方式 器件索引 网站地图 最新更新 手机版

站点相关: 安防电子 汽车电子 手机便携 工业控制 家用电子 医疗电子 测试测量 网络通信 物联网

北京市海淀区知春路23号集成电路设计园量子银座1305 电话:(010)82350740 邮编:100191

电子工程世界版权所有 京ICP证060456号 京ICP备10001474号 电信业务审批[2006]字第258号函 京公海网安备110108001534 Copyright © 2005-2020 EEWORLD.com.cn, Inc. All rights reserved
快速回复 返回顶部 返回列表