一般问题：向嵌入式系统添加新的测试代码答案

【问题标题】：General question: Adding new test code to embedded system一般问题：向嵌入式系统添加新的测试代码
【发布时间】：2011-04-25 16:59:08
【问题描述】：

这可能会跑题，但我正在实时准备考试。我一直在浏览这本书和互联网以寻找问题的答案。

基本上我想知道是否通过添加额外的测试代码可能会改变嵌入式系统的实时行为，或者是否会引入新的错误。

有谁可能知道这个问题的答案，或者请我参考一些阅读材料？

【问题讨论】：

“测试代码”是什么意思。验证系统本身功能的代码？有点什么 ASSERTS 做什么？还是只是调试输出？

标签： testing embedded real-time

【解决方案1】：

你的问题太笼统了..所以我想默认答案取决于..但是考虑到可能性作为逻辑和思想的练习，是的，它肯定可以！

有许多方案可用于保证嵌入式系统的“实时性”。例如，可以有一个基于 ISR 的抢先定时器来为实时任务提供服务。在这种情况下，您的测试代码可能不会影响“实时性”。但是如果测试时间过长，而且上下文切换不是先发制人的，你可能会遇到麻烦..

但这又取决于您要测试的内容以及测试的方式。您的测试代码可能会弄乱定时器、中断或系统内存。如果你不小心的话，搞砸的可能性是无穷无尽的。

在下面有一个操作系统可以防止一些错误，但同样取决于它的工作方式，您可能会从错误的“测试代码”中解脱出来..

【讨论】：

我有点想读。从现在开始。我认为测试是关于 ASSERTS 和类似的。因此，我看不出它会扰乱实时行为的原因。由于附加测试代码仅用于 ASSERTS。但我可能记错了，因为我记得在一次讲座中教授说它会影响实时行为
Hmm.. 实际上，当您尝试编译“部署”代码时，大多数现代 IDE（编译器）都会编译出 Assert 代码。但同样，我们应该坚持逻辑练习。 .我确实遇到过非常“海森堡式”的案例。调试或“观察”代码本身的行为会导致错误。这些是测试代码实际上弄乱了功能的案例。
对于实时系统，如果计时不是由某种独立的计时器控制，而是由执行一定数量的代码所花费的时间（baaad设计，但确实存在），添加代码（即使它是断言或调试）肯定会搞砸时间，从而保证系统的实时性。我已经看到这种情况发生在调试代码中，它将东西发送到串行端口。串行驱动程序正在使用这么长的时间，“快速调试”并没有那么快，并且弄乱了实时基带操作系统的时间......
Hisenberg-esque 试图在 google 上搜索它在维基百科中找到了什么，但它被称为 uncertainty principle。无论如何，我可以说添加新代码会产生与更改调度程序相同的效果，例如如果我有一个循环计划并且我正在添加一个新任务？
是的。我的意思是说它类似于应用于编程的不确定原则。“观察代码本身的行为会改变代码的工作”。关于调度程序，是的，这可能是一种看待它的方式。但再次取决于使用什么方案来保证“实时性”。您还可以通过增加其中一项任务所花费的时间而不是需要添加另一项任务来搞砸“实时性”。.

【解决方案2】：

是的，当您添加代码（测试、诊断、统计）时，它可能会改变实时行为。它是否真的会改变行为取决于设计、实现和 CPU 能力。您还有更多的代码行，出错的可能性可能会增加。但我不会说“它会引入错误”，因为它可以引入错误。

【讨论】：

额外的代码行会如何导致行为发生变化？我猜代码是在安装到嵌入式系统之前编译成字节码的。

【解决方案3】：

是的，它可以。请参阅How can adding data to a segment in flash memory screw up a program's timing? 以了解即使添加不可执行的代码如何调整时间足以搞砸系统的示例。

【讨论】：

【解决方案4】：

是的，更改您的代码库可能会完全改变它的时机。考虑一下，如果您将一些调试输出转储到串行端口，调用该函数、格式化数据需要时间，如果该函数是同步的，则等待数据输出。这种东西肯定会改变系统时序行为。

【讨论】：