[参考译文] AM3358：AM3358上的 UART 传输出现问题/不一致、可能是由编译器导致的？

Michael、您好！

感谢您的查询。

由于某种原因、可能是为我分配的 TT 所对应的 AM3358器件型号所致。

我正在检查谁可以支持该线程重新分配。

在寻找合适的专家时、请预计会有一些延迟。

此致、

斯里尼瓦萨

Michael、您好！

我将重新分配给编译器团队以提供支持。

此致、

斯里尼瓦萨

好的、我正在等待反馈！

您好！

Unknown 说：

-编译器版本是否真的要对此行为负责?

-如果是,编译器 v20中的什么变化可能会修复这个问题?

[/报价]

很难判断这是否与编译器有关。 如果可以将两个编译器之间的差异缩小到一些代码段、则可以比较编译器生成的输出、并判断编译器是否有所不同。

此致、

建中市

好的、但重点是：完全不清楚到底是什么导致了这种行为、因此几乎不可能在编译器输出中找到导致这种行为的确切位置。 一般而言、该行为似乎是其他东西的一些副作用、因此在最坏的情况下、比较 UART 相关代码毫无帮助。

如上所述、我不确定编译器是否是真正的原因、这就是我 在此要求进行验证的原因。

可以将项目拆分为两个库、一个使用 18LTS、另一个使用 v20LTS。 使用虚拟文件启动18LTS 库、然后逐个将文件添加到此库、直到出现问题。 这样，至少您可以找出有问题的文件。

不幸的是、这是不可能的、因为整个软件都太复杂且彼此连接。 另一点是：问题_is_已经是其他东西的副作用。 因此、当发生这种情况时、只有在使用了其他(不明显相关)函数时才会发生。

所以我们在这里有点绝望，关于一个可能原因的每一个提示、想法和粗略猜测都是欢迎的。

您好！

如果不知道问题的来源、我们在此无法为您提供帮助。 我建议指出问题的根源、而不是猜测可能的解决方案。  

此致、

建中市

好的,然后让我重复这个问题:它是不可重现的。 它发生在其他无法识别的事物的副作用,因为它似乎与串行接口无关。 问题本身是一个(理论上)根本不可能发生的问题、因为它完全由硬件控制。

那么、我们究竟该如何确定这一点呢？ 当有一个简单的方法来识别问题时、我不会在这里提出这个问题！

您好！

抱歉、我们无法为您提供调试帮助。 实际上、正如 此处所宣布的、我们已停止为 AM335x 器件支持裸机软件开发。

此致、

建中市

好的；但这也不是我的问题！ 我不需要裸机开发方面的一些帮助、这不是我所要求的！ 您能不能这么客气并阅读原来的问题？

您好！

很抱歉耽误你的时间。 我知道您原来的问题是关于编译器。  

Unknown 说：

-编译器版本是否真的要对此行为负责?

-如果是,编译器 v20中的什么变化可能会修复这个问题?

[/报价]

如前所述、我们无法 根据您提供的信息来判断较新编译器可以产生哪些差异。

此致、

建中市