问题解决：星闪SLE一对多情况下速率不均且容易断联的问题

Viewed 2
bearpi_bm_h63

8月13号笔记
问题解决：星闪SLE一对多情况下速率不均且容易断联的问题
本次历程的仓库：
方案源代码

前提说明：虽然7月份星闪SLE的北向内容开源了，但是对于我们南向的开发者，还是很折磨，他那套适应于OpenHarmony的东西想要自己魔改以后移植到liteOS还是一个不小的工程。所以我们这里所提及的“问题解决”，本质上是提供一种工程方法而非理论方法，因为实际上来讲，SLE的基础服务层，或者说这个协议栈，到底在干嘛这件事，对于我们来说是透明的，或者说是一个黑箱，我们只能通过不断尝试来找到一些个解决方法。

问题描述：
在星闪SLE一对多链接后，在所有从机代码完全相同，只有物理地址改变的情况下，通信的速率每个从机相差很大且通信容易发生断联。
如下三张图所示，这三张图对应地是三个不同的从机在同一次链接当中的通信速度，可以看到三者的通信速度差距很大，最低3620us，最高6505us，而且这还是很好的情况，在最差的情况下，可能最快的可以达到平均2600us，但是最低的却有100000us，且整个通信过程的波动也很大。
同时，该过程又容易发生断联，断联的原因是因为从机自己挂了重启，但这个我忘记截图了，能理解就好。



解决方法：
其实很简单，就在每个的发送之后添加一个sleep就可以了，释放掉对于cpu的控制。

/**
 * @brief 组包并通过 SLE 发送一个测试包
 * @param pkt_seq         包序号
 * @param frame_seq_start 本包首个子帧帧号
 */
static void sle_imu_server_send_test_packet(uint16_t pkt_seq, uint32_t frame_seq_start)
{
    static uint8_t send_buf[SLE_IMU_PACKET_LEN];
    sle_imu_build_packet(send_buf, SLE_SERVER_NODE_ID, pkt_seq, frame_seq_start,
                          SLE_IMU_TEST_ACCEL_FSR, SLE_IMU_TEST_GYRO_FSR, g_sle_imu_test_data);
    errcode_t ret = sle_uart_server_send_report_by_handle(send_buf, SLE_IMU_PACKET_LEN);
    if (ret != ERRCODE_SLE_SUCCESS) {
        osal_printk("%s send fail pkt_seq=%u ret=%x\r\n", SLE_UART_SERVER_LOG, pkt_seq, ret);
    }
    osal_msleep(5);  /* 发包后间隔 5ms, 让出 CPU 给协议栈 */
}

然后由于Liteos的这个sleep的具体时间控制做的一坨，实际睡眠时间差不多20ms，但是这样就把发送给对齐了，效果如下。
首先是对于发送端，发送的速度虽然慢了，但胜在稳定，可以稳定的保持在20ms左右，且峰值波动不超过1ms，这就大大的保证了通讯的相对实时性。

而在接收端，在一对四的情况下，平均接收也是稳定在20ms左右，且波动可能只有100%，更好的地方是他的链接很稳定，在昨晚的实际测试当中，运行2小时不会出现断联的情况。

想了一下，该问题实际上可以拆分为两个问题，但是这两个问题都同一个解决方案。
1、为什么SLE的通讯是这么的不均匀？
2、为什么从机容易死机重启？
这两个问题的原因，在我的猜想当中，是因为任务对于协议栈的过分控制，对于第一个问题，如果一个从机不断的发送，抢占了这个通信，让其他的使用不了信道，那他不就发的快而其他的的发的慢，所以就出现这个不均匀的问题了。对于第二个问题，则是CPU被这个任务过分占据，导致协议栈执行异常，所以重启。
而在sleep添加之后，CPU得以充分的被协议栈使用，大家可以相互交互协调这个通信过程，而不是相互上强度搞对抗，而且20ms的延迟使得通信压力下来了，所以通信才得以正常使用。
但是实际上这个猜想是不一定成立的，这是因为SLE本质上是一个同步时分多路复用，不应该存在一家独大的问题，但是由于SLE的协议栈对于我们是透明的，所以难以验证。
如果想看看，欢迎访问源代码，用的是小熊派的sdk
源代码
复现问题的步骤：
当前的是已经使用了sleep优化的了
如果需要复现的话，将sle_uart.c的119行的
osal_msleep(5); /* 发包后间隔 5ms, 让出 CPU 给协议栈 */
注释掉即可看到所谓的 链接速率不均且容易断联的问题（尽可能越多从机越明显）

fallbles1
0 Answers