This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] CC1310:在 uartEcho 示例中提高 UART 的性能

Guru**** 1825110 points
Other Parts Discussed in Thread: CC1310, CC1311R3
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1392828/cc1310-improving-the-performance-of-uart-in-uartecho-example

器件型号:CC1310
主题中讨论的其他器件: CC1311R3

工具与软件:

似乎 UART_READ()函数在从 UART 返回数据时有一个无法解释的延迟。 下面的屏幕截图显示了 UART RX 和 TX 引脚。 在 CC1310 Launchpad 上运行的 UART Echo 示例(无 RTOS、CCS、CC1310)中、8个字节的线路接收序列在8.8ms 内完成(对于9600波特、偶校验和1个停止位、更新 uartParams)。 回波实现在24ms 内在线路上传输8个字节。  

显然、这是不可持续的、因为 UART 缓冲区将溢出、因为传输所需的时间是接收时间的3倍。  

代码如下所示。 除了数据速率、奇偶校验位和停止位之外、它与 CC1310的无 RTOS、CCS 编译器示例相同。  

void *mainThread(void *arg0)
{
    char        input;
    const char  echoPrompt[] = "Echoing characters:\r\n";
    UART_Handle uart;
    UART_Params uartParams;

    /* Call driver init functions */
    GPIO_init();
    UART_init();

    /* Configure the LED pin */
    GPIO_setConfig(Board_GPIO_LED0, GPIO_CFG_OUT_STD | GPIO_CFG_OUT_LOW);

    /* Turn on user LED */
    GPIO_write(Board_GPIO_LED0, Board_GPIO_LED_ON);

    /* Create a UART with data processing off. */
    UART_Params_init(&uartParams);
    uartParams.writeDataMode = UART_DATA_BINARY;
    uartParams.readDataMode = UART_DATA_BINARY;
    uartParams.readReturnMode = UART_RETURN_FULL;
    uartParams.readEcho = UART_ECHO_OFF;
    uartParams.baudRate = 9600;
    uartParams.parityType = UART_PAR_EVEN;
    uartParams.stopBits = UART_STOP_ONE;

    uart = UART_open(Board_UART0, &uartParams);

    if (uart == NULL) {
        /* UART_open() failed */
        while (1);
    }

    UART_write(uart, echoPrompt, sizeof(echoPrompt));

    /* Loop forever echoing */
    while (1) {
        UART_read(uart, &input, 1);
        UART_write(uart, &input, 1);
    }
}

要从8字节接收序列获取到传输第一个字节、有大约3.56ms 的静默时间! 什么会使1个字节的 UART_READ 花费如此长的时间到达 UART_WRITE? 为 TX 和 RX 启用两个 FIFO。 因此、在 RX 正在进行时、TX FIFO 应由 UART_Write 写入、一旦传输开始、就没有理由连续的字节会有2.3ms 的间隙!  

   

您能解释一下并提高性能吗? 谢谢。  

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    更多后续查询:

    1.您是否有一个具有偶校验的 UART Echo 示例,以及在其中处理奇偶校验错误? 如果是、请分享。

    2.禁用奇偶校验(删除之前发布的代码片段中的第25行)后、接收回调将在接收到第一个字节后立即执行。 请参见屏幕截图。

    不清楚为什么启用奇偶校验会导致代码的行为发生如此明显的变化。  

    请提供帮助。 谢谢你。  

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Manish:

    我们现在没有带宽来查看它。  

    您是否可以使用最新的 SimpleLink F2 SDK 进行相同的测量、例如使用 CC1312?

    https://www.ti.com/tool/SIMPLELINK-LOWPOWER-SDK

    谢谢、

    Marie H.

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Marie:

    感谢您的答复。 此时切换到 CC1312非常具有挑战性- CC1312是7x7 48引脚封装、而 CC1310是5x5 32引脚封装。

    几个问题:

    1. CC1310是停产还是指定为 NRND 的器件? 请提供建议、因为这将有助于做出正确的决定。

    2.此款 TI 驱动程序实施在一开始就非常简单易用。 但一旦我们开始使用它、 在没有 TI 提供更多示例或 E2E 响应支持的情况下、让它去做所需的事情比预期要困难一些。 那么、对于对 UART 的低级访问、驱动程序库是否优于 TI 驱动程序?

    我明白团队可能很忙。 尽管如此、我很低地要求您在具有偶校验和不具有偶校验的 CC1310LP 上运行上述 uartecho.c 中的示例片段、并建议我们接下来应如何进行。  

    谢谢你。  

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Manish:

    CC1312建议仅用于测试目的。 我们对 CC1312 UART 驱动程序进行了多项更改和更新。

    1.不。仍建议在新器件中使用 CC1310。 但是、如果您看一下软件页面、就会发现我们不再经常更新它。

    2.我建议使用驱动程序。 驱动程序库不供客户使用。

    谢谢、

    Marie H.

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    BTW、如果您考虑升级到较新的器件、那么您还应该查看 CC1311R3。 这个提供5x5封装。 不过、它没有传感器控制器。

    https://www.ti.com/product/CC1311R3#pps 

    谢谢、

    Marie

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    1.由于已经投入了软件、硬件和测试工作,因此更换设备可能有一定的难度。 我还看到5x5封装有40个引脚、因此其间距必须小于 CC1310。  

    2.虽然驱动程序库不供客户使用、但其结果是比适用于 UART 的 TI 驱动程序更容易、而且性能也 大幅提高。 即使是奇偶校验延迟也不存在、因此更容易知道器件中发生了什么情况。 启用奇偶校验时、UART 驱动程序很可能出现问题。

    3.对于软件更新和支持,取消旧设备的优先级不是一个好主意。 该器件系列非常出色、并且整个电路板都应提供支持。  

    我将问题标记为已解决-我们别无选择、只能使用 driverlib。 它已经解决了上述性能和功能问题。 谢谢!

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Manish:

    很高兴听到您使其正常工作!

    谢谢、

    Marie H.