这里是BUG回报板块!

RTT的时基函数是rt_tick_increase()，该函数有个不妥之处，比如我把每个线程的时间片长度设置为1个时基。
那么，有以下情况可能发生：rt_timer_check()函数使更高优先级的线程就绪，而该线程的时间片为1。此后rt_thread_self()函数返回的就是这个就绪线程，接下来紧接着时间片计数器就被减1，变为0，也就是说线程还没执行就被rt_thread_yield()函数当作放弃了执行对待！

这就是不妥之处！望Bernard兄妥善解决。

RTT的定时计数器变量rt_tick在每个Tick中断内自增，自增到0xffffffff再溢出到0周而复始。

所有定时器对象的定时结束时基计算为：timer->timeout_tick = rt_tick_get() + timer->init_tick;
在时基中断，检查if (rt_tick >= t->timeout_tick)是否成立，如果成立则定时时间到。似乎很合理，但是错误就出现在这里。

如果来了20个tick的定时请求在执行timer->timeout_tick = rt_tick_get() + timer->init_tick;时，若rt_tick为0xfffffff0，于是得出定时结束时间为0x00000004，于是该节点加入定时器列表等待超时。结果，下一次进入中断的rt_tick为0xfffffff1，使if (rt_tick >= t->timeout_tick)检查成立，所以定时时间结束，错误发生了！
这个错误平时发现不了，是因为等到rt_tick接近溢出需要很长时间（如果1毫秒一个tick的话，需要50天，10毫秒一个tick就需要500天，哈哈！），Bernard兄是不是考虑到这个情况才故意放过这个臭虫的呢？如果要解决该问题，必定添加不少冗余代码，影响性能。但留着这个漏洞又很不舒服，怎么办呢？

RTT的时基函数是rt_tick_increase()，该函数有个不妥之处，比如我把每个线程的时间片长度设置为1个时基。那么，有以下情况可能发生：rt_timer_check()函数使更高优先级的线程就绪，而该线程的时间片为1。此后rt_thread_self()函数返回的就是这个就绪线程，接下来紧接着时间片计数器就被减1，变为0，也就是说线程还没执行就被rt_thread_yield()函数当作放弃了执行对待！这就是不妥之处！望Bernard兄妥善解决。

RTT的定时计数器变量rt_tick在每个Tick中断内自增，自增到0xffffffff再溢出到0周而复始。
所有定时器对象的定时结束时基计算为：timer->timeout_tick = rt_tick_get() + timer->init_tick;
在时基中断，检查if (rt_tick >= t->timeout_tick)是否成立，如果成立则定时时间到。似乎很合理，但是错误就出现在这里。如果来了20个tick的定时请求在执行“timer->timeout_tick = rt_tick_get() + timer->init_tick;”时，若rt_tick为0xfffffff0，于是得出定时结束时间为0x00000004，于是该节点加入定时器列表等待超时。结果，下一次进入中断的rt_tick为0xfffffff1，使if (rt_tick >= t->timeout_tick)检查成立，所以定时时间结束，错误发生了！
这个错误平时发现不了，是因为等到rt_tick接近溢出需要很长时间（如果1毫秒一个tick的话，需要50天，10毫秒一个tick就需要500天，哈哈！），Bernard兄是不是考虑到这个情况才故意放过这个臭虫的呢？如果要解决该问题，必定添加不少冗余代码，影响性能。但留着这个漏洞又很不舒服，怎么办呢？

RTT还需要很长的时间来完善才能用于商业乃至工业现场啊！今天又发现了一个很要命的漏洞，这种漏洞是对临界代码段的理解太随意导致的。
我知道，很多人有时候为了所谓的实时性，都忽略了临界代码段的重要性。但是，如果不仔细推敲代码而随意放任的话，系统会变得异常脆弱！
下面我就来给你分析以下rt_object_find()函数的漏洞。
rt_object_find()函数是通过对象的名称来查找对象，并返回指针。调用该函数之前，线程大都不会关中断来保护rt_object_find()，而该函数自身更是没有临界段保护措施，这样就造成了下面的漏洞：
在遍历链表节点的过程中，node指向当前所检查的对象节点，而在此判断过程中，有可能高优先级线程得到运行，从而导致当前对象节点有可能被删除，这时，对象的链表指针next,prev就指向它自身。之后，CPU上下文回到调用rt_object_find()函数的线程，继续遍历对象链表，结果node = node->next语句总是使node指向它自身，而且符合node != &(information->object_list)条件，因此，for()循环形成了死循环！该函数将无法退出，其结果无法预测！
我是一个思维很严谨的人，总是很小心的对待代码，即使是在单任务软件开发过程中，我也很注意中断函数和main()循环之间的临界代码段问题。希望大家能跟我一样多查看内核代码，尽快完善RTT！
（我的经验都来自ucos源代码，因为国外对RTOS的认证是很严格的，ucos是经过航空级认证的RTOS）

如下。。。

.objrtthread-stm32.axf: Error: L6218E: Undefined symbol rt_realloc (referred from region.o).
.objrtthread-stm32.axf: Error: L6218E: Undefined symbol rt_strdup (referred from rtgui_object.o).
.objrtthread-stm32.axf: Error: L6218E: Undefined symbol rt_free (referred from rtgui_system.o).
.objrtthread-stm32.axf: Error: L6218E: Undefined symbol rt_malloc (referred from rtgui_system.o).
.objrtthread-stm32.axf: Error: L6218E: Undefined symbol rtgui_filerw_create_file (referred from image.o).
.objrtthread-stm32.axf: Error: L6218E: Undefined symbol rt_mq_create (referred from server.o).
.objrtthread-stm32.axf: Error: L6218E: Undefined symbol rt_thread_create (referred from server.o).

可以看到在实例里面的mdk里面， 内存管理的函数都提示没有定义， 无法调用。。。。

你的工程文件有问题？

关于使用RT-Thread/GUI的例子，可以参考STM32 Radio的例程