Choose Memory-Management Model
237
SWRU455A – February 2017 – Revised March 2017
Copyright © 2017, Texas Instruments Incorporated
Porting the Host Driver
17.6 Choose Memory-Management Model
The SimpleLink host driver supports two memory models: static (default) and dynamic.
The major difference between these memory models is that the static model requires the memory
allocation of the driver’s control block, even when the driver is not active, and the dynamic does not. In the
dynamic model, the control block and all required resources are allocated on sl_Start and freed on
sl_Stop.
To enable the dynamic model, the macro SL_MEMORY_MGMT_DYNAMIC must be defined. For
example:
#define
SL_MEMORY_MGMT_DYNAMIC
And a complementary malloc and free functions must also be defined:
•
sl_Malloc – Allocates a buffer of at least the given size and returns a pointer to this buffer. Prototype:
void* sl_Malloc(int Size);
•
sl_Free – Frees a given buffer by a pointer. Prototype:
void
sl_Free(void* pBuff);
NOTE:
TI recommends using the static memory management model.
17.7 Implement OS Adaptation Layer
The SimpleLink Wi-Fi host driver can run on multithreaded environment (OS), as well as a non-OS
environment. This step is not required if the host application is based on a non-OS environment.
To enable the multithreaded environment, the macro SL_PLATFORM_MULTI_THREADED must be
defined. For example:
#define
SL_PLATFORM_MULTI_THREADED
The OS adaptation layer consists of two major objects:
•
Sync objects – To allow synchronization between threads
•
Locking objects – To protect access to resources from different threads
17.7.1 Sync Objects
A sync object is an object used to synchronize between two threads, or between a thread and an interrupt
handler. One thread is waiting on the object and the other thread or interrupt handler sends a signal,
which then releases the waiting thread. The signal can be sent from interrupt context. This object is
generally implemented by binary semaphore.
The type of the sync object is defined by the host application as needed, by defining the _SlSyncObj_t
function as a typedef or a macro.
#define
_SlSyncObj_t
HANDLE
The following functions should also be implemented:
•
sl_SyncObjCreate – Creates a sync object. The function receives a pointer to a memory control block
for the object, which is later passed to the other functions of the sync object.
•
sl_SyncObjDelete – Destroys a sync object. If one of the threads already waits on the sync object
while this function is called, the driver expects that the waiting thread will exit with an error when this
function is called.
•
sl_SyncObjSignal – Generates a synchronization signal to the sync object from a thread context, which
should release the other thread context that is waiting on this sync object.
•
sl_SyncObjSignalFromIRQ – The same as sl_SyncObjSignal, but called from interrupt handler routine.
In most operating systems, there is no difference between these functions, but in some operating
systems there is a special function for this function.
•
sl_SyncObjWait – Waits for a synchronization signal of a specific sync object. The calling thread is
blocked on this function until the signal is generated or time-out value elapsed. If the function is called
