我爱蓝牙网 - 52Bluetooth - 最具人气蓝牙技术交流网站

标题: 有关CSR8670 uart 接收数据的问题 [打印本页]

作者: 米迦勒 时间: 2016-12-12 08:52
标题: 有关CSR8670 uart 接收数据的问题
谁知道，CSR8670 uart 在接收数据时，为什么接收的第一个字节总是会产生一条消息啊，这是CSR的bug吗，还是有解决的办法，谢谢！

作者: wyq0324 时间: 2016-12-12 08:52
不管收到多少MESSAGE_MORE_DATA,只要你不清理，所有收到的数据会存储在Source的内存空间里，直接用这段内存空间就可以啊！

作者: mupro 时间: 2016-12-12 10:41
接收一个串，都是产生好几次消息的
规定一个接收格式，或者接收超时处理都可以

作者: wgc2013 时间: 2016-12-12 11:51

作者: 米迦勒 时间: 2016-12-12 16:32

mupro 发表于 2016-12-12 10:41
接收一个串，都是产生好几次消息的
规定一个接收格式，或者接收超时处理都可以

接收一个串不能只产生一次消息吗，如果接收一个串，产生好几次消息，处理起来会非常麻烦，需要将接收到数据存储起来，而CSR本身资源有限，我处理的数据包需要一个261个字节的空间，分配空间的时候一运行系统就会崩溃；而如果只产生一次消息，我就可以直接处理SourceMap的数据，会很容易

作者: 米迦勒 时间: 2016-12-12 16:33

wgc2013 发表于 2016-12-12 11:51

这是什么表情

作者: mupro 时间: 2016-12-12 16:34

米迦勒发表于 2016-12-12 16:32
接收一个串不能只产生一次消息吗，如果接收一个串，产生好几次消息，处理起来会非常麻烦，需要将接收到 ...

不能的，必须多次。
内存申请不要定义数组，用指针加malloc

作者: 米迦勒 时间: 2016-12-12 16:41

mupro 发表于 2016-12-12 16:34
不能的，必须多次。
内存申请不要定义数组，用指针加malloc

我就是用的malloc，超过140个字节 malloc(140),就panic了。。。。

作者: wyq0324 时间: 2016-12-12 16:45
如果不drop的话，字符串会一直存储在Source映射的内存空间里，不用再额外分配。

作者: 米迦勒 时间: 2016-12-12 16:45

mupro 发表于 2016-12-12 16:34
不能的，必须多次。
内存申请不要定义数组，用指针加malloc

还请大神指教啊

作者: 米迦勒 时间: 2016-12-12 16:50

wyq0324 发表于 2016-12-12 16:45
如果不drop的话，字符串会一直存储在Source映射的内存空间里，不用再额外分配。

这个我知道，但是最开始我不是说，通过uart接收数据会分成几包数，产生好几个MESSAGE_MORE_DATA消息，如果这样的话，就需要把数据统一存储起来然后再进行处理了

作者: 米迦勒 时间: 2016-12-12 16:55

wyq0324 发表于 2016-12-12 16:45
如果不drop的话，字符串会一直存储在Source映射的内存空间里，不用再额外分配。

而且如果这样的话，有可能会造成映射的内存空间溢出吧~~

作者: 米迦勒 时间: 2016-12-12 16:58

wyq0324 发表于 2016-12-12 16:54
不管收到多少MESSAGE_MORE_DATA,只要你不清理，所有收到的数据会存储在Source的内存空间里，直接用这段内存 ...

source的内存映射空间有多大啊

作者: wyq0324 时间: 2016-12-12 16:59

米迦勒发表于 2016-12-12 16:55
而且如果这样的话，有可能会造成映射的内存空间溢出吧~~

通过malloc分配的空间不会比source映射的空间大。

数据当然要及时处理了，定义数据格式或分隔符，检测到一包数据后就处理和清理掉。

作者: 米迦勒 时间: 2016-12-12 17:02

wyq0324 发表于 2016-12-12 16:59
通过malloc分配的空间不会比source映射的空间大。

数据当然要及时处理了，定义数据格式或分隔符，检测 ...

嗯我按照您的这个方法试试多谢

作者: wgc2013 时间: 2016-12-14 09:41

作者: 米迦勒 时间: 2016-12-14 16:10

wyq0324 发表于 2016-12-12 16:59
通过malloc分配的空间不会比source映射的空间大。

数据当然要及时处理了，定义数据格式或分隔符，检测 ...

实施过程中遇到了一个问题，如果数据没有按照指定的数据格式接收完，source缓冲区岂不是一直都不会清除吗

作者: wyq0324 时间: 2016-12-14 16:33

米迦勒发表于 2016-12-14 16:10
实施过程中遇到了一个问题，如果数据没有按照指定的数据格式接收完，source缓冲区岂不是一直都不会清除吗 ...

所以，你要加一个结束符，比如\r,标志本次发送结束，然后你就可以清除处理过的数据了。

作者: 米迦勒 时间: 2016-12-14 16:48

wyq0324 发表于 2016-12-14 16:33
所以，你要加一个结束符，比如\r,标志本次发送结束，然后你就可以清除处理过的数据了。

数据都没有按照指定的格式接收完全，应该也收不到结束符了吧。

作者: wyq0324 时间: 2016-12-14 17:00

米迦勒发表于 2016-12-14 16:48
数据都没有按照指定的格式接收完全，应该也收不到结束符了吧。

建议你查一下上位机是不是就没有发送完全！

即使没有接收完全，也会在收到下一个结束符时把数据清理，好过一直清理不掉！

作者: icersong 时间: 2016-12-14 17:01

mupro 发表于 2016-12-12 10:41
接收一个串，都是产生好几次消息的
规定一个接收格式，或者接收超时处理都可以

接收一个串不能只产生一次消息吗，如果接收一个串，产生好几次消息，处理起来会非常麻烦，需要将接收到数据存储起来，而CSR本身资源有限，我处理的数据包需要一个261个字节的空间，分配空间的时候一运行系统就会崩溃；而如果只产生一次消息，我就可以直接处理SourceMap的数据，会很容易

- 本文出自蓝牙音箱网，原文地址：http://www.52bluetooth.com/thread-15114-1-1.html

作者: 米迦勒 时间: 2016-12-14 17:28

wyq0324 发表于 2016-12-14 17:00
建议你查一下上位机是不是就没有发送完全！

即使没有接收完全，也会在收到下一个结束符时把数据清理， ...

正常运行情况下没有问题，我就是在测试异常处理，如果CSR能够自主识别，纠错能力更强，对上位机的依赖也没有那么大，这样不应该是更好吗

作者: youneversay 时间: 2016-12-16 17:39
都是大神，看你们的对话，不懂，但是我要记住

欢迎光临我爱蓝牙网 - 52Bluetooth - 最具人气蓝牙技术交流网站 (https://www.52bluetooth.com/)