microblaze tc问题

编译加优化O2后，TC绝大部分都能测试通过，真是奇怪。

简单比较了O0和O2的反汇编代码，O2更接近于C语言表达。
例如：
rt_tick_t rt_tick_get(void)
{
/ return the global tick /
return rt_tick;
}

O0的反汇编：
a400021c :
a400021c: 3021fff8 addik r1, r1, -8
a4000220: fa610004 swi r19, r1, 4
a4000224: 12610000 addk r19, r1, r0
a4000228: b000a402 imm -23550
a400022c: e860b408 lwi r3, r0, -19448
a4000230: 10330000 addk r1, r19, r0
a4000234: ea610004 lwi r19, r1, 4
a4000238: 30210008 addik r1, r1, 8
a400023c: b60f0008 rtsd r15, 8
a4000240: 80000000 or r0, r0, r0

O2的反汇编：
a4000204 :
a4000204: b000a402 imm -23550
a4000208: e8601730 lwi r3, r0, 5936
a400020c: b60f0008 rtsd r15, 8
a4000210: 80000000 or r0, r0, r0

看来以后就用O2优化吧

thread_delay失败，你那边是否把OS_TICK开得特别高？或者串口波特率非常低？thread_delay的测试代码本身存在些问题，我已经修正从更新了，可以再试试。

thread_delete好像也是OS_TICK分辨率非常高的缘故？RT_TICK_PER_SECOND的值是多少？

RT_TICK_PER_SECOND是100，串口波特率是115200。可能是uart的发送fifo比较小，用查询方式发送速度比较慢。我在rt_kprintf()前后控制gpio，然后用示波器测量了一下，打印10几个字符大约需要1.5mS。

现在经过O2的优化处理，以及修改了thread_delay,thread_delete,thread_same_priority,执行tc_start(“thread”)全部通过了。

原来以为不优化，占用的堆栈可能会多一些，增加了stack尺寸，也没有效果。算了，没时间仔细研究编译器的优化问题了。就用O2优化吧。

thread_delay修改跟以前一样，将打印字符的位置进行了调整。
thread_delete中问题比较奇怪，将_tc_thread_delete函数中的返回值增大一些，就可以通过测试。原来是25，修改成27后，反复测试没有出过错误。
thread_same_priority还跟上次遇到情况一样，_tc_thread_same_priority函数中，返回100不起作用，返回前，增加了rt_thread_delay(100)能通过测试。不过，thread_same_priority好像还有问题，单独执行tc_start(“thread_same_priority”)测试，会反复测试退不出来。我增加了两个count的打印。
finsh>>tc_start(“thread_same”)
0, 0x00000000
finsh>>Run TestCase: thread_same_priority
t1_count=830531 t2_count=399806
TestCase[thread_same_priority] passed
Run TestCase: thread_same_priority
t1_count=829804 t2_count=399805
TestCase[thread_same_priority] passed
Run TestCase: thread_same_priority
t1_count=829805 t2_count=399805
TestCase[thread_same_priority] passed
Run TestCase: thread_same_priority
t1_count=829807 t2_count=399804
TestCase[thread_same_priority] passed
Run TestCase: thread_same_priority
t1_count=829803 t2_count=399806
TestCase[thread_same_priority] passed

刚测试了svn上的thread_delay没有问题了。

thread_same_priority问题是_tc_cleanup函数返回前的tc_stat设置有问题。
if (t1_count / t2_count != 2)
tc_stat(TC_STAT_END | TC_STAT_FAILED);
如果t1_count / t2_count 等于2时，应该设置TC_STAT_PASSED。
将上面代码改为：
if (t1_count / t2_count != 2)
tc_stat(TC_STAT_END | TC_STAT_FAILED);
else
tc_done(TC_STAT_PASSED);

另外，t1_count 前面不加上volatile的话，可能会被优化掉？打印的count值是0。
经修改，解决问题。

thread_same_priority还有问题，执行tc_start(“thread”)测试时，失败。单独用tc_start(“thread_same”)测试，通过。好像thread_same_priority还是受到其他测试程序影响，没有等100个tick，直接结束了。

finsh>>tc_start(“thread”)
0, 0x00000000
finsh>>Run TestCase: thread_delay
…
TestCase[thread_resume] passed
Run TestCase: thread_same_priority
t1_count=0 t2_count=0
TestCases[thread_same_priority] failed
TestCase[thread_same_priority] failed

finsh>>tc_start(“thread_same”)
0, 0x00000000
finsh>>Run TestCase: thread_same_priority
t1_count=429606 t2_count=184568
TestCase[thread_same_priority] passed
RT-Thread TestCase Running Done!

芯片有cache吗？有cache会导致执行序列有部分差异。

另外，把觉得测试代码有问题，修改过后能pass的提交一份到svn吧。我根据diff再看看。