Studio:Advantages and disadvantages of "default" candidates

The following table describes the advantages and disadvantages associated with the "default" candidate method vs. the candidate method.

	"Default" candidate method	Candidate method
Define and pragmatize each function prototype	Not needed.	Cumbersome if there are hundreds of candidate functions.
Code footprint of the generated code	Only the proxy/stub of the "default" candidate is generated; thus, the code footprint is much smaller.	The code footprint is dependent upon how many candidates are defined using the scl_ptr_flist() pragma, since a proxy/stub is generated for each candidate defined in the list.
Capturing of function callback command/response payloads via the trace module	Any function callback command/response payloads with the identical signature can be captured.	Only those candidate functions defined in the scl_ptr_flist() pragma can be captured.
Visibility of function callbacks via the trace module	The function callback being called is unknown. All of the function callbacks with the identical signature will be displayed with the "default" candidate name and SMID.	All of the function callbacks being called are known, as long as the candidate functions were declared in the scl_ptr_flist() pragma.

One disadvantage of using the shorthand method to define candidates in scl_ptr_flist(), as shown in Method 3 of the Working with "default" candidates topic, is that the function pointer prototypes are not defined by the user/customer, but rather by STRIDE. So, for example, if the user wants to create a proxy for foo2() with stub candidate functions C2 and "cand4" on the target, the generated IM code will give "undefined" compiler errors for "cand4". The following procedure using the header file MyHeader.h (the file containing the SCL pragmas or function prototypes) resolves this issue:

#ifdef srIMON

void cand4(int x, char y);

#endif 

The use of the srIMON preprocessor directive allows the SDAC to compile the file without any name conflicts for "cand4", since these are already defined within STRIDE. It also allows the generated IM code to compile successfully.

MyFunctions.c

MyFunctions.c is an example of a user-created file containing the actual code for the candidate "cand4":

void cand4(int x, char y)

{ 

} 
 

MyTest.c

MyTest.c is an example of a user-created file containing a test thread that makes the call to foo2() with the appropriate function pointer callback:

#include “MyHeader.h”

FPtr funcPtr;

// set to cand4

funcPtr = cand4;

foo2(&funcPtr);

In some instances, the candidates on the target are not known to the implementer of foo2() and the candidates may be static, so the above solution isn’t applicable. Using the “default” candidate mechanism is the perfect solution to this problem. The following example demonstrates how to do this (refer to Method 3 above):

In MyHeader.h (the file that contains the SCL pragma’s or the function prototypes), replace the following:

#pragma scl_ptr_flist(*foo2.pFPtr, “cand4”, C2)

with:

#pragma scl_ptr_flist(*foo2.pFPtr, “default_cand”) // default candidate

MyFunctions.c

MyFunctions.c is an example of a user-created file containing the actual code for the candidates (unknown_cand1, unknown_cand2):

static void unknown_cand1(int x, char y)

{

}

static void unknown_cand2(int x, char y)

{

}

MyTest.c

MyTest.c is an example of a user-created file containing a test thread that makes the call to foo2() with the appropriate function pointer callback.

#include “MyHeader.h”

FPtr funcPtr;

// set to unknown_cand1

funcPtr = unknown_cand1;

foo2(&funcPtr);

// set to unknown_cand2

funcPtr = unknown_cand2;

foo2(&funcPtr);