RTT_逍遥
RTT_逍遥 - 认证专家
我欲乘风

注册于 2 years ago

回答
172
文章
6
关注者
9

@NCJN_9736 楼主可以试下#include "error.h"是否可以,也可以试下最新的github上面的该bsp是否ok。

@TELK_4455 有检查是否需要在cubemx里面打开UART配置吗?有一些时钟引脚什么的,需要在CUBEMX里面配好。

@jevian Hi ,可以试下latest版吗?最近master分支上libc有部分改动,可以试下最新版,最新版的bug,我有对其进行修复哦。感谢对RT-THREAD的支持,感兴趣的话,可以把默认配置改成最新的(现在是1.12版本),欢迎楼主PR,成为开源贡献者。

@chenyingchun
帮楼主试了以下几个软件包,这些软件包里面都有submodule,且都是在github上面,在menuconfig中选中之后,执行命令pkgs --update
log如下所示:

image.png

下载起来也是很快的,而且submodule都是从镜像里面下载的。速度也是相对来说比较快的,因为是从gitee上面下载的,

带有submodule的软件包有:
https://github.com/RT-Thread-packages/jerryscript
https://github.com/RT-Thread-packages/CMSIS
https://github.com/RT-Thread-packages/trusted-firmware-m

所以经过我的测试,结论是:gitee镜像同步软件包其实是有对submodule进行同步的。楼主可以验证下我的结论。所以大胆的在软件包中使用submodule,没问题的,虽然可能镜像同步有些延迟,不过一般过个几天就能在gitee镜像中找到submodule。

你这个是master上的代码吗?可以参考下master上面的bsp/stm32上面的流程。看上去,你这里有可能uart_init和set_console的顺序上可能有些差异。

这个你要去看底层drv_uart.c哪里中断接收的时候,是如何调回调函数的。你这种情况很常见,通常有可能是FIFO满了,触发两次中断,一次是数据接收结束中断,一个是FIFO满,中断,可能FIFO满中断又调了一次回调。

公司总归要盈利的,商业一些软件也是正常的。请正确对待RT-THREAD和睿赛德公司出品的商业软件,两者不是同一个东西。RT-THREAD是一个开源平台,内核是免费使用的,睿赛德基于RT-THREAD做的东西不一定要开源公开源码,如果需要源码,可以考虑商业洽谈睿赛德公司。

从PC指针中0x 800534c中找到相应的code可以知道哪一行出错了。

另外一个方法是从MQTT 处于running中,可以看到,其实MQTT线程中可能存在引起hardfault的地方。

检查一下以下变量是否有对应的值:

echo $RTT_CC
echo $RTT_EXEC_PATH
echo $RTT_ROOT

查看下是否有对应的值

楼主可以考虑把系统时钟systemclock打出来看一下,并且可以实际测试下同样的指令,两边是否运行的systick的时间一样。
主要检查下系统时钟是否配置正确。两边系统时钟是否一样。

fopen模式最近有小伙伴反应rb+是有偶问题的,如果改成r就是可以打开来,主要是arm-none-eabi-gcc的bug,用IAR和keil是可以的。楼主可以试下

ulog 在打印的时候,判断下文件系统是否是ready的。

建议找个STM32跑下官方的例子试试看。理解原理。

回到
顶部

发布
问题

投诉
建议