Modularize your code in such a way that there is a thin layer in the bottom which knows about the details of the underlying hardware. That layer can then be mocked on a normal PC. That way you can use normal unit test libraries for desktop development to test all code except that thin bottom layer.
My experience on developing embedded software for Linux is using C++ and not plain C. We used cppunit for unit tests.
Edit: there is a list of project using Check as unit test framework on the check project page. Some links are outdated, but you can browse the source of the unit test of pigment and SCEW ; one has to download the source for others.
minunit has no dependencies at all and can be used as a base to build your own framework.
As far as an approach is concerned, I start from the lowest level functions (the leaves). Very often, when I'm testing the higher level function they invoke the lower level functions. This is not a problem as the lower functions have already been tested.
I also modularize the code as "object", or table of objects. Stub functions allow testing in isolation of the hardware or of other components.
I get rid of the static with a define that remove them, or I include the source file containing the functions to be tested into the unit tests source file.
#if defined(UNIT_TESTING)
#define STATIC
#else
#define STATIC static
#endif
No rocket science here but this does the trick.
One last thing, test the behavior, not the implementation so that the unit tests won't break when the implementation changes.