views:

691

answers:

4

This follows a couple of other questions (but I think I have refined my question better).

I want to test out my firmware code before I put on the device.

I realize that a lot of people write their code, upload, test, etc. But I really want to write and test before upload (mainly because I want to automate the many scenarios).

So, what is the best way of doing this. If I were writing pure software, as in, no firmware at all, I would go about it by using cppunit (for example). But I'm a little lost with this firmware thing.

Any ideas?

Thanks

+2  A: 

Well it is hard to say without knowing how your code is architected, but basically you could test the software at the class/function level just like other software. Any code that interfaces with the device would most likely need to be tested via emmulation.

EBGreen
So, maybe your code would be written in C, thoroughly tested, then compiled into hex and uploaded? Is that what you or the industry would do?
cbrulak
I think what EBGreen is suggesting is that you use something like cppunit to test your C on your development machine (probably with some mock objects for the stuff that touches hardware), then when those pass, recompile for your embedded target, upload, and smoke test with the actual hardware.
rmeador
A much better way to put it. Although from your other question and your comment here I suspect the you are writing in assembly. In that case I don't know of any unit test harness for asm.
EBGreen
But, it really doesn't matter if you write it in assembly or C right? Because when you compile for the device, it's going to end up in hex or some other binary form. So, does it matter if it is C or assembly?
cbrulak
Well, if it is C then there are unit testing harnesses available. Like I say I don't know of any for assembly (doesn't mean that there aren't any).
EBGreen
I mean, is there more value to do it assembly versus C ? See http://stackoverflow.com/questions/452139/writing-firmware-assembly-or-high-level
cbrulak
+2  A: 

Many embedded devices have software simulators available, but it does depend on the device.

Jim C
+2  A: 

I don't think the answer marked as "correct" is at all correct or complete.

For firmware code, you really MUST conduct a two-pronged test to be rigorous.

  1. Initial tests done using an emulator. This is ideal but presumes you can get a good emulator for the target platform.

  2. Test on the actual hardware, but in a test bed framework. That is, you test on the actual device, but with additional hardware (i.e. oscilloscope, probes) and other connections to allow proper trace/debug on what's happening.

With firmware, often the most difficult bugs are timing related, and only show up once you are on the actual hardware. In the worst cases, the actual act of probing can alter timings such that the bugs won't appear - only in the "production" version. Then you have real fun.

Cheers,

-Richard

Huntrods
A: 

You should unit test your classes as much as you can, but at the end of the day, you must run it and test it in the hardware.

To test your firmware in a device write a debugging interface so that you can use a terminal emulator like procomm to talk to your device. Then, when you are writing a feature, have a way for your debugging interface to call methods in your class, that way you can specifically test your code in the device itself.

Once you have that done, you can write scripts in your terminal emulator to do the tests automatically.