Unit testing of firmware?

[object01]

I've been wondering recently about ways that I could unit test all the code I'm writing for these PICs, but seeing as how so much of the code depends on input from a host computer, or a cellular modem, or whatever, I'm finding it difficult to come up with a way to create a suite of clean, reusable, and easily runnable unit tests.

Does anyone out there have any suggestions?

--
Jeff S.

[Trampas]

Personally I have found the only good way to test code is with an emulator.

That is I find it is often best to test the logic of the software by writting the software for a PC first. Then write a test system. The tools for a PC are much better at measuring code coverage and such. Not to mention debugging software on a PC is a breeze compared to on an embedded device. I usually after writting a function like to run software and step through each line in function. It is amazing how many bugs this will catch.

Then the drivers need to be tested on your PCB. This requires lots of work as their is no easy way to simulate timing problems or PCB noise. Usually this involves lots of feild testing.

Once you have the drivers and the logic working, you need a way to do factory testing. Usually for my products I design a test fixture which tries to exersize the hardware and physical devices.

However before you get going, implement a bug tracking system, it will save you some time.

Finally if at all possible make a firmware update option, this way when (not if) a bug is found you can have customers upload new firmware. Additionally see if you can automate any testing and have your version control and bug tracking system intergrated, such that each and every night code is check out from version control, compiled and tested. Then have the tested add bugs to database, and email you. This way when code breaks the code is only a day old.

Trampas