NXP Reader Library Peer to Peer User Manual
All information provided in this document is subject to legal disclaimers.
© NXP B.V. 2018. All rights reserved.
User manual
COMPANY PUBLIC
Rev. 1.2 — 5 August 2018
270112
See section 4.1.5 and 4.1.6 that only content of *
pRemoteDevInfo
and *
pLinkParams
is
needed for “direct access”. Other data parameter components pointed by members of
parameter component do not need to be initialized to any particular values. They must be
only declared before initialization of the
phlnLlcp_Fri_DataParams_t
parameter component.
returnValues:
PH_ERR_SUCCESS
Operation successful.
3.2.3 Pending
Sometimes the current request cannot be performed in time, due to another operation is
running. For example, the local intends to send disconnect request, but the link is
currently performing receiving from the remote. Thus, the disconnect request is pending
means placed into “waiting queue”. The disconnect request shall be send as soon as the
link will perform sending operations. All the pending cases are managed internally, thus
the developer need not to care about it.
3.2.4 Callbacks
In the P2P Library provides notification to the application layer via callbacks when an
important event on LLCP layer occurs. The developer may build his own function,
declare it and set it like a callback. The developer’s defined callback function must fulfill
the function prototype for the particular callback type defined in the library. All the socket
related callbacks prototypes are in
NxpRdLib_PublicRelease/comps/phlnLlcp/src/Fri/phFriNfc_LlcpTransport.h. But the
developer is totally free in building the body of the callback function. Except the callback
function must be declared right, it can be triggered at an event after set by the dedicated
function. In the sections 3.2.8 and 3.2.10 there are link and callback prototypes clarified
through following pattern:
Called at event: the event on LLCP that triggers the user CB function is called.
Set by: the user defined CB function address need to be passed like the input argument
to the certain function. In fact, the function address is assigned to internal library
parameter structure. From this time on, the user defined CB can be called when the
event occurs.
Function prototype: although the function body may be defined by the user, the function
header and return value need to agree with the CB function prototype defined by the P2P
library. Function may be a type void.
Input arguments: are explained one by one. In general, there are two input arguments
passed to the called CB. The first input argument passed to each CB is
pContext
-
pointer to application layer data of any type. The pointer needs to be passed to the
dedicated LLCP Link API or LLCP Transport Socket API function from section
3.2.7 or
3.2.9 respectively in the same time as pointer to CB function. The data may be later used
during the CB function execution. The second on third argument (if any) are information
passed by the caller of the CB – from within the P2P library, giving precious information
about the event related circumstances.
There are two types of callbacks in general. Link related callbacks and socket related
callbacks. The link callbacks are called when link status changes from activated to
deactivated or vice versa. The socket callbacks are triggered on dedicated socket
events.
