微控制器C代码的单元测试模式 [英] Unit testing patterns for microcontroller C code

问题描述

虽然有很多支持C的单元测试框架，但我对如何编写微控制器代码的单元测试有一点困惑（在我的情况下，我认为这个问题比较普遍） / p>

为微控制器编写的大部分代码围绕着将配置和数据值写入寄存器，从寄存器读取传入数据并响应中断事件。我想知道是否有人可以提供一些最有效的方法来指导这一点。

解决方案

你写;

微控制器围绕将配置和数据值写入寄存器，从寄存器读取传入数据并响应中断事件。

我同意，这在实践中经常出现，但我实际上并不认为这是一件好事，我认为重新考虑一些事情会帮助你实现测试目标。

也许是因为微控制器程序员可以随时随地触及硬件，许多（大多数）他们已经习惯于在他们的代码中做到这一点。通常这种习惯是毫无疑问的，也许是因为这么多人做这样的工作是电脑科学家不是计算机科学家的训练和倾向。我知道，我自己开始了。

我想要做的一点是，微控制器项目可以和应该像任何其他软件项目一样精心设计。良好设计的一个非常重要的部分是限制硬件访问硬件驱动程序！分离所有写入寄存器的代码，将中断等响应到模块中，从而为您的软件提供对硬件的良好，干净，抽象的访问。使用逻辑分析仪，示波器，定制测试台或其他任何有用的东西来测试目标上的驱动程序模块。

一个非常重要的一点是，现在剩下的软件，希望绝大多数，现在只是C代码，您可以在主机系统上运行和测试。在主机系统上，硬件模块被隐藏，以提供对被测代码正在做什么的可见性。您可以在此代码上使用主流单元测试方法。这需要一些准备和工作，但如果组织良好，您可以创建一个可应用于所有项目的可重用系统。潜在的好处是巨大的。我在这里写了更多关于这些想法的信息：

[ http://discuss.joelonsoftware.com/default.asp?joel.3.530964.12] [1]

Although there are plenty of unit test frameworks that support C, I'm a little stumped on how to write unit tests for micro controller code (PIC in my case, but I think the question is more general than that).

Much of the code written for micro controllers revolves around Writing configuration and data values to registers, reading incoming data from registers and responding to interrupt events. I'm wondering if anyone can provide some pointers on the most effective way to this.

解决方案

You write;

"Much of the code written for micro controllers revolves around Writing configuration and data values to registers, reading incoming data from registers and responding to interrupt events".

I agree that this is often the case in practice, but I don't actually think this is a good thing, and I think rethinking things a little will help you with your test goals.

Perhaps because microcontroller programmers can reach out and touch the hardware any time they like, many (most?) of them have got into the habit of doing just that, throughout their code. Often this habit is followed unquestioningly, maybe because so many people doing this sort of work are EEs not computer scientists by training and inclination. I know, I started out that way myself.

The point I am trying to make, is that microcontroller projects can and should be well designed like any other software project. A really important part of good design is to restrict the hardware access to hardware drivers! Partition off all the code that writes registers, responds to interrupts etc. into modules that provide the rest of your software with nice, clean, abstracted access to the hardware. Test those driver modules on the target using logic analyzers, oscilloscopes, custom test rigs or whatever else makes sense.

A really important point is that now the rest of your software, hopefully the great majority of it, is now just C code that you can run and test on a host system. On the host system the hardware modules are stubbed out in a way that provides visibility into what the code under test is doing. You can use mainstream unit testing approaches on this code. This needs some preparations and work, but if you are well organized you can create a reusable system that can apply to all your projects. The potential benefits are enormous. I wrote a little more about these ideas here;

[http://discuss.joelonsoftware.com/default.asp?joel.3.530964.12][1]

这篇关于微控制器C代码的单元测试模式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！