嵌入式C的TDD：如何设计LED驱动器的测试？

Question

我是TDD的新手，并遵循“嵌入式C版本3的测试驱动开发”。

找到作者提出的一个非常有趣的问题。它位于“入门”->“测试完成方式”->“将知识投入工作，P103：

3. 我们的硬件工程师通知我们，她可以节省$ 0.12 /板如果LED使用反向逻辑。修改LedDriver及其测试使用反向逻辑。如何改善我们的测试或设计，以便大多数测试不关心逆逻辑吗？
4. 我们公司刚刚完成了董事会版本的倒置LED逻辑。我们发现某些旧版本仍在在该领域。 LedDriver及其测试应如何修改为支持两个版本的硬件？条件编译为不是正确答案的一部分。我们需要一个二进制文件。
5. [生产板的丝网印刷是错误的！ LED 1标记为16，Led 2是15，依此类推。您如何修改测试和代码以使用真正的硬件？

在这些情况下，是否可以遵循最佳实践来修改生产代码或测试脚本？

B.R。

Answer 1

通常，这听起来像是程序员的任务，而不是测试人员的任务。

如果写入具有高电平有效逻辑的端口，则将使用PORT |= MASK;，否则使用PORT &= ~MASK;。这里的主要问题是我们需要根据极性使用不同的运算符，因此幼稚的解决方案将是：

if(active_high)
  PORT |= MASK;
else
  PORT &= ~MASK;

虽然会产生开销代码。最好的解决方案是，如果我们可以在编译时生成MASK，并且始终使代码执行PORT = MASK;，而又不破坏任何其他不相关的端口引脚。反过来，这意味着需要尽早在硬件引脚布线期间就考虑到这一点！

假设PORT = MASK;解决方案是可能的，那么您可能会做类似的事情：

#define LED2 (1u << 2)  // active high
#define LED1 (0u << 1)  // active low
#define LED0 (1u << 0)  // active high

#define MASK (LED0 | LED1 | LED2)

或者如果您愿意：#define POLARITY 1 ...#define LED2 (POLARITY << 2)...

---

话虽这么说，工程学中最重要的技能之一就是批判性批判性思维/怀疑主义和超越常规的思维。

因此，如果硬件工程师说他们可以节省0.12美元/板，而您的公司生产了数百万个板，请竖起大拇指。如果您每年售出数百台左右的产品，而修复将需要您花费几天的时间，那么也许会让他们迷路，因为程序员修复它的薪水比一生中“节省”的任何钱都要高很多倍。该产品。

类似地，“条件编译不是正确答案的一部分。我们需要一个二进制”是一个过早的要求。如果您在原型板上拧紧丝网，最好的解决方案是为该拧紧的板上提供一个二进制文件，直到推出下一个PCB版本，然后在该时间点永久更改固件为止。这些事情通常应该由version control处理，而不是由条件编译处理。为已拧紧的板子另建一个分支，已解决问题。

[如果不可能，那么...在设计电路板时，还可以做一些技巧，例如牺牲4个GPIO引脚，将它们设置为输入并将每个引脚绑定到Vdd或GND，以形成二进制数。 MCU可以读取引脚以告知板子的硬件版本，并且还有16个版本的空间。然后，您可以拥有一个支持每个单一版本的二进制文件。

始终询问要求！