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.

[参考译文] CC2564MODA:在 stm32F4上使用 DMA 实现 HCI 时出现问题

Guru**** 2588655 points
Other Parts Discussed in Thread: CC2564

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

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/684343/cc2564moda-problem-implementing-hci-using-dma-on-stm32f4

器件型号:CC2564MODA
主题中讨论的其他器件:CC2564

您好!

我们有一个使用 STM32F4和 CC2564的定制板。 我们需要将 HCI 连接到 DMA 以用于应用。 我们从 BlueTopia 堆栈的 hcitrans.dma 中的源开始。 我们注意到 了这些来源中的一个不一致之处:

作为参数传递给 HCITR_COMOpen()的回调例程在函数上方的注释中指示为返回值(为了实现某种流控制、这似乎是逻辑的):

/*以下函数负责打开 HCI */
/* Bluetopia 用于发送和接收的传输层*/
/* COM (串行)数据。 此函数必须在*/中成功发布
/* Bluetopia 的运行顺序。 此函数接受为其*/
/*参数要使用的 HCI COM 传输 COM 信息*/
/*以打开端口。 最后两个参数指定 HCI */
/*传输数据回调和回调参数(分别),*/
从 UART 接收数据时将调用/*。 成功*/
/*调用此函数将返回一个非零的正值,该值为*/
/*指定与其余*/一起使用的 HCITransportID
/*本模块中的传输功能。 此函数返回*/
/*表示错误的负返回值。 *
int BTPSAPI HCITR_COMOpen (HCI_COMMDriverInformation_t * COMMDriverInformation、
HCITR_COMDataCallback_t COMDataCallback、unsigned long CallbackParameter)

但是、它实际上在文件 HCITRANS.h 中被声明为"typedef void (BTPSAPI * HCITR_COMDataCallback_t)(unsigned int HCITransportID、unsigned int DataLength、unsigned char * DataBuffer、unsigned long CallbackParameter);"

我在这里错过了什么?

感谢你的帮助、

左通道

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

    您好!

    [引用 user="Laurent CHENU87"]但实际上它被声明为"typedef void (BTPSAPI *HCITR_COMDataCallback_t)( unsigned int HCITransportID、unsigned int DataLength、unsigned char *DataBuffer、unsigned long CallbackParameter);"在文件 HCITRS.h

    没错。 这意味着回调函数(在上层实现)将为 void 类型。 这是整个 BT 堆栈中使用的约定。 例如、SPP_Open_Server_Port API 中的回调函数指针具有 SPP_Event_Callback_t 类型、但 SPPAPI.h 中的 SPP_Event_Callback_t 类型声明为 typedef void。 因此、在应用中实现 SPP_Event_Callback 函数时、该函数将为 void 类型。

    [引用 USER="Laurent CHENU87]我们有一个使用 STM32F4和 CC2564的定制板。 我们需要将 HCI 连接到 DMA 以用于应用。 我们从 BlueTopia 堆栈的 hcitrans.dma 中的源开始[/quot]

    我建议使用 hcitrans.dma 文件夹中现有的 HCITRNS.c 文件作为起点、并在其中移植您的平台特定更改。 这样、您就可以按照 HCITR_COMDataCallback_t COMDataCallback 应该如何在 HCITRNS 函数中处理。

    此致、

    Vihang

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

    你的建议正是我所做的、而事实是它不起作用、这就是我发布原始消息的原因。
    我们的板需要同时使用 BLE 和 A2DP 以及 HFP 配置文件。 经过巨大的努力、我们实现了 A2DP 和 HFP_1.5 (这是 HCI 上需要高带宽的原因)、但在 HCI 上存在其他通信(使用 SPP)时、A2DP 上会出现失真。
    由于没有对原始 HCITrans.c 文件(在 DMA 目录中)进行其他修改、该设置适用于 A2DP、但仅适用于 HCI 的特定波特率。 波特率的上升会失败、在深入研究代码后、我得出结论:当 COMDataCallback ()不能接受更多数据时,它永远不会告诉我们,我们实际上会淹没上层。
    源文件中的注释之间存在矛盾、回调提供某种有关其是否成功的信息以调整带宽(例如在 HFP 中完成)似乎是合乎逻辑的。

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

    有关客户用例的更多信息:
    - Bluetopia 栈 v4.0.2.1
    -目标是在 HCI 通道上使用 A2DP ET HFP (因为需要使用 BLE)。 A3DP 和 HFP1.6不能使用。

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

    劳伦特

    [引用 user="Laurent CHENU87">经过巨大的努力、我们成功实现了 A2DP 和 HFP_1.5 (这是 HCI 需要高带宽的原因)、但在通过 HCI 进行其他通信(使用 SPP)时、A2DP 上会出现失真。 [/报价]

    首先、eSCO 数据(用于 HFP)将通过 CC256x 的 PCM 接口进行路由、因此 HFP 不应对 HCI UART 流量产生太大影响。  

    [引用 user="Laurent CHENU87">除了对原始 HCITrans.c 文件(在 DMA 目录中)进行其他修改外、该设置适用于 A2DP、但仅适用于 HCI 的特定波特率。 波特率的上升会失败、在深入研究代码后、我得出结论:当 COMDataCallback ()不能接受更多数据时,它永远不会告诉我们,我们实际上会淹没上层。 [/报价]

    回调函数的任务是将来自控制器的数据/事件发送到上层协议栈。 为什么回调函数会向 UART 驱动程序发送任何指示(某种流量控制)? 最好只调整 hcitrans 中的 UART 缓冲区大小、因为 UART 硬件流控制是基于这一点的。

    我认为对于这个 SDK 版本、所有示例应用的缺省 HCI 波特率为921600。 可能会针对这些设置对 hcitrans DMA 进行"微调"。 典型的 A2DP 流数据速率(328kbits/s)远低于921600。 为什么您需要为此应用使用更高的波特率?  

    [引用 user="Laurent CHENU87"]回调提供某种有关其是否成功的信息以调整带宽(例如在 HFP 中)的逻辑似乎是合理的[/quot]

    您能更具体一点吗、您在 HFP 中指的是什么/确切的是什么?

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

    [引用 user="Vihang"]

    首先、eSCO 数据(用于 HFP)将通过 CC256x 的 PCM 接口进行路由、因此 HFP 不应对 HCI UART 流量产生太大影响。  

    [/报价]

    是的、但是在我们的配置中、我们的编解码器连接到 STM32、我们使用 SCO_SET_physical 传输(BluetoothStackID、sptHCI)

    [引用 user="Vihang"]

    回调函数的任务是将来自控制器的数据/事件发送到上层协议栈。 为什么回调函数会向 UART 驱动程序发送任何指示(某种流量控制)? 最好只调整 hcitrans 中的 UART 缓冲区大小、因为 UART 硬件流控制是基于这一点的。

    我认为对于这个 SDK 版本、所有示例应用的缺省 HCI 波特率为921600。 可能会针对这些设置对 hcitrans DMA 进行"微调"。 典型的 A2DP 流数据速率(328kbits/s)远低于921600。 为什么您需要为此应用使用更高的波特率?  

    [/报价]

    我明白了。 我们将原始 HCITrans .c 文件原样保存在 DMA 目录中、并观察到 BT 组件向我们发送了大量数据、而在某一点上、整个过程都刚刚崩溃。 从理论上和从整体的角度来看,这不应该发生。 我们发现的唯一方法是微调波特率(466800波特)。

    [引用 user="Vihang"]

    您能更具体一点吗、您在 HFP 中指的是什么/确切的是什么?
    [/报价]
    我之前提到我们在应用中使用的'HFRE_Send_Audio_Data ()'、此回拨确实会在成功/失败时返回不同的值(并且事件 etHFRE_Audio_transmit 缓冲区 empty_indication 仅在回调失败时发出)。 如果需要、我可以通过 HCI 提供低音扬声器的日志文件。
    此致、  
    劳伦特

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

    [引用 USER="Laurent CHENU87"]是的,但是在我们的配置中,我们的编解码器连接到 STM32,我们使用 SCO_SET_physical 传输(BluetoothStackID、sptHCI)[/quot]

    SCO over HCI 是一种传统的操作模式、不建议使用、因为 PCM (默认模式)更可靠。 我确信、有多种方法可以通过 MCU 路由 PCM 接口。

    [引用用户="Laurent CHENU87">我理解这一点。 我们将原始 HCITrans .c 文件原样保存在 DMA 目录中、并观察到 BT 组件向我们发送了大量数据、而在某一点上、整个过程都刚刚崩溃。 从理论上和从整体的角度来看,这不应该发生。 我们发现的唯一方法是微调波特率(466800波特)。

    我明白了。 如果您在 MCU 端调试此功能时需要其他帮助、请联系我们的第三方合作伙伴之一(即 Cloud2GND)、他们将了解 BT 堆栈。

    [引用用户="Laurent CHENU87"]

    我之前提到我们在应用中使用的'HFRE_Send_Audio_Data ()'、此回拨确实会在成功/失败时返回不同的值(并且事件 etHFRE_Audio_transmit 缓冲区 empty_indication 仅在回调失败时发出)。 如果需要、我可以通过 HCI 提供低音扬声器的日志文件。

    [/报价]

    HFRE_Send_Audio_Data()不是回调,也没有任何需要回调函数指针的参数。 这与您之前提到的 HCI 层 API 不符。  

    此外,请参考我在上面的两项评论,因为它们也适用于本声明。

    BR、

    Vihang