我已经将这些论坛搜索了尽可能多的信息，并且我看过了throughput_eval和SPS.源代码，我有点熟悉它们并了解他们的程度。他们确实对我来说仍然有点不透明......也许你们都可以在这里幽默。
我不需要超级高吞吐量...> 3k字节/秒。我有一个发生的中断，它会产生6个字节的每2ms。但是我一直无法使用标准的GATT通知机制实现这一点（如果我每4ms生成中断，则我开始丢失数据）。所以我的第一个问题是，对任何人来说似乎是错误的吗？我保留了20个字节数据包的队列来通过GATT通知发送。我在gattc_cmp_evt消息后检查队列，并将计划发送到发送下一个数据包如果可用。系统无法跟上，并且在大约100个数据包之后失败（如果我使队列更大，则在2ms中断时段时的时钟更少）。
所以，假设上面的不起作用，我看了throughput_eval项目。它看起来它使用多种特征（数据似乎并行地写入所有特征）和L2CAP。我很难看看在这里接收数据在这里在这里做什么，因为没有示例。客户是否必须与L2CAP进行互动？不幸的是，我的Windows PC没有任何东西，但Gatt所以我不确定如何协调它。
SPS做了什么我不认为你能做的事情。特征（SPS_SERVER_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_NOTIFY消息来临时，它会检查是否有更多的数据包才能发送，如果是，请发送一条消息以在队列中发送下一个项目。所以它是无限的。填充数据包需要3个中断（18个字节+ 2个字节的状态）。在8ms的中断时期（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上删除数据包，以防止传送多个消息/数据包。我有这个问题首先导致队列低于空的......庆幸没有人类或宠物在随后的灾难中受到伤害。）
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 ......）
嗨Marcodg.
来自Smart Scippets的图像将有助于，您是否通过等待以前的GattC_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_Notify并在准备就绪时发送数据包，例如，每隔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_notify需要很长时间的事实是一个谜，因为在较低的中断速率下，发送/等待过程只是几个ms。
嗨marcdg，
你能发给我们一些智能片段活动，也许我们可以看看并找到一些东西。
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