在不同温度下测量物联网设备的CPU速度

我想测量不同温度下telosB的计算速度。要对设备进行编程，我使用contiki。 我的想法是让它以固定的时间间隔发送消息，并返回消息

时钟时间（无效）

作为内容。第二个设备读取该消息并将其与自己的时钟时间（void）返回值一起存储在文件中。我可以这样说：

在温度A下，一个设备需要500个时钟信号来发送100条消息，第二个设备需要600个时钟信号来接收100条消息

在温度B下，一个设备需要500个时钟信号来发送100条消息，第二个设备需要800个时钟信号来接收100条消息

这意味着，由于接收器必须等待更长的时间，设备在温度B下的速度确实较慢

我现在被卡住了，因为每次我执行我的解决方案时都会得到不同的结果+结果在链接质量不完美和一些包丢失的时刻被扭曲。

---

是否有一种解决方案（可能是使用不同的设置）可以帮助我证明这一想法？

您可以以固定的间隔发送消息（例如，在a的时间内每5毫秒发送一次），并为每条消息添加一个序列号。通过这种方式，您将知道每个接收到的消息相对于先前消息的预期时间，即使某些消息丢失

要测量CPU速度，实际上不需要测量接收和处理每条消息的时间。无论如何，这不是一个客观的衡量标准，因为通信中的很多时间实际上都花在实际接收上，而实际接收是从无线电时钟开始计时的，而不是从一个驱动CPU开始计时的

如果CPU速度确实是您想要测量的，那么不要使用

clock\u time（）

。您需要将msp430硬件计时器配置为源于DCO

另一个选择，如果你的想法太复杂，是比较DCO频率和低频晶体振荡器的频率。这不会给出最准确的结果，因为晶体也会受到温度的影响，但如果您想将CPU速度测量到%而不是ppm的精度，这就足够了。请参阅函数msp430\u sync\u dco（）执行此操作

我的假设是，时钟的频率在不同的温度下变化。我想以某种方式测量它

如果要测量时钟频率的偏差，请使用。这就是它的用途，它可以测量频率，精度远远高于微控制器

---

一般来说，大多数时钟源在设备的工作温度范围内应该足够稳定，运行时的差异应该可以忽略不计。如果你在极端的温度下运行你的设备，时钟速度甚至会漂移几个百分点，这可能会阻止收音机工作，因为它们的发送/接收频率也会漂移。

MSP430通常有一个自由运行的内部振荡器，您可以对其进行编程，以给出处理器时钟的近似工作频率。该校准在两个频率之间交替进行，以提供所需工作频率的近似值。看过telosB的电路图后，它有一个32kHz的晶体，可以用来提供更精确的时间源。我不熟悉您正在使用的操作系统或主板上的其他软件，但此32kHz振荡器可作为主处理器时钟的校准源，其中软件使用内部计时器计算实际主处理器时钟频率，并调整编程时钟频率，使其回到正常值期望频率。转到TI MSP培训资料中描述DCO操作和校准的页面。如果操作系统包括此功能，则工作频率随温度的漂移将取决于32kHz晶体特性和频率跟踪算法。这很可能不是单调的

还有发送消息的应用程序的软件结构。发送消息的决定是如何触发的。我通常使用的方法是有一个计时器，它使用水晶来生成一个事件，触发主循环软件以定义的周期发送消息。然后，主软件生成事件消息。假设事件之间有足够的处理器周期来生成消息，那么实际的时钟频率是不相关的

你说链接不完美，有些信息丢失了。在这两种情况下，您在500个刻度中发送100条消息。设备不能错过传输，因为它是发起者。接收数据时间的差异看起来可能是由于接收端丢失的消息数量造成的。您每5个操作系统周期发送一条消息，接收间隔可能类似，因此如果任何两条消息之间的时间间隔超过6个周期，您可以检测到丢失的消息

---

另一种想法；操作系统标记是如何生成的。如果它来自处理器时钟，则勾号持续时间将随处理器时钟而变化。如果它是由32kHz XL1振荡器产生的，则其周期将随晶体频率特性而变化。

这两种情况下的接收器似乎都无法跟上？解决方案是确认消息，使发送器不超过接收器？不是因为“接收器必须等待更长时间”而是发射机应该等待吗？也许我把我的问题表达错了。我的假设是，时钟的频率在不同的温度下变化。我想以某种方式测量它。第二个微尘的整个想法只是一种测量两个活动之间相对时间差的方法