• 状态 Resolved
  • 已锁定 已锁定
  • 回复 5 回复
  • 订户 0 订户
  • 视图 249 视图
  • 用户 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.

[参考译文] TM4C1294NCPDT：UARTPrintf 与 UARTCharPUT/获取

admin
Guru**** 2482105 points


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

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/715388/tm4c1294ncpdt-uartprintf-versus-uartcharput-get

器件型号：TM4C1294NCPDT

员工、

当 TivaWare 首次推出时、我们可以选择使用两个 UART 库。  也可以

C：\ti\TivaWare_C_Series-2.1.X\utils\uartstdio.c  (具有 UARTPrintf)或

C：\ti\TivaWare_C_Series-2.1.X\driverlib\UART.c (具有 UARTCharPut 和 Get 等)

UARTPrintf 的吸引力在于它具有软件 缓冲区、而 UARTCharPut 和 UARTCharGet 没有软件缓冲区。

 uartstdio.c (包含 UARTPrintf)的问题是，它只能通过硬编码与前3个 UART 端口一起工作，并且一次不能打开/缓冲多个 UART。  但 TM4C129X 有八个 UART。  要在 TM4C129X 上使用 UARTPrintf、需要修改库代码以添加更多端口、并为每个 UART 端口提供一个库副本(因为一次只能打开一个端口、并且缓冲也不可扩展)

  1. 在 UART.c 中排除缓冲 UART Tx 和 Rx 是有意还是疏忽 ？？
  2. 为什么不重新编写 uartstdio.c 来支持具有3个以上 UART 的 MCU？

UARTStdioConfig 从下面 的 uartstdio.c 复制 、显示它如何仅处理3个端口。 

空
UARTStdioConfig (uint32_t ui32PortNum、uint32_t ui32Baud、uint32_t ui32SrcClock)
｛
//
//检查参数。
//
assert ((ui32PortNum =0)||(ui32PortNum =1)||
(ui32PortNum==2))；

  • 0
    TI__Guru**** 2482105 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    尊敬的 Peter：
    uart.c 包含用于使用 UART 模块的驱动程序/API。 uartstdio.c 实际上是一款更高级的实用工具、可提供与终端连接的简单 UART 'console'函数。 我认为该实用程序的构建支持要在 EVM/LaunchPad 板上使用的各种 TivaWare 示例、其中 UART0/UART1主要用于与控制台进行通信。
  • 0
    TI__Guru**** 2482105 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    你(们)好，查尔斯 谢谢，这很有意义。 我错误地假设 uartstdio.c 是库组件、而是实用程序和示例。
    我的团队已修改并使用它与 TM4C129X MCU 配合使用。 主要缺点是每个 UART 需要一个新的 uartstdio.c 模块实例。 例如 uart0stdio.c、UART 1stststststdio.c 等

    考虑到 UARTPrintf 需要付出的大量努力、我认为如果 TI 重新编写 uartstdio.c 来处理多达8个 UART 并根据需要动态分配缓冲区、那将会是极好的。
  • 0
    TI__Guru**** 2482105 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您已经很好地：

    • 首先介绍并记录了现有 API 规定
    • 正确识别出"显著"弱点
    • 然后提出 了"供应商-何时/何时/是否可行"解决方案

    原谅-但我“不能屏住呼吸”。   (请注意"鼠疫病-病症"(双胞胎 R9/R10 -在'123 LPAD 中)的长期/持续存在-可预测地会使"许多人"-但仍然存在！)

    相反、将"最多8个 UART"包含在内的扩展证明了"没什么大不了的"-然后是主要问题-"多个"UART"缓冲器的动态分配/分配！"   您的团队更喜欢"通过"。

    现在-由于您的想法是如此的明智-难道不是、'更多的人才'-如果这样的'动态缓冲'-可以适应'超越 UARTs？'   

     "任何 MCU 外设操作"是否会 从您的"基本想法"中受益？   实际上、"困难的增加"已经提高、但也是如此、"吸引力-价值-和附加性能(甚至简化编码)-动态缓冲(巧妙而可靠地实施)预计将提供这种优势。

    优秀的想法不应"自定"限制"更"！    如本文所述-多个 MCU 外设的"接受/邀请"极大地提升了您的想法的吸引力和优势-从而"更好地点燃和点燃"-它加速了发射！

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

    [引用 USER="CB1_MOBIST"]出色的想法不应"自定义"限制！   正如此处所述、人们相信、"接受/邀请"多个 MCU 外设-显著推动了您的"巧妙"基本理念...[/QUERPLET]

    感谢 CB1！   我只是想了解一下，您是否建议 TI 针对所有外设实施此缓冲方案？！   如果现在只为 UART 提供服务、我将不胜感激。  我可以看到、TI 可能建议改用 DMA。   我还没有深入了解任何 DMA 实施、更喜欢用我的工作量极少的方式为我编写的内容！

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

    [报价用户="Peter John"]您是否建议 TI 针对所有外设实施此缓冲创意[/quot]

    否-我不相信(太多)会影响供应商的雷达。  (我的意见！)  注意-与您一样-公司/我是"外部人员"-尽管我们经常与多个供应商人员进行互动。   我不能回顾这一问题(以往任何时候)。

    Peter John 说：
    更喜欢为我编写的内容、但对我的部分只做了很少的工作

    只要这样、"已编写"就能体现出足够的质量、功能和广度、而"已编写"这种"标准就不会成为"首要"、那么我可能会同意。

    你提出了强大的"基本想法"-我只是试图通过(显而易见的)扩展来"拓展其吸引力"-以便"采用"的理由-更具吸引力(甚至)...