Implement OS Adaptation Layer
238
SWRU455A – February 2017 – Revised March 2017
Copyright © 2017, Texas Instruments Incorporated
Porting the Host Driver
after the signal is already generated, the waiting thread should be released immediately.
17.7.2 Locking Objects
Locking objects are used to protect resources from mutual accesses of two or more threads. A locking
object should support reentrant locks by a single thread. This object is generally implemented by a mutex
semaphore.
The type of the locking object could be defined by the host application as needed, by defining the
_SlLockObj_t function as a typedef or a macro. For example:
#define
_SlLockObj_t
HANDLE
The following functions should also be implemented:
•
sl_LockObjCreate – Creates a locking object. The function receives a pointer to a memory control
block for the object, which is later passed to the other functions of the locking object.
•
sl_LockObjDelete – Destroys a locking object.
•
sl_LockObjLock – Locks a locking object. Other threads that try to lock the same object must be
suspended until the locking thread unlocks this locking object.
•
sl_LockObjUnlock – Unlocks a locking object to be used by other threads.
17.8 Implement Timestamp Services
The SimpleLink host driver supports a time-out mechanism for busy loops that the operating systems
object do not support (for example, while waiting for a response from the device between a small SPI
transactions). These time-outs require an implementation of timestamp mechanism.
NOTE:
TI recommends implementing this mechanism.
To implement this mechanism, the host application must provide a function that retrieves the current
timestamp:
•
slcb_GetTimestamp – Gets counter value in ticks units
In addition, the host application must declare the time resolution of the timestamp on the platform by using
the following macros:
•
SL_TIMESTAMP_TICKS_IN_10_MILLISECONDS
•
SL_TIMESTAMP_MAX_VALUE
The default time-out values are set to meet the common values of an average system. If the host
application needs to, it can set a different time-out value by defining the following macros:
•
SL_DRIVER_TIMEOUT_SHORT – In ms. By default, set to 30 seconds if this macro is not defined.
•
SL_DRIVER_TIMEOUT_LONG – In ms. By default, set to 60 seconds if this macro is not defined.
•
SYNC_PATTERN_TIMEOUT_IN_MSEC – In ms. By default, set to 60 seconds if this macro is not
defined.
17.9 Set Asynchronous Event Handler Routines
The host application can register asynchronous event handler routines for the different API silos. TI
recommends registering to all of these routines and handling the different events. Registering to these
routines is optional, and might be changed from one host application implementation to another.
The following asynchronous event handlers can be registered:
•
slcb_DeviceFatalErrorEvtHdlr – Handles fatal errors from the device or the host driver. After this
routine is called, the host application must restart the driver and the device (call to sl_Stop and
sl_Start) to continue using the device.
•
slcb_DeviceGeneralEvtHdlr – Handles general errors from the device.
•
slcb_WlanEvtHdlr – Handles events and errors of the WLAN silo
•
slcb_SockEvtHdlr – Handles events and errors of the Socket silo.
