你好,
我们正在构建一个音频流应用程序，其中中央将压缩音频发送到外围设备。
在外设上，我们有一个外部音频处理器，它每8毫秒切换一个GPIO线来中断DA14580。作为响应，DA14580通过I2C向处理器输出71字节的数据流。I2C数据传输是中断驱动的。外围设备不能向中心传输数据。注意，我们的外围设备在Boost模式下运行。
当没有启用睡眠时，这可以正常工作。
当启用长时间睡眠(使外围设备始终保持清醒)时，每次唤醒都会执行BLE_WAKEUP_LP_Handler中的以下等待循环。
GetBits32(BLE_INTSTAT_REG, SLPINTSTAT) ||
如果(t)休息;
这个循环以及接下来的BLE_SLP_Handler似乎只需要不到5毫秒就可以完成。作为较低优先级的中断，任何GPIO或I2C isr都将被暂停，直到唤醒完成。这会中断到处理器的数据流。
事实上，I2C传输足够快，我可以推迟数据传输的开始，直到唤醒完成。仍然存在的问题是，当I2C传输正在进行时，唤醒可能会开始，从而中断流量。
我可以在等待循环中手动服务GPIO和I2C任务。我能够让这工作为I2C的一组特定参数，连接参数等，但它似乎不健壮。很明显，这样的方法可以延迟唤醒的过程，我不确定这会有什么影响。
作为一种替代方案，我想研究一下是否可以将等待循环从BLE_WAKEUP_LP_Handler中取出并在主循环中执行—例如在app_sleep_exit_proc()中。这应该允许执行GPIO和I2C中断，同时保持主循环，直到唤醒完成。然而，这似乎并不奏效。
欢迎提出任何建议。
提前谢谢,
Sandeep
-----------
设备:
嗨Sandeep Sira,
我理解你的问题，但你所做的事情我们不能保证它会工作，你看到的低于5ms的时间是XTAL需要解决的时间，如果破坏了这些功能中的任何一个，你就有可能错过BLE事件。我能推荐的是，因为你有你的外设，BLE不会节省你太多的电力，所以我建议你保持BLE打开，同时有音频处理。
由于MT_dialog
嗨MT_dialog,
谢谢您的及时回复。
我已经通过等待任何正在进行的I2C事务在执行唤醒等待之前完成来解决这个问题。只要交易时间小于3毫秒，我就可以了，对吧?由于GPIO中断被暂停，进一步的事务将被阻止启动。
你能给我指一份外围设备的功耗分析吗?我们的音频处理器是1毫安@ 1.5 V，所以一切都算数。
谢谢,
Sandeep
-----------
嗨Sandeep,
在唤醒时，应该避免延迟LP处理程序的执行。XTAL16M应该尽快启用。然后LP在while循环中等待，以便被解除断言，然后代码立即跳转到SLP。关键是不要延迟LP到SLP的过渡。如果在等待LP去断言的同时启动I2C事务，并且在去断言之前完成事务，那么应该没问题，但是不能为了I2C事务完成然后执行LP而延迟LP的执行3ms，也不能延迟LP到SLP的过渡。如果这样做，您将面临BLE连接的问题。
我们还建议在您的应用程序上尝试和测量580能够进入睡眠(使用gpio)的时间，并检查它是否值得额外的复杂性，以及睡眠/唤醒过程的惩罚是否为您进入睡眠时带来任何实际的功率好处。如果睡眠时间不是很长，也许你应该重新考虑睡眠方案，让你的580在流媒体时始终保持清醒。
这取决于您使用的连接间隔，在您的情况下，连接间隔应该很小，以避免延迟。
我们希望我们没有误解您的系统配置，也没有以任何方式误导您。
由于MT_dialog
嗨MT_Dialog,
再次感谢您的回复。的确，你对我们的情况了解得很正确，你的意见很有帮助，而且与我所期望的完全一致。
我已经使用GPIO线告诉我关于睡眠事件，但也许您可以建议我应该假设退出睡眠的确切位置(从功率绘制的角度)。
它是否在指令之后的BLE_WAKEUP_LP_Handler中
SetBits16 (CLK_RADIO_REG BLE_ENABLE 1);// BLE时钟使能
(PMU_CTRL_REG RADIO_SLEEP 0);/ /启动!注意:系统必须运行在16MHz时，为RADIO_PD供电。
还是应该在完成BLE_SLP_Handler之后?
我接受了指令后就会进入无线电睡眠
SetBits16 (PMU_CTRL_REG RADIO_SLEEP 1);
在main()。
我试图得到一个测量实际当前draw在各种情况下，但这将花我一些时间。
谢谢,
Sandeep
-----------
嗨Sandeep,
您可以在WFI()之前关闭外设之前将它放在主循环中，在外设初始化之后将它放在LP处理程序中。
由于MT_dialog
谢谢你的帮助。
Sandeep
-----------