User manual

104
define should be passed there), in the line parameter the line of code where the message
is logged from (__LINE__ define should be passed there), in the log_msg_id parameter the
identifier of the message to log and in the fmt parameter the format string like in printf C
runtime call and variable number of parameters to be used in accordance with the fmt
parameter. The procedure is invoked as follows:
const chapi_in * ci = …;
if (ci->log_message_ex) {
ci->log_message_ex(ci, error_msg_type, __FILE__, __LINE__,
msg_my_msg_id, “The call has failed with the code %d.”,
GetLastError());
}
The example above shows that the CHARON core is not obliged to support the indicated
operation. It also shows why the loadable component instance must remember the
chapi_in descriptor.
Message identifiers definition for the CHAPI device
Each CHAPI device have to define a set of unique messages based on predefined rules.
It is done to facilitate problem identification and allow per module multilanguage message
support in the future – message codes it the first step – further features will be added in
one of the next releases.
The following CHAPI message code format is proposed:
31 24 23 16 15 0
<vendor_id> <device_id> <message_id>
Unique vendor id should be assigned by Geneva to everyone who wants to develop using
CHAPI. VENDOR_ID_SRI = 0 is reserved for STROMASYS developed CHAPI modules;
Device id should be unique for each device with the same vendor id. How to assign device
id to particular device is up to its vendor;
Message id should be unique in scope of particular CHAPI module. Message ids
assignement is up to module developer.
CHAPI_MSG_ID(vendor, device, code) macro is defined to construct complete message id
based on its components.
Examples of message id definitions can be found in supplied example CHAPI modules
sources.
4.21.3 Debug trace
Debug trace belongs to the class of operations called “Message log request”.