[参考译文] TM4C129ENCPDT：需要澄清、UNCHEID0至 UNCHEID3寄存器

[引用用户="12ve12PM"] 有关 TM4C129ENCPDT 器件的唯一 ID 寄存器(UNIQUEID0至 UNIQUEID3)的一些问题[/QUERT]

这些问题之前已经出现。 搜索可能会找到。 但是、您的问题的答案基本上是：它完全符合文档记录、不多不少。

[引用 user="12ve12PM"]它们是按顺序排列的[/引用]

否

[引用 user="12ve12pm"]如果不按顺序排列，我们是否可以预期不同器件的所有四个字之间存在差异？

如果您的意思是所有四个字都保证要更改。 不符合文档要求。

TI 唯一愿意提供的性能保证是数字是唯一的。

请注意、非随机和故意模式不同。

[引用 user="12ve12pm]]出现此问题的原因是软件需要为以太网通信提供唯一的 MAC 地址。 在示例程序中、这些数字存储在 USER0和 User1中。 如果任一寄存器未编程(包含0xffffffff)、则示例程序会进入 while (1)陷阱。 出于生产目的、我们希望恢复一些更强大的功能。 一种方法是抓取唯一 ID[/引用]的六个字节

作为终端用户、我会认为这一点不太可靠。 我希望设备彻底故障、而不是可能损坏网络

Robert

[引用用户="Robert Adsett"]

如果您的意思是所有四个字都保证要更改。 不符合文档要求。

TI 唯一愿意提供的性能保证是数字是唯一的。

请注意、非随机和故意模式不同。

12时12分

这个问题的原因是软件需要为以太网通信提供一个唯一的 MAC 地址。 在示例程序中、这些数字存储在 USER0和 User1中。 如果任一寄存器未编程(包含0xffffffff)、则示例程序会进入 while (1)陷阱。 出于生产目的、我们希望恢复一些更强大的功能。 一种方法是抓取唯一 ID 的六个字节

Robert

[/报价]

感谢你的答复。

在我们的应用中、如果没有网络连接、就无法知道发生了什么错误。 一般来说、设备具有自己的内部网络和路由器等 用户界面是该网络上的一个设备。 即使要打印错误消息，我们也需要网络连接来确定错误是什么。 因此、在本例中、不能选择简单失败。 如果 USER0、User1发生问题、我们"只需"确保它具有 MAC 地址。 我认为最好的解决方案是较长的128位唯一 ID 的某种48位哈希。 是的、对于所有哈希函数、都存在冲突、但如果我们选择了一个良好的哈希算法、并且如果我们确保将愚蠢的事情发送给 USER0、则用户1已正确编程、这样他们就不会首先回到这个代码上、 然后、设备网络中 MAC 地址冲突的可能性应极低。

[引用 user="12ve12pm"]在我们的应用程序中，如果没有网络连接，就无法知道出现了什么问题。

没有 LED？ 通常，您需要一种在通信失败时发出信令的方法。

[引用用户="12ve12pm]]通常，设备有自己的内部网络和路由器等 用户界面是此网络上的一个设备

我使用的网络类型、尽管我们通常转向 CAN 来控制网络。 不过、我们仍然有 LED。

[引用 user="12ve12pm"]即使要打印错误消息，我们也需要网络连接来确定错误是什么。

器件不能进行通信是否不是很明显地表明存在问题？

\n 因此、在这种情况下、仅仅失败不是一个选项。 如果 USER0、User1发生问题、我们"只需"确保它具有 MAC 地址。

警惕此类需求。 我希望以太网接口故障的可能性比 MAC 寄存器被覆盖的可能性更高。 您正在修补一种不太可能出现的故障模式，但修复方法不太可能导致整个网络出现故障。

[引用 user="12ve12pm"]我认为最好的解决方案是较长的128位唯一 ID 的某种48位哈希。

更好的做法是、由于您在路由器后面、应从 MAC 的保留专用集或从保留 MAC 的子集中进行选择。 我不喜欢这两种解决方案的稳健性。

[引用 user="12ve12pm"]是的，所有散列函数都存在冲突，[/引用]

问题不是哈希冲突本身，问题是与现有 MAC 分配的冲突。 如果您对该风险满意、只需从前面提到的其中一个池中挑选一个、这仍然是一个小风险。

[引用 user="12ve12pm">但是如果我们选择了一个良好的哈希算法， ... 然后、设备网络中遇到 MAC 地址冲突的可能性应极低。

我希望哈希的性质对概率影响很小。

Robert

[引用用户="Charles Tsaaaa">您好、
很抱歉、您和 Robert 之间进行了良好的谈话。 如果您试图为 MAC 地址获取六个字节的唯一 ID、我不太清楚。 请注意、MAC 地址必须来自分配给组织/公司的 MAC 地址池、不能是您需要的任何随机数。

[/报价]

MAC 地址有一个 U/L 位、用于将其标识为"通用管理"或"本地管理"。 以生成本地管理的 MAC 地址、按位或 MAC 地址为02-00-00-00-00-00-00-00。

[引用用户="Charles Tsaaaa">您好、
如果需要区分分组地址(广播或多播)与单个地址(单播)、则 MAC 地址的第一个八位位组的 LSB 会怎样？

[/报价]

好的地方。 我们必须按位并使用01-00-00-00-00-00。

我想网络堆栈应该自动处理该位、具体取决于是发送单播还是多播数据包、但嵌入式系统中使用的最小网络堆栈很可能不提供所有功能。

[引用用户="Robert Adsett72"]

12时12分

因此、在本例中、不能选择简单失败。 如果 USER0、User1发生问题、我们"只需"确保它具有 MAC 地址。

[/报价]

你是对的。 这是一种不太可能出现的故障模式。 但是、当事情因为没有好的理由而静默失败时、我不喜欢它。 我的一只宠物狗在周一进来、周五完美工作的东西突然不会"毫无理由"加电。 如果有问题、我希望系统在它放弃之前进行真正的尝试、如果只有这样、它才能清楚地报告它的问题。

[引用用户="12ve12pm ">]我的一只宠物狗在周一进来、周五完美工作的东西突然不会"毫无理由"加电。 如果有问题、我希望系统在放弃之前尝试一下、如果只是为了让系统能够清楚地报告问题所在。[/引述]

我知道。 但您已经可以很好地指示故障。 电路板无法通信、您的通信中心/HMI 肯定知道这一点？ 如果它不知道、为什么不知道呢？

作为交换、用"我失败"消息替换"不沟通"消息的交换、您会增加开发工作量、并增加产生进一步问题的风险。 请注意、这种局部恢复方法仅适用于通信损耗的一部分、而不太可能的部分。

Robert