我已经将这些论坛搜索了尽可能多的信息，并且我看过了throughput_eval和sps系统源代码和我有点熟悉他们和理解他们的程度。它们对我来说确实有些不透明。。。也许你们都能在这里取笑我。
我不需要超高的吞吐量。。。>3k字节/秒。我有一个中断，每2ms发生一次，产生6个字节。但是我无法使用标准的GATT通知机制来实现这一点（如果我每4ms生成一个中断，我就开始丢失数据）。所以我的第一个问题是，有人觉得这不对吗？我保留了一个由20字节数据包组成的队列，以便通过GATT通知发送。我检查GATTC\u CMP\u EVT消息之后的队列，并安排发送下一个数据包（如果有）。系统跟不上，在大约100个数据包之后就失败了（如果我把队列调大的话会更多，如果我以2ms的中断周期计时的话会更少）。
所以，假设上面的不起作用，我看了throughput_eval项目。它看起来它使用多种特征（数据似乎并行地写入所有特征）和L2CAP。我很难看看在这里接收数据在这里在这里做什么，因为没有示例。客户是否必须与L2CAP进行互动？不幸的是，我的Windows PC没有任何东西，但Gatt所以我不确定如何协调它。
SPS做了我认为你做不到的事。特征（SPS\u SERVER\u TX）的大小为128个字符。我认为你不能通知这么大的物体（当我尝试时，它不起作用）。也许我在这里遗漏了一些关键的方面，但是我也不知道这里的最大吞吐量应该是多少。
Any advice from the gallery would be helpful.
谢谢，
marco
关键词：
设备：
嗨marcodg，
To beggin with, is the sleep enabled in the system? You should be able to send data with this kind of rate, if the sleep is enabled you may lose data when the interrupts are disabled, also do you process these data? You said that the system fails, does it goes to a hardfault handler ? Also how do you send the notifications? You populate the queue in the interrupt handler and update the value in the database ?
No the client doesn't have to interact with the l2cap.
The DSPS project sends a mtu exchange command (this allows the host, if he accepts it, to receive bigger mtu's), you can try it if you like but i think that this is your problem.
Thanks MT_dialog
谢谢你的回复。睡眠模式未启用。没有数据处理。中断将填充队列，如果在放入队列时队列为空，则会向流任务发送初始消息，以发送队列中的下一项。。流任务在正常过程中处理此消息（通过将数据放入数据库并发送通知）。当GATTC\u NOTIFY消息出现时，它检查是否有更多的数据包要发送，如果有，则向自己发送一条消息以发送队列中的下一个项目。这就是无穷大。填充一个数据包需要3次中断（18字节+2字节的状态）。在8ms（125Hz，24ms/包）的中断周期内，一切正常。事实上，队列中放入的项目永远不会超过1个。中断时间为4ms（12ms/包），队列将填满。我在客户端收到大约100个有效数据包。我完全承认我可能把这台机器搞砸了，但如果我搞砸了，我不知道在哪里。。。没那么复杂。
（注意：数据包从GATTC\ U NOTIFY上的队列中删除，以防止多个消息/数据包循环。一开始我遇到了这个问题，导致排队的人都空了。。。谢天谢地，没有人或宠物在随后的灾难中受到伤害。）
The connection interval is whatever the default is (I think 7.5 or 8ms IIRC).
谢谢，
marco
嗨marcodg，
您可以尝试使用ISR的标志....然后在App_Asynch_trm中检查标志，如果设置标志，则将消息发送到流键任务。也许从ISR发送到Streaming任务的消息会导致您面临的概要。您是否可以在连接和发送数据时上传智能播播器图像（当它失败时以及没有）？
Thanks MT_dialog
从ISR设置标志和sending the message as part of the main-loop doesn't seem to help. I hooked up a scope and flipped a GPIO bit. When I set the interrupt rate low enough (< 180 Hz, packet every 16.7ms) the time between when the packet is sent and when I get the GATTC_NOTIFY (and I can send the next message if available) is about 800us, with the occasional flash up to 1.2ms. It's pretty stable there. When the rate gets above 195Hz things go haywire on the scope but I was able to measure that the time between the packet was sent and GATTC_NOTIFY in many instances was >55ms. When enough of these long intervals go by, the queue fills up. I will work on getting the Smart Snippets image (I haven't used that software yet).
（编辑：某些东西似乎是SmartSnippets，因为它找不到ftd2xx.dll。我有Windows 10 ......）
你好，马可德
来自智能代码片段的图像会有所帮助，您是否通过等待上一个GATTC\u NOTIFY completetion事件来触发下一个数据包的发送？
你能尝试在没有等待的情况下发送消息吗？
Thanks MT_dialog
谢谢你的回复。我需要一些关于“聪明片段”的指导。我有SmartSnippets启动（下载了驱动程序），可以下载代码并让它运行。但在那之后，我真的不知道该怎么办。我在右下角看到一个“数据速率监视器”，但按下按钮似乎没有效果。我应该注意，我使用的是PAN1740模块。
In other news, I tried increasing the MTU size from 23 to 87, thinking that if I could send fewer packets it would work. While it does allow me to increase the frequency (up to about 240Hz) it still fails in the same way. The time between when the packet is sent and GATTC_NOTIFY gets really long, about 60ms in this case, which is longer than the required packet frequency.
如果我不等待GATTC\u通知并在数据包准备好时发送数据包，比如说，每52.8ms发送一个与87字节MTU相对应的数据包（我需要每32ms发送一个数据包），数据包就会在源位置丢弃。我发送的数据包中有一个序列号。这些值是不连续的。通常只有一个包被丢弃，但我已经看到多达两个。
我正在继续检查代码，以确保我没有弄错。
还是没什么好运气。我试过了using l2cc (like the throughput_eval project) but at higher throughput rates, around where it was failing with GATT, the device would go into reset. At higher interrupt rates, the GATTC_NOTIFY message takes too long get sent, filling up the queue. If I don't wait for the message packets get dropped, even when they are only coming at around 1 packet per 50ms (87 byte MTU). I've tried varying the size of the MTU but that doesn't seem to help except that larger packets do marginally better.
I changed the code so that no real processing happens in the ISR itself. The kermel messages are sent as part of the app_asynch_trm() function.
GATTCèu NOTIFY需要这么长的时间这一事实是个谜，因为在较低的中断率下，发送/等待过程只需要几毫秒。
你好，马奇，
你能发给我们一些智能片段活动，也许我们可以看看并找到一些东西。
Thanks MT_dialog
我无法聪明-snippets to work. The device is a Panasonic 1740. I have CFG_STREAMDATA defined as well as METRICS. I can download code to the device (jlink), but the datarate monitor only supports a com port. Usually the 'start peripheral' button has no effect, the rest of the time it displays an error.
我想我找到问题了。Using wireshark I was able to track the conversation from the client (a PC running Windows 10). I can see the PC responding with empty PMU packets after every L2CAP fragment. Sometimes that response takes too long, forcing data to get backed up on my device. I'm not a BLE expert, so can you can confirm that a response from the client (in the form of an empty PMU) needs to occur before the next transmitted packet?
thanks
marco
嗨marcodg，
我们无法从你上传的日志中看出什么（在你的另一篇文章中，我假设你正在检查同一个案例），因为有些数据包似乎丢失了。通常，主机在每个连接间隔内都会使用空pmu或数据包（如果需要发送某些内容）轮询设备。通过这些数据包，主机能够确认设备发送的前一个数据包已被接收，并执行某种流控制。如果数据包未被确认，则必须重新发送。换句话说，如果主机显式地不确认一个数据包，那么设备就不能发送另一个数据包，直到这个数据包最终被主机确认。这样主机就可以阻止设备发送更多的数据包。无论如何，主机总是轮询设备！因此，您所报告的主机在发送空的轮询数据包时暂停是一个问题，如果它确实发生并且不是由嗅探器生成的（嗅探器看起来不太可靠）。
Thanks MT_dialog