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

注册于 7 months ago

回答
980
文章
23
关注者
65

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

image.png
这个路径下有个 package.py 文件,搜一下有没有?

想起来一件事情来,在你修改向量表地址之前,rtt 可能已经偷偷开中断了。

mdk 和 stutio 使用的编译器不一样,⊙﹏⊙b

上电配置过程是有一段时间是这样的,一直发中断,配置完成后就不发中断了,然后就是按屏幕的时候一直发中断,不按就不发。
检查一下你的屏使用的触摸芯片是哪款,核对iic 地址以及寄存器的地址等等。
rt_hw_gt9147_init 这个函数里有上电时序,时序对不对。别人写的代码也不一定那么完全可靠。自己全核查一遍才放心。

这种问题,根源不定在哪儿。有一个排查方法,你可以尝试一下。
先删减组件,从线程开始,然后是组件,板级组件,系统配置。
然后是反向添加,发现在某个部分删除和添加明显引起问题了,相关性很高的部分。重点检查那个部分。

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

这个确实跟节点树有很大关系,树越复杂,需要额外的节点越多,申请内存也越多。
比如你上面的那个 data 就是一个节点,它里面又有很多list节点,list 里面 又有 list 这个层次有七八层了吧。
其实 56k 的内存占用不算啥,加内存才是王道。

虽然没用过这个芯片,但是我猜上面的是外部晶振,很有用的,右边的是内部实时时钟使用的晶振,这个倒是可以省去的。
建议你把电路画上,元器件可以不焊接。

你的 rt_kprintf 支持浮点数?还是你自己加的?

libraries\pico-sdk\src\rp2_common\hardware_irq\irq_handler_chain.S
编译这个文件出错了,看一下这个文件。
这个文件有错的可能性很小。可能你用错编译器了,这个s文件的语法和编译器不兼容。

syswatch 就别用了吧,没啥作用,里面只有一个看门狗有实用性。但是看门狗自己怎么搞加不了?我的建议放弃 syswatch

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

回到
顶部

发布
问题

投诉
建议