Partition Memory in Nucleus SE: Konfiguration, APIs und Best Practices

View the RTOS Revealed series

Memory Partitions wurden in unserem früheren Artikel eingeführt, wo wir sie mit der konventionellen C malloc() Funktion verglichen. Eine Partition ist ein fixed-size Memory Block, der aus einem Partition Pool kommt, und bietet deterministische Allocation und Deallocation, auf die Tasks sich verlassen können.

Partitions nutzen

In Nucleus SE werden Partition Pools zur Compile Time definiert. Bis zu 16 Pools können pro Applikation konfiguriert werden. Wenn keine Pools definiert sind, werden alle zugehörigen Data Structures und API Code vom Build omitted, was den Footprint minimal hält.

Ein Pool ist einfach ein contiguous Memory Area, unterteilt in eine Set Number identischer Partitions. Die Applikation kontrolliert Size und Count jedes Pools. Tasks requesten eine Partition und erhalten einen Pointer zum Block. Es ist die Verantwortung des Callers, innerhalb der allokierten Bounds zu bleiben. Eine Partition kann von jedem Task via Deallocate API an den Pool zurückgegeben werden. Wenn der Pool exhausted ist, kann der Call einen Error returnen oder den Task suspenden, abhängig von API Parametern und Build Optionen.

Memory Partitions konfigurieren

Anzahl Partition Pools

Partition Pools werden durch #define Statements in nuse_config.h enabled. Das Schlüssel Symbol ist NUSE_PARTITION_POOL_NUMBER, welches die Count der Pools setzt. Default ist 0, meaning keine Pools sind active. Gültige Werte reichen von 1 bis 16; ein invalid Wert triggert einen Compile-Time #error generiert von nuse_config_check.h.

Ein Non-Zero Wert aktiviert die notwendigen Data Structures und initialisiert sie in ROM. Es unlockt auch die API Enable Symbole, die unten beschrieben sind.

API Enables

Jeder Service Call hat ein Enable Macro in nuse_config.h. Für Partitions existieren folgende Symbole:

• NUSE_PARTITION_ALLOCATE
• NUSE_PARTITION_DEALLOCATE
• NUSE_PARTITION_POOL_INFORMATION
• NUSE_PARTITION_POOL_COUNT

Standardmäßig sind alle auf FALSE gesetzt, stripping die Implementation vom Build. Um ein Feature zu nutzen, setzen Sie das entsprechende Macro auf TRUE. Enablen eines APIs während keine Pools definiert sind (außer NUSE_Partition_Pool_Count()) resultiert in Compile-Time Error. Using eines APIs, das nicht enabled ist, verursacht Link-Time Error.

Partition Pool Service Calls

Nucleus RTOS bietet sieben Service Calls für Partition Pools. In Nucleus SE sind nur die Kern Allocation und Deallocation APIs implementiert. Die Tabelle unten listet jeden Call, seinen Implementation Status, und eine kurze Beschreibung:

Beachten Sie, dass weder Nucleus RTOS noch SE eine Reset Routine für Partition Pools bereitstellen. Diese Design Wahl reflektiert typische Use Cases, wo ein Task eine Partition allokiert und seinen Pointer an einen anderen Task handed, der sie schließlich deallokiert. Resetting eines Pools würde stillschweigend alle Partitions als free markieren, brechend den Task-Level Contract.

Allocation und Deallocation Services

Die Kern Operationen sind:

• Allocate: Markiere eine Partition als used und returniere ihre Address.
• Deallocate: Markiere eine Partition als free.

Nucleus RTOS Allocation API

Prototype:

STATUS NU_Allocate_Partition(NU_PARTITION_POOL *pool, VOID **return_pointer, UNSIGNED suspend); 

Return Values inkludieren NU_SUCCESS, NU_NO_PARTITION, NU_INVALID_POOL, NU_INVALID_POINTER, NU_INVALID_SUSPEND, NU_TIMEOUT, und NU_POOL_DELETED.

Nucleus SE Allocation API

Prototype:

STATUS NUSE_Partition_Allocate(NUSE_PARTITION_POOL pool, ADDR *return_pointer, U8 suspend); 

Parameter:

• pool – Index des zu nutzenden Pools.
• return_pointer – Address des allokierten Blocks.
• suspend – NUSE_NO_SUSPEND oder NUSE_SUSPEND.

Return Codes spiegeln jene von RTOS aber sind mit NUSE_ prefixed. Invalid Suspend Requests von Non-Task Threads oder wenn Blocking APIs disabled sind, produzieren NUSE_INVALID_SUSPEND.

Für einen vollständigen Implementation Walkthrough, sehen Sie die nachfolgenden Artikel in der RTOS Revealed Serie.