The transport implementations have to register with
ti.sdo.ipc.MessageQ. This is done via the
ti.sdo.ipc.MessageQ.registerTransport function.
If transports need additional processing during startup,
there are multiple hook points to run start-up code that
the transport implementation can use.
enum IMessageQTransport.Reason |
|
Reason for error function being called
enum Reason {
Reason_FAILEDPUT,
Reason_INTERNALERR,
Reason_PHYSICALERR,
Reason_FAILEDALLOC
};
DETAILS
First field in the
errFxn
enum IMessageQTransport.Status |
|
Transport return values
enum Status {
S_SUCCESS,
E_FAIL,
E_ERROR
};
DETAILS
- S_SUCCESS: Operation was successful
- E_FAIL: Operation resulted in a failure
- E_ERROR: Operation resulted in an error.
typedef IMessageQTransport.ErrFxn |
|
Typedef for transport error callback function
DETAILS
First parameter: Why the error function is being called.
Second parameter: Handle of transport that had the error. NULL denotes
that it is a system error, not a specific transport.
Third parameter: Pointer to the message. This is only valid for
Reason_FAILEDPUT.
Fourth parameter: Transport specific information. Refer to individual
transports for more details.
config IMessageQTransport.errFxn // module-wide |
|
Asynchronous error function for the transport module
metaonly config IMessageQTransport.common$ // module-wide |
|
Common module configuration parameters
DETAILS
All modules have this configuration parameter. Its name
contains the '$' character to ensure it does not conflict with
configuration parameters declared by the module. This allows
new configuration parameters to be added in the future without
any chance of breaking existing modules.
IMessageQTransport.setErrFxn() // module-wide |
|
Sets the asynchronous error function for the transport module
ARGUMENTS
errFxn
Function that is called when an asynchronous
error occurs.
DETAILS
This API allows the user to set the function that will be called in
case of an asynchronous error by the transport.
config IMessageQTransport.priority // instance |
|
Which priority messages should this transport manage
config UInt priority = 0;
Instance Creation |
|
create(UInt16 procId);
// Create an instance-object
ARGUMENTS
procId
Remote processor id that this instance
will communicate with.
DETAILS
This function creates a transport instance. The transport is
responsible for registering with MessageQ via the
ti.sdo.ipc.MessageQ.registerTransport API.
IMessageQTransport.control() // instance |
|
Send a control command to the transport instance
Bool control(UInt cmd, UArg cmdArg);
ARGUMENTS
cmd
Requested command
cmdArgs
Accompanying field for the command. This is
command specific.
RETURNS
TRUE denotes acceptance of the command. FALSE
denotes failure of the command.
DETAILS
This is function allows transport to specify control commands. Refer
to individual transport implementions for more details.
IMessageQTransport.getStatus() // instance |
|
Status of a Transport instance
RETURNS
Returns status of Transport instance
DETAILS
This function returns the status of the transport instance.
IMessageQTransport.put() // instance |
|
Put the message to the remote processor
ARGUMENTS
msg
Pointer the message to be sent
RETURNS
TRUE denotes acceptance of the message to
be sent. FALSE denotes the message could not be
sent.
DETAILS
If the transport can accept the message, it returns TRUE. Accepting
a message does not mean that it is transmitted. It simply means that
the transport should be able to send the message. If the actual transfer
fails, the transport calls the {@#ErrFxn} (assuming it is set up via the
{@#setErrFxn} API. If the {@#ErrFxn} is not set, the message is dropped.
(also...should an error be raised or just System_printf?).
If the transport cannot send the message, it returns FALSE and a
filled in Error_Block. The caller still owns the message.