As you develop your software, you will add stubs to AppIF.c. These stubs will mimic drivers for things like PWM I/O , EEPROM, and CAN. The goal is to provide a virtual device driver layer so that the application layer can execute.
In general we have stubs associated with all the input and outputs of the system.
•Low level drivers are in general stubbed out for testing under MxVDev.
•It is usually best to stub functions that contain assembly code and functions that are in pre-compiled libraries.
•If files are omitted from the build, then any variable declared in those files need to be declared in the AppIF.c file.
•Use conditional compilations to correct errors without affecting the target build. MXVDEV is defined in the MSVC build environment for this purpose.
Here are some suggestions for stubbing for various I/O drivers:
In general the I/O ports of a microcontroller are defined in a processor-specific register header file. Change this file so the ports are represented by numeric variables. Remove any embedded compiler extensions such as @0x0400. Instead declare a variable for the register or make it a macro to index a register array.
•Discrete Port I/O – Discrete ports are easily mapped to variables, usually unsigned chars. Some microcontrollers allow bit access directly to ports. We recommend using the mechanisms available in ANSI C to access individual bits. These mechanisms are portable and make it easier to set up MxVDev. There are portability issues raised when you use ‘bitfield’ operations in C.
•Analog Port I/O – Analog ports are easily mapped to variables, again by altering the register header file. Analog ports are normally converted to unsigned shorts.
•Message I/O – The low level Send and Receive calls are normally conditionally removed from the project with an #ifdef, and stubbed in the AppIF.c file. An example of how this is done for CANSend() is provided in AppIF.c for the DoorTurn sample. Also, take a look at the function CallBackVehSpeedRPM() to see how receiving a message is handled.
Suppose the function prototype for a PWM output driver is defined as: void PWMOut (uint8 DutyCycle), where DutyCycle can take a value between 0 and 100. This function is easily stubbed in the AppIF.c file as follows:
uint8 PWMOut (uint8 DutyCycle)
PWMValue = DutyCycle;
Now just add the variable PWMValue to the Signal Dictionary and you have completed the stub for this driver.
If the actual driver is in a file with other code that needs to be included in the build, then you need to use the #ifdef MXVDEV construct to eliminate the original driver from the build.
See the example functions write_EE_data() and read_EE_data() in AppIF.c for the TurnDoor sample. Note that once you have designed a stub (e.g. for your EEPROM interface), you can re-use it in many test harnesses.