Ember Connect API dynamically allocates and frees memory. More...
|A special EmberBuffer ID indicating that no memory is currently allocated. More...|
The Application Framework implements all handlers, directly calling their associated callbacks. By default, Connect projects declare such callbacks as stubs in flex-callbacks-stubs.c. Hence, to use an enabled Connect feature, applications should replace the stub with their own implementation of the associated callback (typically in flex-callbacks.c). See UG235.04 for more info.
|This handler is invoked by the memory buffers system garbage collector and allows the application to properly mark the application-defined EmberBuffer variables with emberMarkBuffer(). More...|
|EmberBuffer||emberAllocateBuffer (uint16_t dataSizeInBytes)|
|Dynamically allocates memory. More...|
|void||emberMarkBuffer (EmberBuffer *buffer)|
|Prevent the garbage collector from reclaiming the memory associated with the passed EmberBuffer. The application should call this API within the emberMarkApplicationBuffersHandler() stack handler for each EmberBuffer object. More...|
|uint8_t *||emberGetBufferPointer (EmberBuffer buffer)|
|Return a pointer to the memory segment corresponding to the passed EmberBuffer buffer. Notice that the garbage collector can move memory segments to defragment the available memory. As result, the application should always use this API to obtain an updated pointer prior to accessing the memory. More...|
|uint16_t||emberGetBufferLength (EmberBuffer buffer)|
|Return the length in bytes of the passed EmberBuffer buffer. More...|
|Return the available memory at the buffer manager in bytes. More...|
Ember Connect API dynamically allocates and frees memory.
Generally, dynamic memory allocation in embedded code is not recommended. However, in some cases, the drawbacks of avoiding them is even bigger. Using C standard library dynamic memory is still not recommended due because it could cause fragmented memory.
For these reasons, Connect allocates some (configurable in the stack common plugin) memory as HEAP at compile-time. Memory allocation from this heap is possible through the API below.
memory-buffer.h for source code.
Macro Definition Documentation
|#define EMBER_NULL_BUFFER NULL_BUFFER|
A special EmberBuffer ID indicating that no memory is currently allocated.
Definition at line
37 of file
Dynamically allocates memory.
The size in bytes of the memory to be allocated.
- An EmberBuffer value of EMBER_NULL_BUFFER if the memory management system could not allocate the requested memory, or any other EmberBuffer value indicating that the requested memory was successfully allocated. The allocated memory can easily be freed by assigning an EmberBuffer variable to EMBER_NULL_BUFFER. The memory will be freed by the garbage collector during the next emberTick() call.
Return the available memory at the buffer manager in bytes.
- The number of available bytes.
Return a pointer to the memory segment corresponding to the passed EmberBuffer buffer. Notice that the garbage collector can move memory segments to defragment the available memory. As result, the application should always use this API to obtain an updated pointer prior to accessing the memory.
A pointer to the EmberBuffer buffer for which the corresponding memory pointer should be returned.
- Implement associated callback emberAfMarkApplicationBuffersCallback() to use. See Handlers for additional information.
|void emberMarkBuffer||(||EmberBuffer *||)|