EEPW论坛

实验六 消息缓存区

看了看内核规范里的消息缓存区，赶脚和邮箱消息蛮相似的，不过没看到有消息类优先级的设置，只有发送消息任务队列有优先级。第一感觉，应该是个经典的FIFO。

读实验源代码的时候，发现有个函数strlen( )找不到定义。

貌似是用来获取发送字符串的长度的函数，然后将长度参数传递给tk_snd_mbf()函数用来发送消息。

后来才知道，这个函数是Gcc库中的。

实验结果：

串口信息显示，A和B不断在通过消息缓存区进行通信。

如果消息邮箱有一定的了解，这个也不在话下。

1) 当一个缓冲区中有多个消息时，取出一条消息，那么这条消息是最先进入缓冲区的消息还是最后进入缓冲区的消息？
简单分析一下，在内核规范里头未见有消息类的优先级设置，估计应该是一个FIFO。

修改代码，使TaskA连续发送字符串 “Do you think that uTenux is the best RTOS?????????”和“ Good Day????????? ”，然后使TaskB从消息缓存区接收2次消息。

从串口打印信息可以很清楚的看到，A先发送的消息，B会先收到。

2) 某任务向一个消息缓冲区连续不断发送消息，消息缓冲区满之后会出现什么状况？

内核规范中提到，如果没有足够的缓冲区空间可容纳消息队列中的消息 msg，则发行该系统调用的任务进入发送等待状态， 排队等候可用的缓冲区空间 （发送队列）。也意思是说，A不断地发送消息直至消息缓冲区满，那么A就会进入等待状态，这个时候B就开始运行。

修改代码，使A不断发送消息，并不接收消息。可以预见，A进入等待状态后，B会收取一个消息并向第二个缓存区发送消息，那么很快，第二个缓存区也会满，B最后也会进入等待状态。

μTenux所有任务都等待状态的话，会退出。

有图有真相：

看上去，分析得还不算太错。

如果修改代码，使A不断发送消息，并不断接收消息呢？

是不是应该A和B不断进行发送和接收呢？

那必须滴。

TBC......

实验七集合点端口

个人觉得集合点相对于前面几个实验是比较难理解一些。

仔细查看内核规范，这里重点是四个函数tk_cre_por( )、tk_acp_por( )、tk_cal_por( )和tk_rpl_rdv( )。

基本任务流程是：

首先，用tk_cre_por( )函数创建一个集合点端口，这里要特别注意，仅仅是创建而已，并没有使用。就好像任务一样，创建任务和运行任务是不同的。

然后，是tk_acp_por( )和tk_cal_por( )，你可以以先acp再由cal应答（等待集合点接受）的方式来唤醒集合点，或者以先cal再acp应答（等待集合点调用）的方式唤醒，我个人理解这两个函数得成对使用才行。任务之间通信和同步如果用集合点端口来完成的话，那么不同任务必须使用相同的位模式参数（相与不为0），才能使tk_acp_por( )和tk_cal_por( )匹配，唤醒集合点端口。

最后，等待的任务调用tk_rpl_rdv( )完成应答，并结束集合点（类似挂起），等待下一次集合点唤醒。特别注意，这个tk_rpl_rdv( )函数只能在执行完 tk_acp_por 以后执行。

这里面有个集合点ID和集合点编号的区别，ID其实是创建集合点时OS赋予的，而编号则是由OS在等待集合点调用或接受的时候，由OS分配。在多个集合点的系统里面，编号是非常重要的。

了解了这些东西，再去看实验源代码就一目了然了。

直接上结果：

很顺利，B执行tk_cal_por( )等待调用，A执行tk_acp_por( )接受集合点，然后A执行tk_rpl_rdv( )进行回复并结束集合点，典型的等待集合点调用模式。

1) 本实验中演示了两个同优先级任务使用集合点端口进行通信的方式,如果增加一个任务，也参与通信,结果如何?

分析一下，如果增加一个任务C，会不会出现任务A和任务C这2个任务轮流与任务B通过集合点端口进行同步和通信呢？

果断增加同优先级的TaskC，同时B任务的i变成18（和2个任务通信，一个任务9次）。

出来的结果和预想的有点小差距，为毛A要与B通信2次后，C和A才交替与B进行通信呢？

其实这个和ABC优先级、OS的任务调度有关。

ABC三个任务优先级一样，B首先运行并按次序启动A和C，这个时候，B在运行态，A和C在就绪态。根据μTenux系统调用的原则，B等待后，先会执行A，再执行C。

B调用tk_cal_por而进入等待集合点调用的等待状态，此时A开始运行并执行tk_acp_por启用集合点（此时集合点应答等待队列中无任务），然后执行tk_rpl_rdv在集合点中返回一个回应给调用任务B，终止集合点。tk_rpl_rdv并不会引起A进入等待状态，A继续从循环开始执行，并执行tk_acp_por引起A进入等待集合点接受的等待状态（这个时候集合点等待队列中出现了A），C开始执行，并执行tk_acp_por引起C进入等待集合点接受的等待状态（这个时候集合点等待队列中出现了C）。回头看集合点创建函数，cpor.poratr  = TA_TFIFO;，集合点等待队列以FIFO的形式进行排列，A和C进入等待状态后，B首先响应的是A的等待集合点接受，然后才是C的。这也就解释了，为什么A会与B通过集合点进行2次通信后，C和A才开始交替与B通过集合点进行通信。B和A第一次通信是等待集合点调用模式，以后所有的通信都是等待集合点接受的模式。

原来是优先级惹的祸，强力插入修改，将A和C的优先级提高为9.

上图：

串口打印出来的信息表明，从一开始，A和C就在交替与B通过集合点端口进行通信。打完收工。

2) 考虑一下其他还有什么情况下,会使用到集合点端口这种方式?

多个任务要执行同一个处理的时候，这种集合点端口的方式很方便。

譬如一个打印机，有A、B、C等3台电脑有文档需要打印，优先级A>B>C。如果C先开始打印，打印到1/3，B发出请求，再打印1/3，A又发出请求。如果没有集合点端口模式，最终打印出来的文档ABC各有1/3；如果采用集合点端口模式，就会按照优先级或者FIFO的队列形式进行打印。

不知道这种理解是否合适。

TBC......

实验八固定尺寸内存池

实验开始涉及有关内存管理的相关内容了。

不过μTenux不支持虚拟内存，支持常驻内存。意思是说，μTenux所管理的内存对象是物理内存。

关于保护级，μTenux目前只支持所有程序（包括系统和应用程序）内存保护级在0级。

这个实验主要涉及的函数包含tk_cre_mpf()、tk_rel_mpf()、tk_get_mpf()、tk_ref_mpf()和tk_del_mpf()。

实验开始前，首先要整清楚一个概念：内存池和内存块。内存池实际上是调用tk_cre_mpf()后，系统分配的内存区间大小，而内存块则包含在内存池中，或者说一个内存池包含有几个内存块。那么，整个内存池的大小=每个内存块的大小X内存块个数。

实验代码中，申请内存池参数cmpf.mpfcnt = 5; cmpf.blfsz = 100;，那么此次申请的内存池大小为5X100=500字节，由5个100字节的内存块构成。在不调用tk_rel_mpf()函数的情况下，这个内存池可以被tk_get_mpf()申请5次。

代码中还调用了内存块操作函数memcpy(blf, buf, len)，意思是将buf起始地址位置的len个字节数据copy到blf起始地址位置里面去。

实验结果：

基本程序流程：创建内存池--B运行--A运行--A休眠--B申请内存块--B写入数据--B唤醒A--A读取内存--A释放内存并休眠--B运行。

固定内存池和互斥体相对，互斥体解锁必须由加锁的任务，而固定内存池可由任何任务进行get或release。

如果A不释放内存池，那么B最多只能申请5次，之后系统就会挂起。

注释掉释放的函数，上图：

嗯，从打印信息来开，意料之中，内存池中的内存块数量被申请完后，A和B进入等待休眠和等待态，系统最终被shutdown。

这里有个疑问，实验代码中len = strlen(buf)+1，为什么要从*buf多copy一个字节的数据到*blf？估计这个问题得回去再深入温习一下C语言了。后来也试了memcpy(blf, buf, len)中len不+1，其实和上面结果一样。

代码的彩蛋？求科普。

1) 尝试修改固定内存池程序，测试申请最大的内存池为多少 KB？

这里尝试了STM32F407VG和sam3S4c两块片子。

STM32F407VG最大申请的内存池为100800B（100.8KB），不过它Up to 192+4 Kbytes of SRAM，还有96KB的物理内存用作什么了，预留？boot？

sam3S4c最大申请的内存池为35264B（35.264KB），它RAM 48KB，还有将近13KB的的物理内存用作什么了，预留？boot？

看来嵌入式操作系统学习的路程才刚刚开始。

TBC......

实验九可变尺寸内存池

可变尺寸内存池（mpl）和固定尺寸内存池（mpf）灰常滴类似。

看了看内核规范，只是个别参数上的区别。

cre的时候，mpl的参数结构体中的mpfcnt和blfsz规定内存块的数量和大小；而mpf的参数结构体中的mplsz规定总的大小。

get的时候，mpf直接减少内存块的数量，大小由cre时候确定；而mpf则通过mplsz参数减少总内存的大小，mplsz即get到的内存块大小。

ref的时候，mpf通过frbcnt获取剩余内存块数量；而mpl则通过maxsz或frsz获取剩余内存池的大小。

窃以为，可变尺寸内存池应该指获取时并不指定具体的大小，而是根据任务使用情况来改变内存池块的大小。

从这个角度来看，μTenux的可变尺寸内存池应该叫做自定义尺寸内存池更为贴切。

实验结果：

实验代码创建的mpl是512B的，为毛128B+376B小于512B，这8个字节去哪里了？

1) 如果内存池内的数据超过内存池块的空间会产生什么样的现象？

其实这个题目看不大明白。是指任务获取的内存块中存储的数据，超过了整个mpl大小吗？

不过还是尝试了一下，条件是任务获得1B的内存块，字符串数据远远超过1B：

从打印信息来看，程序跑飞了。目前还未找到原因。

debug发现，任务B第二次执行MplSamplePutCnt()函数中的ltostr(rmpl.frsz,frsz,10,10)时，程序跑飞。

2) 为什么在申请了 128B 内存块后，剩余的内存块不是 384B，而是 376B 了？

损失了8B的数据空间，个人想法，内存池的控制表、创建内存池时候T_CMPL *pk_cmpl 所包含的内存池相关信息，应该都是会保存在内存池的单元中吧。所以会少几个B的空间，用以保存这些元数据。

不过有个很有意思的现象，申请不同大小的可变地址池，有可能损失的空间不一样。

譬如，在STM32F407VG平台下，申请一个1B的空间，系统会显示剩余488B空间，那么损失了25B空间；申请500B的空间，系统则显示剩余0B空间。

很奇怪。

TBC......

我是每次申请128B，都要损失8B内存。后来看到这段，算是明白了：

Get memory block,'blksz' must be larger than minimum fragment size and adjusted by ROUNDSZ unit.

#define ROUNDSZ(sz)    (((UW)(sz) + (UW)(ROUNDSIZE-1)) & ~(UW)(ROUNDSIZE-1))

应该是一个内存对齐。申请121～128个block都会剩余376B

你也换成STM32F4了？是不是也是Discovery？

这板子真不错，板载仿真器  严重节省桌面空间啊！

那必须是discovery，现在比较普及，芯片资源也相当强大，1M flash，196KB ram，太强大鸟。

呃，内存对齐啊，这个真心没接触过，苦逼哇。