媒体的建议请求

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

我已经将这些论坛搜索了尽可能多的信息,并且我看过了吞吐量_eval.spssource code and I am somewhat familiar with them and understand them to a degree. They do remain somewhat opaque for me... perhaps you all can humor me here.

一世don't need super high throughput... >3k bytes/second. I have an interrupt that happens every 2ms that generates 6 bytes. But I have been unable to achieve this using the standard GATT notification mechanism (If I generate an interrupt every 4ms, I start losing data). So my first question is, does this seem wrong to anyone? I keep a queue of 20 byte packets to send via GATT notification. I check the queue after the GATTC_CMP_EVT message and schedule to send the next packet if one is available. The system can't keep up and it fails after about 100 packets (more if I make the queue bigger, much less if I clock at a 2ms interrupt period).

所以,假设上面的不起作用,我看了吞吐量_eval.项目。它看起来它使用多种特征(数据似乎并行地写入所有特征)和L2CAP。我很难看看在这里接收数据在这里在这里做什么,因为没有示例。客户是否必须与L2CAP进行互动?不幸的是,我的Windows PC没有任何东西,但Gatt所以我不确定如何协调它。

SPS does something which I didn't think you could do. The characteristic (SPS_SERVER_TX) has a size of 128 characters. I didn't think you could notify an object that large (when I tried it, it didn't work). Perhaps I am missing some key aspect here but I also can't tell what the maximum throughput here should be.

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

Device:
mt_dialog.
离线
最后一次露面:1个月3周前
职员
加入:2015-06-08 11:34
嗨marcodg,

嗨marcodg,

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

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

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

谢谢mt_dialog.

马车
离线
最后一次露面:2 years 9 months ago
加入:2015-01-14 17:58
谢谢你的回复。

谢谢你的回复。不支持睡眠模式d. There is no processing of the data. The interrupt fills the queue and if the queue was empty when it puts one in, it sends an initial message to the streaming task to send the next item in the queue.. The streaming task processes this message (by putting the data in the database and sending the notification) in the normal course of things. When the GATTC_NOTIFY message comes, it checks to see if there are more packets to send and if so, sends itself a message to send the next item in the queue. And so it goes for infinity. It takes 3 interrupts to fill up a packet (18 bytes + 2 bytes of status). At an interrupt period of 8ms (125Hz, 24ms/packet) everything works great. In fact, the queue never gets more than 1 item put in it. 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.

(Note: packets are removed from the queue on the GATTC_NOTIFY to prevent multiple messages/packets in circulation. I had that problem at first causing the queue to go below empty... thankfully no humans or pets were harmed in the ensuing catastrophe.)

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

谢谢,
马可

mt_dialog.
离线
最后一次露面:1个月3周前
职员
加入:2015-06-08 11:34
嗨marcodg,

嗨marcodg,

您可以尝试使用ISR的标志....然后在App_Asynch_trm中检查标志,如果设置标志,则将消息发送到流键任务。也许从ISR发送到Streaming任务的消息会导致您面临的概要。您是否可以在连接和发送数据时上传智能播播器图像(当它失败时以及没有)?

谢谢mt_dialog.

马车
离线
最后一次露面:2 years 9 months ago
加入:2015-01-14 17:58
Setting the flag from the ISR

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

(编辑:某些东西似乎是SmartSnippets,因为它找不到ftd2xx.dll。我有Windows 10 ......)

mt_dialog.
离线
最后一次露面:1个月3周前
职员
加入:2015-06-08 11:34
Hi marcodg

Hi marcodg

An image from smart snippets would help, are you triggering the sending of the next packet by waiting the previous GATTC_NOTIFY completetion event ?
你能尝试在没有等待的情况下发送消息吗?

谢谢mt_dialog.

马车
离线
最后一次露面:2 years 9 months ago
加入:2015-01-14 17:58
谢谢你回复。一世

谢谢你回复。一世will need some coaching on "smart snippets". I got SmartSnippets to start up (downloaded the drivers) and can download the code and get it running. But after that, I'm not really sure what to do. I see a "Data Rate Monitor" on the lower right, but pushing the buttons don't seem to have an effect. I should note that I am using a PAN1740 module.

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

一世f I do not wait for the GATTC_NOTIFY and send a packet when it is ready, say, every 52.8ms corresponding to the 87 byte MTU (I require a packet every 32ms), packets get dropped at the source. I have a sequence number in the packet I send. The values are non-contiguous. Usually only one packet is dropped but I have seen as many as two.

一世am continuing to examine the code to make sure I'm not messing up.

马车
离线
最后一次露面:2 years 9 months ago
加入:2015-01-14 17:58
仍然没有运气。一世tried

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

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

The fact that GATTC_NOTIFY takes so long is a mystery because at lower interrupt rates, that send/wait process is only a couple of ms.

mt_dialog.
离线
最后一次露面:1个月3周前
职员
加入:2015-06-08 11:34
Hi marcdg,

Hi marcdg,

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

谢谢mt_dialog.

马车
离线
最后一次露面:2 years 9 months ago
加入:2015-01-14 17:58
我无法聪明

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

马车
离线
最后一次露面:2 years 9 months ago
加入:2015-01-14 17:58
我想我发现了这个问题。

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

谢谢
马可

mt_dialog.
离线
最后一次露面:1个月3周前
职员
加入:2015-06-08 11:34
嗨marcodg,

嗨marcodg,

We couldn't tell much from the log you uploaded (in your other post, i assume that you are examining the same case), as some packets seem to be missing. In general, the host polls the device in every connection Interval with either empty PMUs or data packets (if something needs to be sent). With these packets the host has the ability to acknowledge that the previous packet the device sent was received and also perform some kind of flow control. If the packet is not acknowledged then it has to be resent. In other words, if the host explicitly doesn't acknowledge a packet then the device cannot send another one until this packet is eventually acknowledged from the host. This way the host can block the device from sending more packets. In any case though, the host always polls the device! Thus, what you reported, that the host stalls in sending the empty POLL packets, is a problem, if it indeed happens and is not produced by the sniffer which does not seem very reliable.

谢谢mt_dialog.