• 状态 Resolved
  • 已锁定 已锁定
  • 回复 4 回复
  • 订户 0 订户
  • 视图 258 视图
  • 用户 0 会员在此处
选项
选项
相关

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.

[参考译文] TM4C129XKCZAD：USBHCPDPIPEStatus()未实现。

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

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/679377/tm4c129xkczad-usbhcdpipestatus-is-unimplemented

器件型号：TM4C129XKCZAD

usbhostenum.c 中的 USBHCPepeStatus()无用： 

uint32_t
USBHCPepeStatus (uint32_t ui32Pipe)
｛
返回(0)；
}

我需要这样做、以便能够检测并从我看到的写入传输故障中恢复。  这些文档甚至引用了一个值 USBHCD_PIPLE_NO_CHANGE、该值在 USBLIB 的任何位置都未定义。

 

  • 0
    TI__Guru**** 2382170 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    R Sexton、您好！

    遗憾的是，没有计划将该功能纳入参考文献。 就个人而言、我认为 API 甚至不应该发布到"假设"此类功能在未来会存在、更不用说表示在 usblib 中不存在的变量-但在上次发布时、我不是团队的一员...
  • 0
    TI__Guru**** 2382170 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    如何检查传输故障？
  • 0
    TI__Guru**** 2382170 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    usbhostenum.c 中的 USBHCSDPipeStatus ()无用：

    我所有 的“纪律力量”  都不想说， “理查德——你真的感觉如何？”

    然而-拉尔夫到达-他确认了你的感受。

    这个主题领域在我的脑海中—但我的"照片"回忆起一位客户 (至少一位采用"USB 管道"的人)、我们 "接到了电话"。

    现在-这一客户(过去)案例让我感兴趣的是-他们回顾了(其他)：

    • 配备 USB 的 ARM MCU
    • 和"常见可疑"UART <-> USB 芯片

    "已执行-在其特定的"意图区域"中。  我记得，他们能够"讲出来"充分理解(复制)他们的努力确实取得了成功。

    你(看来)在这里"死了"--我认为这可能会提供 一个"终审法院"。   (可能)

    我可以报告、我们使用多家供应商提供的许多 ARM MCU 通常会暴露"优势技术"、同样、这些" 不太..."   有时-"吹入风"(45°-精确)使您能够达到目标-即使是在-尤其是当-这似乎令人怀疑的情况下-也是如此...

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

    您好、Robert、

    [报价用户="R Sexton"]如何检查传输失败？

    根据我在代码方面所做的回顾、在 usbhostenum.c 文件中、实现方案需要与此 API 一同执行： 

    //
//
//！ 此函数返回 LPM 请求的当前状态。
//！
//！ param psDevice 是要查询的设备。
//！
//！ 此函数返回给定
//！的 LPM 请求的当前状态 器件。 调用此函数可确定先前的请求是否已完成
//！ 或者是否存在错误。
//！
//！ 返回此函数返回以下值：
//！ -\b USBHCD_LPM_AVAIL -此特定的无挂起的 LPM 请求
//！ 设备或最后一个请求成功完成。
//！ -\b USBHCD_LPM_ERROR -此器件的最后一个 LPM 请求未
//！ 成功完成。
//！ -\b USBHCD_LPM_PENDING -最后一个 LPM 请求尚未完成。
////
*****************
uint32_t
USBHCCDLPMStatus (tUSBHostDevice * psDevice)
｛
uint32_t ui32Ret；

assert (psDevice！= 0)；

//
//不应同时具有 USBHDEV_FLAG_LPMERROR 和 USBHDEV_FLAG_LPMPEND
//同时设置。
//
assert((psDevice->ui32Flags &
(USBHDEV_FLAG_LPMERROR | USBHDEV_FLAG_LPMPEND))！=
(USBHDEV_FLAG_LPMERROR | USBHDEV_FLAG_LPMPEND)；

//
//默认为无待处理的传输或错误。
//
ui32Ret = USBHCD_LPM_AVAIL；

if (psDevice->ui32Flags & USBHDEV_FLAG_LPMERROR)
｛
//
//在发送 LPM 命令的最后一次调用后发生错误。
//
ui32Ret = USBHCD_LPM_ERROR；
｝
否则、如果(psDevice->ui32Flags & USBHDEV_FLAG_LPMPEND)
｛
//
//仍有待处理的传输。
//
ui32Ret = USBHCD_LPM_PENDING；
｝

return (ui32Ret)；
｝

    使用的标志是用户定义的、放置在文件的顶部、 ui32Flags 变量被添加到 tUSBHostDevice 结构中(这可能更难拉取、因为它在7个文件中使用、所以如果你觉得它足够干净、你可以选择一个不与结构相关联的全局变量)。

    更困难的部分是集成新标志是 USBHostIntHandlerInternal 的一部分、在该部分中、您可以指定哪些事件会导致设置哪些标志、然后当然将标志检查添加到相关函数中以获得所需的行为。

    不幸的是、无论我以何种方式看待它、我都看不到一种快速/简单的实施方法-尽管我总是有机会看到一种更简单的方法、而我只是没有知识水平可以查看。