出出啊
出出啊
It is Not the Mountain We Conquer, but Ourselves

注册于 7 months ago

回答
980
文章
23
关注者
65

Print 一个类,要么你没有添加它的源码文件,要么你没有添加它的库文件

换个终端软件吧,串口调试助手不适合msh。
xshell securitycrt mobax putty.....

node 变 NULL 了吧。
或者,内存已经乱了,到这里代码跑飞了

手动调用 libc_stdio_set_console 这个函数。或者你搜一下什么地方使用 libc_stdio_read 这个函数了,不用这个函数就没上面的错误了。

关于线程栈,有个误区,以为完全被线程使用了,其实不是。单单论线程内函数调用树的深度,总是有个固定的值(包括递归调用)。
但是,中断不在函数调用树内,中断是随机的,任何时候可能出现的。只要你没关中断,就有可能进入中断异常。如果中断回调函数内有比较复杂的函数调用,比如 rt_mq_send ,中断 + 中断 + 任务调度 + 任务调度的情况都是有几率出现的。
一次中断耗用了多少栈,一次任务调度又耗用了多少栈,加上线程自己函数调用占用。还觉得 128 很富余吗?

你的挂载 elm 文件系统部分代码在哪儿?格式化磁盘分区代码在哪儿?

  1. 自己控制文件大小,上电初始化先扫描需要写的文件大小,记下文件大小计算剩余写入限值,剩余为0的时候开新文件。
  2. 数量也控制,根据实际测试取一个数量值。
  3. 别用容量特别大的卡,写新数据搜索可用块的时间可能会随着使用越来越长。
  4. 应用层加缓存,数据量少的时候不进行写操作,凑够1k 2k 才写一次。

这个最好不要删的吧,强制删除导致其它等待事件的线程会使用一个没有初始化的对象。你也看到了,continue之后直接返回了 RT_ERROR。
如果你确定必须删除重新创建,其它线程在continue之前也得先find到新的事件集对象之后才能返回while 开头,进而继续等待新的事件集对象。

我感兴趣的是,你说的突发情况是什么,是业务要求?还是异常?是不是发现了莫名其妙的有事件但是其它线程没收到?

没开软定时器?
某个地方使用定时器,但是那个定时器没初始化成功,然后 rt_timer_stop 的时候出错了。

你那几行代码在哪儿执行的?你知道app已经跳转,那引导的肯定没有问题的。问题出在引导后的运行。

左边显示并不能说明编译器知道它的路径,添加include路径

RT_USING_DFS_MNTTABLE
删掉这个配置宏

  1. 你说的使用pin驱动和不使用pin驱动,仅仅是打开 RT_USING_PIN 这个宏?
  2. HAL_SPI_MspInit 里怎么初始化的,初始化没问题吧
  3. 片选脚外接上拉电阻看一下。有可能是芯片内供电不稳定引起的。

前不久有个人是 io 中断脚,长低,上升沿中断,经常自己出尖刺,和你的一样,但是他的搞下拉也不管用,引脚直接接地也不管用,最后换成了长高,下降沿中断。也就是把下拉换成了上拉。

消息队列用错了。完全破坏了消息队列池。
一个消息队列,一经初始化,消息的长度就是固定的了。
也就是说 rt_mq_send 的第三个参数应该是个固定值了,第二个参数是这个固定字节长度的消息体。消息体内包含你的数据。
你把数据指针当成消息体,内部一直认为你的消息长度是 USART_RBUFF_SIZE - sizeof(void*) 这么长。所以第三次,你认为是一个字节,它认为有这么长。然后你接收打印用的字符串打印,当然会出现上一次的字符了。

回到
顶部

发布
问题

投诉
建议