Unit testing embedded C for a TI MSP430. Unit tests are to run on a Linux host compiled with GCC. The project is rather big and primarily legacy code.
There are reads and writes to registers such as PCIN_L, PCOUT_L, and PCDIR_L among others that when compiled will generate errors saying they are undeclared. This is true because when running on the host no such registers exist.
Earlier I learned to intercept calls to functions (symbols) that would not be available and redirect thos calls to fake functions, only returning a predefined value. This I did using the linker option -Wl --wrap,someSymbol
.
Makefile:
LDFLAGS=-Wl --wrap,AbsentFunction
SOURCES=WrappedFunctions.c
WrappedFunctions.c:
int __wrap_AbsentFunction(int val_a)
{
return val_a;
}
This would redirect any calls to AbsentFunction
to __wrap_AbsentFunction
.
I did however try this on my registers as well withou any luck.
Makefile:
LDFLAGS=-Wl --wrap,PCDIR_L
SOURCES=WrappedSymbols.c
WrappedSymbols.c:
char __wrap_PCDIR_L;
Is it possible to something similar to the registers as I did to the functions? I prefer not introducing changes into the projects code.
You could simply declare memory mapped processor peripheral registers as volatile data by creating a "fake" processor header containing declarations such as:
extern volatile uint16_t PCDIR_L ;
They will not of course behave like peripheral registers but it will allow the code to be built.
A better approach is to have built a hardware abstraction layer so that peripheral access is via an function API rather than direct to the hardware, then you can create a "fake" API that emulates the hardware behaviour.