[参考译文] LMK61E2：I2C 影子寄存器。

您好、  

据我所知 、LMK61E2 不使用影子寄存器来处理分布在多个寄存器地址之间的字段。 我 预计这不会成为 XO_CAPCTRL 的主要风险、因为位 1：0 存储在 R16 中、9：2 存储在 R17 中、因此 XO CAP 代码中不应该 从寄存器写入 R16 和 R17 之间的延迟发生重大跳跃。 能否分享一些有关您的用例的更多详细信息？ 我们还有一份应用手册、介绍了如何计算 XO 电容代码对频率的影响： https://www.ti.com/lit/an/snaa283/snaa283.pdf 

此致、  

Connor  

。 我 预计这不会成为 XO_CAPCTRL 的主要风险、因为位 1：0 存储在 R16 中、9：2 存储在 R17 中、因此 XO CAP 代码中不应该 从寄存器写入 R16 和 R17 之间的延迟发生重大跳跃。 [/报价]

我希望他们是巨大的,出于同样的原因。

我的项目必须与外部、精确和已知的 CLK 同步。

因此、我将 NDIV、NUM 和 DEN 设置为已知值、并仅通过更改 XO_CAPCTRL 来同步它。

I2C 帧仅发送 XO_CAPCTRL 值、因此它们包含 4 个字节 (I2C 地址、I2C 寄存器地址、XO_CAPCTRL LSB 和 MSB)。

帧以几 k/秒的重复率发送、因此即使在 400kHz 的 SCL 频率下、下一帧也会紧跟前一帧之后。

因此、XO_CAPCTRL LSB 和 MSB 写入之间的距离很显著。

我发送相对较小的 XO_CAPCTRL 变化 (1...5)、因此边界上的干扰 (256) 可能很大。 但我还没有对此进行测试。

我可能会有所误解、但我的假设是、由于 2 个 LSB 位存储在 R16 中、大多数情况下 XO_CAPCTRL 错误可能会偏离 3。 例如、要将代码设置为 255、您需要将 0x3 写入 R16[1：0]、然后将 0x3F 写入 R17。 然后、如果将值更新为 256、则将 0x0 写入 R16[1：0]、这会暂时将 XO_CAPCTRL 设置为 252。 在下一个 I2C 事务中、256 将被写入 R17。 因此、在本例中、XO_CAPTRL 从 255 -> 252 -> 256 变大。  

如果您尝试锁定到已知的时钟频率、那么在您的应用中直接将时钟用作基于 PLL 的时钟发生器的输入是否有意义？  

此致、  

Connor  

抱歉、我的错。 我忽略了在 R16 中只有 2 个 LSB、在 R17 中有 8 个 MSB。 因此、每 4 个值都会出现一次干扰、但它们的振幅会很小（不是 256、而只是 4 个）。

如果您尝试锁定到已知的时钟频率、直接将时钟用作您应用中基于 PLL 的时钟发生器的输入是否有意义？  [/报价]

可能是的、但我找不到任何具有如此低抖动的 PLL、例如 LMK6xxx 系列。

不用担心、请告诉我、让 LMK61E2 在系统中运行时是否遇到任何问题。  

我们还有一些 PLL 时钟发生器、其抖动性能与 LMK61E2 类似。 您可以看看 LMK03318、当 PLL 在整数模式下运行时、它的 156.25MHz 输出抖动最大约为 150fs。  您需要锁定/生成哪种频率输出、您的抖动要求是什么？ 可能还有其他更合适的器件。  

此致、  

Connor