通读ucosiii最新版本3.04.04官方给基于stm32f429的移植代码，发现fpu的操作没有问题

fandeshun

看了一下ucosiii的官方提供的目前最新代码，觉得他的移植很严禁，尤其是版主提到的fpu问题，我没有发现哪里写的不对呢。在范例中，启动代码关闭了fpu硬件自动压栈，然后以固定的顺序对fpu的33个寄存器进行人工压栈，只要OS_CPU_ARM_FP_EN == DEF_ENABLED，那么每次任务切换调用的OSTaskSwHook函数会对fpu的33个寄存器进行压栈和出栈操作，机制非常简单。网上有网友说官方的移植有错误，根本就没有办法运行，不太理解哪里出了问题，虽说官方版本的fpu效率有些低，但是运行应该没有问题吧？如果说官方移植的有错误，谁又能一针见血的说出他的症结所在呢？

eric2013

3.04.04不是最新，3.05.01才是最新。最近没时间折腾这个ucos了，等后面有时间看了再瞅瞅新版本的移植部分修改了那些。
ucos提供的方法也可以的，就是效率低一些，这个问题uCOS都解决不了，那不是歇菜了。。。

rgzdb

实际移植后，F4开FPU进入硬件错误，不开运行正常。

fandeshun

我也看了一下eric2013移植的改进版代码，其中PendSV部分代码有点疑惑，想请教一下。任务的堆栈初始化后第一次运行，是不需要进行现场保护的，那么任务第一次运行的标记是将PSP的设为0，那么有一个风险，那就是如果我在程序的启动代码（start.s）中就已经将MSP切换到PSP，执行PendSW的时候，由于中断过程中硬件的自动压栈，PSP的值将被改写为非零值，那么这下就会引发任务切换问题。怎么解决呢？

fandeshun

rgzdb？您说的“实际移植后，F4开FPU进入硬件错误，不开运行正常。”，是指的官方的移植代码么？

eric2013

fandeshun:我也看了一下eric2013移植的改进版代码，其中PendSV部分代码有点疑惑，想请教一下。任务的堆栈初始化后第一次运行，是不需要进行现场保护的，那么任务第一次运行的标记是将PSP的设为0，那么有一个风险，那就是如果我在程序的启动代码（start.s）中就已经将MSP切换到PSP，执行PendS .. (2015-11-19 16:05) 

所以一定要有规范的编程习惯，对于我们开发板所有的uCOS代码，我不会在uCOS开启多任务之前做任何额外个工作，外设的初始化等我都是放在启动任务里面完成的。

mqkycy

我在407上移植的V3.04.05这个版本，程序中遇到浮点操作后，再调用GUI_Clear（）这个函数就进入硬件错误中断了，没有浮点操作就运行正常。目前还没有解决呢

fandeshun

第一次进入PendSV，为了保证PSP=0，硬件自动入栈显然使用的是MSP，那么您在弹出寄存器恢复现场的时候为了让任务使用PSP,使用的是任务堆栈初始化时自己人工定义的EXC_RETURN（0xfffffffd），PendSV返回时，硬件自动出栈的时候将不能恢复MSP中所保存的正确的寄存器值，而弹出了PSP的未知值，未知值怎么可能让第一个任务启动呢？当然，如果顺利启动了，说明弹出的还是MSP中的值，而EXC_RETURN中的指针控制位就没有起作用么？难道第一个任务得到运行之后，经历人工定义的EXC_RETURN后，他仅仅将CONTROL寄存器中的有效指针位更新为PSP，而中断返回过程中硬件自动出栈的时候则还是选择了MSP?您在代码中有没有其他地方明确定义CONTROL寄存器的堆栈选择位为PSP么？

eric2013

fandeshun:第一次进入PendSV，为了保证PSP=0，硬件自动入栈显然使用的是MSP，那么您在弹出寄存器恢复现场的时候为了让任务使用PSP,使用的是任务堆栈初始化时自己人工定义的EXC_RETURN（0xfffffffd），PendSV返回时，硬件自动出栈的时候将不能恢复MSP中所保存的正确的寄存器值，而弹出了PSP的 .. (2015-11-19 18:42) 

有些地方你还是没有理解透。
1. 首次运行PendSV将切换到当前最高优先级任务去执行，MSP中保存的自动入栈寄存器已经没有用了，也不需要返还了，而是开始多任务的执行了。
2. 开启多任务后，任务栈使用的是PSP,系统栈使用的MSP。

再好好理解下，有什么问题继续交流。

rgzdb

不开浮点可以正常运行，开浮点进入硬件错误，用的是官方例程Micrium_STM3240G-EVAL_OS3，版本号V3.04.05。

fandeshun

eric2013，谢谢你的耐心回复，我又仔细看了一下你的代码，觉得这次真的理解了！在PendSV的最后，你把人工出栈后的堆栈地址赋给了PSP，这样，中断返回过程中的硬件自动出栈恢复寄存器就没有问题了，而且，通过这次EXC_RETURN人工设置，PendSV返回后CONTROL寄存器将受该EXC_RETURN影响被自动更新为PSP状态，这样一来，以后的代码都将进入到PSP指针状态！所有的工作仅仅是浪费了32个MSP堆栈没有回收，以后的切换都是基于PSP的！不知理解是否到位。另外有个想法：为了不损失MSP，回收一下MSP，即：如果PSP=0，那么MSP-=8；然后再跳转到OS_CPU_PendSVHandler_nosave。代码如下：   CPSID I;     MRS R0, PSP;      TST R0, 0X00000000;     ITT EQ;       SUBEQ MSP, MSP, #8;       BEQ OS_CPU_PendSVHandler_nosave;  ......   不知是否可行。

eric2013

fandeshun:eric2013，谢谢你的耐心回复，我又仔细看了一下你的代码，觉得这次真的理解了！在PendSV的最后，你把人工出栈后的堆栈地址赋给了PSP，这样，中断返回过程中的硬件自动出栈恢复寄存器就没有问题了，而且，通过这次EXC_RETURN人工设置，PendSV返回后CONTROL寄存器将受该EXC_RETURN影 .. (2015-11-20 09:37) 

可以试试。

========
下面说的是另一个问题。
我们都知道，在STM32的启动文件里面有一个设置栈大小的地方，平时裸机编程都是用的这个栈空间，而uCOS-II和III设置了一个新的系统栈空间，没有再使用这个启动代码里面的栈空间作为以后的系统栈空间。这个是uCOS最大的浪费，所以我前面说明不要在uCOS开启多任务前做任何其它的工作，这些工作是要占用启动代码里面的栈空间，如果做得工作需要大的栈空间，造成的浪费就更大。
   当然，uCOS这么做也是有好处的，方便内核管理系统栈空间。
---------
在uCOS的汇编移植代码里面。你可以看到MSP重新指向了这个uCOS自己定义的系统栈空间。

star_66666

[s:147]  [s:147]  [s:147]  [s:147]  [s:147]

fandeshun

eric2013:可以试试。

========
下面说的是另一个问题。
....... (2015-11-20 11:27)

嗯，我也注意到这个问题了，不过我觉得ucos没有用启动代码那个栈，应该也没什么，他重新定义了MSP，之前在启动代码定义的栈应该被优化掉了，他们不会并行存在的，对整个内存不会造成浪费。如果你有顾虑，可以考虑将启动代码的栈设置成ucos用的栈。

fandeshun

另外，eric2013，使用你的这个移植版本，应该提醒大家把fpu自动入栈那个设置为系统默认的允许，要屏蔽掉官方版本启动代码中的相关"disable lazy context switch"的设置，才可以ucos保证运行正常。
;Disable automatic FP register content
;Disable lazy context switch
;LDR.W   R0, =0xE000EF34         ; Load address to FPCCR register
;LDR     R1, [R0]
;AND     R1,  R1, #(0x3FFFFFFF)  ; Clear the LSPEN and ASPEN bits
;STR     R1, [R0]
;ISB                             ; Reset pipeline now the FPU is enabled

eric2013

fandeshun:嗯，我也注意到这个问题了，不过我觉得ucos没有用启动代码那个栈，应该也没什么，他重新定义了MSP，之前在启动代码定义的栈应该被优化掉了，他们不会并行存在的，对整个内存不会造成浪费。如果你有顾虑，可以考虑将启动代码的栈设置成ucos用的栈。 (2015-11-20 17:17)

不是，是浪费掉了。后面不会再使用到。FreeRTOS在这方便做的很好，重新把启动代码部分指向栈顶。

eric2013

fandeshun:另外，eric2013，使用你的这个移植版本，应该提醒大家把fpu自动入栈那个设置为系统默认的允许，要屏蔽掉官方版本启动代码中的相关"disable lazy context switch"的设置，才可以ucos保证运行正常。
;Disable automatic FP register content
;Disable lazy context switch .. (2015-11-20 17:25) 

我的写个UCOS工程里面没有设置 LSPEN 和ASPEN，使用默认值，也就是使能这个特性。

fandeshun

eric2013:不是，是浪费掉了。后面不会再使用到。FreeRTOS在这方便做的很好，重新把启动代码部分指向栈顶。

(2015-11-20 17:28)

那我们把启动代码的栈顶改为指向ucos的栈吧，这样应该就没有问题了。

eric2013

fandeshun:那我们把启动代码的栈顶改为指向ucos的栈吧，这样应该就没有问题了。 (2015-11-21 09:56) 

不好，因为这样uCOS没有办法管理了系统栈了。

roguebear

求版主FPU开和不开均正常的 最终版本……

eric2013

roguebear:求版主FPU开和不开均正常的 最终版本……    (2015-11-21 11:09) 

使用当前给V5开发板配套的即可。只是新版本我还没有去移植，待我搞F429开发板的时候再配套吧。

fandeshun

eric2013:不好，因为这样uCOS没有办法管理了系统栈了。 (2015-11-21 10:00)

又看了一下，ucos系统启动之前，在启动代码里定义的那个栈，后面就没有再使用过，我觉得把启动代码那个栈改为ucos的可行。

eric2013

fandeshun:又看了一下，ucos系统启动之前，在启动代码里定义的那个栈，后面就没有再使用过，我觉得把启动代码那个栈改为ucos的可行。 (2015-11-21 12:27)

这样做不好。uCOS没有办法去管理这个栈空间。还得再修改源代码，得不偿失，其实没必要纠结这些了。前面我就是简单的提一下，开阔下你的思路。
这个问题我们就讨论到这里吧，后面你有什么新的发现了，我们继续交流。

fandeshun

好的，谢谢eric，多交流，共同进步