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

注册于 6 months ago

回答
902
文章
19
关注者
55

放心,小问题,仅仅两个未定义而已,上面的文件里添加stddef.h头文件包含先

这种事儿以后会很常见,慢慢来

umqtt_ex_start 里添加调试信息,调试一下因为什么退出了,试试重新执行一下命令,还能不能连接上服务器。

程序跑飞了。可能性极高。这可能比 hard fault 还难排查

目测,是内核源码没下载成功,或者解压失败了。用 studio 就是,这么多尴尬。
重新选择内核版本,或者切换一下内核版本,倒腾两次切换回来试试。

我们知道,芯片的 GPIO 分组往往是从 PA 开始,往后依次是 PB PC PD PE ... PZ。往往的,每组端口或者是 16bit 或者是 8bit (分别对应 16 个 IO 和 8 个 IO)。下面给出 GET_PIN 的简化公式:

16bit 是 (X - A) * 16 + n

A10 就是 10.
C9 就是 2*16+9=41.
H1 就是 7*16+1=113.

8bit 是 (X - A) * 8 + n

这个公式别忘啊,别忘了

写日志,不需要总 seek 吧。文本文件不支持seek,没处理好会出问题的。
写文本文件默认要么擦了写,要么 append。
这个,可能去掉 seek 也就好了。

印象中,这个问题解决了啊。添加 m 函数库

应用程序的启动代码里,加一句关全局中断的汇编,类似这样

                CPSID   I
                LDR     R0, =SystemInit
                BLX     R0
                LDR     R0, =__main

你写的代码呢?
读写缓存从哪儿分配的?从线程栈上?线程栈大小够用?

这,,,env 就办不到了吧。手动从源仓库下载,然后拷贝到项目中使用?

  1. 先说说看门狗的问题,看门狗的优先级没那么重要,难有某个高优先级中断不断触发导致其它中断得不到响应。
  2. 多传感器采集,我的建议是放到一个线程里进行轮询,一个挨一个设备进行数据采集。采集的结果放到结构体里。这个数据整齐方便通信和传输。也能降低系统复杂度。
  3. 传递给 NB 线程。上面因为把数据结构化了,接收线程可以使用消息队列把结构体数据传输到 NB 线程。最后经由这个线程进行网络数据协议打包,传输到云端。

看看消息队列的用法就能解决数据传输的问题了

串口设备是数据流设备,数据包被拆包很正常,这个需要你自己在应用层自己进行整合和包边界检测。
这个跟 dma fifo 概念没有任何干系!!!
因为 dma fifo 根本不知道你的应用数据包有多长,协议规范是怎么定义的。而这些问题恰恰是应用层的责任!

首先,定义数据协议格式,要么定长,要么带包头包尾长度等。
然后,应用层根据前边的协议进行拼包,界定不同包数据,放到应用层缓冲区。
最后,整包(帧)数据进行数据处理。

无论定长还是变长,校验很重要

  1. env 环境没有搭建好,这个其实解压就能用的,什么也不用配置,也不用安装
  2. 打开上面提示里的那个 rtconfig.py 文件定位到 11行,把 .replace 以及后面的内容删掉,文件中其它类似错误地方也这么处理

回到
顶部

发布
问题

投诉
建议