媒体的建议请求

12个帖子/ 0新
最后一篇
马车
离线
最后一次露面:3年2个月前
加入:2015-01-14 17:58
媒体的建议请求

我搜索了这些论坛尽可能多的信息,我可以收集,我已经浏览了吞吐量_eval.sps源代码,我有点熟悉它们,并在一定程度上理解它们。对我来说,它们仍然有些不透明……也许你们都能迁就我一下。

我不需要超高的吞吐量…> 3 k字节/秒。我有一个中断,每2ms发生产生6字节。但我一直无法使用标准的GATT通知机制来实现这一点(如果我每4毫秒产生一个中断,我就开始丢失数据)。我的第一个问题是,有人觉得这不对吗?我保留一个20字节的数据包队列,通过GATT通知发送。我检查GATTC_CMP_EVT消息之后的队列,并计划发送下一个包(如果有可用的包)。系统无法跟上,在大约100个包之后就会失败(如果队列变大会更多,如果我以2毫秒的中断周期计时就会更少)。

假设上面的方法行不通,我看吞吐量_eval.项目。它似乎使用了多个特征(数据似乎是并行地写入到所有特征)和l2cap。对于我来说很难看到接收数据的客户端在这里做什么,因为没有例子。客户端是否也必须与l2cap进行交互?不幸的是,我的Windows电脑除了GATT以外什么都做不了,所以我不确定如何协调这一点。

SPS做了一件我认为你做不到的事。特征(SPS_SERVER_TX)的大小为128个字符。我不认为您可以通知这么大的对象(当我尝试它时,它没有工作)。也许我在这里漏掉了一些关键方面,但我也不知道这里的最大吞吐量应该是多少。

来自画廊的任何建议都会有所帮助。
谢谢,
马可

设备:
mt_dialog.
离线
最后一次露面:6个月2个星期前
职员
加入:2015-06-08 34
嗨marcodg,

嗨marcodg,

致敬,是系统中启用的睡眠吗?您应该能够使用这种速率发送数据,如果启用睡眠,您可能会在禁用中断时丢失数据,您还可以处理这些数据吗?你说系统失败了,它是否进入了硬盘处理程序?您如何发送通知?您在中断处理程序中填充队列并更新数据库中的值?

没有客户端不必与L2CAP进行交互。

DSPS项目发送MTU Exchange命令(如果他接受它,则允许主机,以接收更大的MTU),如果您愿意,可以尝试,但我认为这是您的问题。

谢谢mt_dialog.

马车
离线
最后一次露面:3年2个月前
加入:2015-01-14 17:58
谢谢你的回复。

谢谢你的回复。未启用睡眠模式。没有对数据的处理。中断填充队列,如果队列是空的,当它放入一个时,它发送一个初始消息给流任务发送队列中的下一个项目。流任务按照正常的过程处理此消息(通过将数据放入数据库并发送通知)。当GATTC_NOTIFY消息到来时,它检查是否有更多的包要发送,如果有,就给自己发送一条消息来发送队列中的下一个项目。所以它是无限的。它需要3个中断来填充一个包(18字节+ 2字节的状态)。在8毫秒的中断周期(125Hz, 24ms/包),一切工作都很好。事实上,队列中永远不会有超过1个条目。 With an interrupt period of 4ms (12ms/packet) the queue fills up. I get about 100 valid packets received at the client. I fully acknowledge that I may have screwed this machinery up somehow but if I did I don't know where... it's not that complicated.

(注意:在GATTC_NOTIFY上从队列中删除包,以防止多个消息/包在循环中。我一开始就遇到了这个问题,导致队列低于空队列……谢天谢地,在随后发生的灾难中,没有人或宠物受到伤害。)

连接间隔是默认值(我认为7.5或8ms IIRC)。

谢谢,
马可

mt_dialog.
离线
最后一次露面:6个月2个星期前
职员
加入:2015-06-08 34
嗨marcodg,

嗨marcodg,

你能试着从ISR....设置一个标志吗然后检查app_asynch_trm中的标志,如果设置了该标志,则将消息发送到流任务。也许是从ISR发送到流任务的消息导致了您所面临的问题。当你连接并发送数据时(当它失败或不失败时),你能上传一张Smart Snippers图片吗?

谢谢mt_dialog.

马车
离线
最后一次露面:3年2个月前
加入:2015-01-14 17:58
从ISR设置标志

将标志从ISR设置并作为主循环的一部分发送消息似乎没有帮助。我挂钩了一个范围并翻了一个gpio bit。当我将中断率设置为足够低(<180 Hz,每16.7ms时)数据包发送时的时间以及当我获得gattc_notify时(如果可用,我可以发送下一条消息)是大约800us,偶尔闪烁高达1.2ms。那里很稳定。当速度超过195Hz以上的东西时,在范围上,我能够衡量数据包之间的时间,并且在许多实例中发送了Gattc_notify> 55ms。当这些长时间的足够的时候,队列填满了。我将在获取智能代码段图像(我还没有使用那个软件)。

(编辑:SmartSnippets似乎有问题,因为它找不到ftd2xx.dll。我有Windows 10…)

mt_dialog.
离线
最后一次露面:6个月2个星期前
职员
加入:2015-06-08 34
嗨marcodg

嗨marcodg

来自智能片段的图像将会有所帮助,您是否通过等待前一个GATTC_NOTIFY完成事件来触发发送下一个包?
你能试着不等待就发送信息吗?

谢谢mt_dialog.

马车
离线
最后一次露面:3年2个月前
加入:2015-01-14 17:58
谢谢您的回复。一世

谢谢您的回复。我需要一些关于“智能片段”的指导。我有SmartSnippets启动(下载驱动程序),可以下载代码并让它运行。但在那之后,我真的不知道该做什么。我在右下角看到一个“数据速率监视器”,但按下按钮似乎没有效果。我应该注意到我使用的是PAN1740模块。

在其他新闻中,我尝试从23到87增加MTU大小,认为如果我可以发送它将工作的数据包更少。虽然它确实允许我增加频率(高达约240hz),但它仍然以相同的方式失败。在发送数据包和GattC_Notify之间的时间非常长,在这种情况下大约60ms,这比所需的分组频率长。

如果我没有等待GATTC_NOTIFY并在它准备好时发送一个包,例如,每52.8毫秒对应于87字节的MTU(我需要每32ms一个包),包就会在源处被丢弃。我发的包里有序列号。这些值是非连续的。通常只有一个数据包被丢弃,但我看到多达两个。

我继续检查代码,以确保我没有搞砸。

马车
离线
最后一次露面:3年2个月前
加入:2015-01-14 17:58
还是没找到。我试着

还是没找到。我尝试使用L2CC(如横向_eval项目),但在吞吐量率较高,在GATT失败的位置,设备将重置。在较高的中断速率下,GATTC_NOTIFY消息需要太长的发送,填写队列。如果我不等待邮件报文得出,即使它们仅在每50毫秒(87字节MTU)约为1个数据包时。我尝试改变MTU的大小,但除了更大的数据包做得更好的情况下,似乎并没有帮助。

我更改了代码,以便在ISR本身中没有发生实际处理。KELMEL消息作为APP_ASYNCH_TRM()函数的一部分发送。

GATTC_NOTIFY需要这么长的时间是一个谜,因为在较低的中断速率下,发送/等待过程只有几毫秒。

mt_dialog.
离线
最后一次露面:6个月2个星期前
职员
加入:2015-06-08 34
嗨marcdg,

嗨marcdg,

你能给我们发送一些智能片段的活动吗,也许我们可以看看并找到一些东西。

谢谢mt_dialog.

马车
离线
最后一次露面:3年2个月前
加入:2015-01-14 17:58
我不能变得聪明

我无法获得智能片段工作。该设备是松下1740.我有定义的CFG_StreamData以及度量标准。我可以将代码下载到设备(jlink),但数据箱监视器只支持COM端口。通常,“开始外设”按钮没有效果,其余时间显示错误。

马车
离线
最后一次露面:3年2个月前
加入:2015-01-14 17:58
我想我发现了这个问题。

我想我发现了这个问题。使用Wireshark我能够跟踪客户端(运行Windows 10的PC)的对话。每个L2CAP片段后,我可以看到通过空的PMU数据包在响应的PC响应。有时,响应需要太长,强制数据以备份我的设备。我不是一个专家,所以你可以确认客户端(以空的PMU形式)需要在下次传输的数据包之前发生吗?

谢谢
马可

mt_dialog.
离线
最后一次露面:6个月2个星期前
职员
加入:2015-06-08 34
嗨marcodg,

嗨marcodg,

我们无法从你上传的日志中看出什么(在你的另一篇文章中,我假设你正在检查同样的情况),因为一些数据包似乎丢失了。一般情况下,主机在每个连接间隔中用空pmu或数据包(如果需要发送一些东西)轮询设备。有了这些包,主机就有能力确认设备发送的前一个包已被接收,并执行某种流控制。如果数据包没有被确认,那么它必须重新发送。换句话说,如果主机明确地不承认一个包,那么设备就不能发送另一个包,直到这个包最终从主机得到承认。这样主机就可以阻止设备发送更多的数据包。无论如何,主机总是轮询设备!因此,您报告的主机在发送空的POLL包时停止是一个问题,如果它确实发生并且不是由嗅探器产生的,而嗅探器似乎不是很可靠。

谢谢mt_dialog.