Do people test microcontroller peripherals using CppUTest?

[funbotix]

Thanks/Kudos to Mr. Grenning for his "Test Driven Development for Embedded C" book.  It has been a great help in learning how to write better, more testable code using CppUTest.  I've written a fair amount of tests using CppUTest, but they've pretty much been for things other than the drivers for the microcontroller itself.  For example, I have not done tests for I/O pin drivers, DMA controllers, I2C or SPI controllers, etc.  My main question is, do folks typically write CppUTest based tests for microcontroller peripherals like these, or do they "break the seam" at the peripheral and only test higher level code via those seams, or do they do something else for the type of code that makes the microcontroller itself work?  Can anyone provide links to online articles, or the names of books that contain information about strategies for testing microcontroller peripheral drivers using CppUTest?

[A. Robert S.]

A bit of a late answer ;-). I'll give it a shot, because I am wrestling with the same question.

 

I wrote quite a bit of code for the TI cc430, the sports watch, to be exact. I broke the seam *above* the drivers.

 

The TI drivers are horrible. They are full of interdependencies, plus some dependencies on applications (!). So I had to rewrite the ones I was going to use. I pulled out quite a bit of code into function libraries, because it was logical code and there was no reason why it should live in a driver. I unit tested that code with cpputest, and with very simple tests that I ran directly on the target.

 

However, the whole thing irks me. I wasted a lot of time debugging drivers. I have no real tests for them, either. And despite quite a bit of experience with unit testing in the embedded world, I still can't imagine how to test those drivers. I would like to know about any books or other sources of wisdom myself.

[James Grenning]

I just checked my sent mail and it seems I never responded to this question.

Breaking the seam above the drives has the best long term pay-off.  Because the code about the seam can be software.  The code below the seem is definitely firmware. (See this article about the difference http://www.renaissancesoftware.net/blog/archives/458)

The firmware can also take advantage of the first benefit of TDD, it helps get the code right in the first place.  In the book there is the FlashDriver example that uses the seam right above the device IORead() and IOWrite().  

In the FlashDriver example, we test drive right from the data sheet, using MockIO.  In the book I use a hand-crafted mock, though now I use CppUMock.

If your drivers evolve, or there is shared code between drives under the seam, they can enjoy the regression test benefit TDD creates.

Since the book I have seen a fair amount of legacy microcontroller and DSP code. I've written several articles that show some of the things I've run into in legacy firmware.

Search for the articles on my blog about

- embedded

- non-standard keywords

- include test double

- embedded asm

These articles show how to get arounds 'special extensions' to C and other non-portable code.  Ideally if you are test driving from the start, you limit when you use the non-portable constructs to a small area of your code.

In the end, its all just C.  If you know how to fake an application interface, you should be able to fake access to IO operations.

You can also write some tests that interact with your real hardware.  But this kind of depends on your hardware.  For example, you can write tests that use your FlashDriver in the HW.  You could write tests for a UART that you add a loopback connector to.  You could consider doing a partially automated tests that runs the LEDs through a cycle for a few seconds that you can recognize.

I have been getting some reports for people that I have trained, and that made TDD work for them, that they are finding their code works in the hardware the first time or with very few changes.  One person reported a new first, getting done early because of only a few integration problems.  The problems were quickly discovered and repaired because they knew (through TDD) what their code was doing and they had the TDD safety net.

Thanks for the kudos on the book.  Sorry I did not notice the original question.

James

Sent from my iPad

--
You received this message because you are subscribed to the Google Groups "cpputest" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cpputest+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.