Der Keil RTX-RTOS-Threadstapelgröße

Question

In der RTX-RTOS-Konfigurationsdatei von Keil RTX konnte der Benutzer die Standardgröße für den Thread-Stack konfigurieren. Im Allgemeinen enthält der Stack auto/lokale Variablen. Der Abschnitt "ZI-Daten" enthält nicht initialisierte globale Variablen.

Wenn ich also die Größe des Benutzer-Thread-Stacks in der RTX-Konfigurationsdatei ändere, erhöht sich die Stack-Größe und die "ZI-Daten" -Sektion wird nicht größer.

Ich teste es, das Testergebnis zeigt, dass wenn ich Benutzer Thread-Stack-Größe zu erhöhen. Die "ZI-Daten" Sektionsgröße wird synchron mit der gleichen Größe erhöht.

In meinem Testprogramm gibt es 6 Threads und jeder hat 600 Bytes Stapel. Ich benutze Keil das Programm zu bauen, und es zeigt mir, dass:

 
     Code (inc. data) RO Data RW Data ZI Data  Debug 

    36810  4052  1226  380  6484  518461 Grand Totals 
    36810  4052  1226  132  6484  518461 ELF Image Totals (compressed) 
    36810  4052  1226  132   0   0 ROM Totals 

============================================================================== 

    Total RO Size (Code + RO Data)    38036 ( 37.14kB) 
    Total RW Size (RW Data + ZI Data)    6864 ( 6.70kB) 
    Total ROM Size (Code + RO Data + RW Data)  38168 ( 37.27kB) 

Aber wenn ich jeden Thread Stapelgröße auf 800 Byte geändert. Keil zeigt mich wie folgt:

 
============================================================================== 


     Code (inc. data) RO Data RW Data ZI Data  Debug 

    36810  4052  1226  380  7684  518461 Grand Totals 
    36810  4052  1226  132  7684  518461 ELF Image Totals (compressed) 
    36810  4052  1226  132   0   0 ROM Totals 

============================================================================== 

    Total RO Size (Code + RO Data)    38036 ( 37.14kB) 
    Total RW Size (RW Data + ZI Data)    8064 ( 7.88kB) 
    Total ROM Size (Code + RO Data + RW Data)  38168 ( 37.27kB) 

============================================================================== 

Die "ZI-Daten" Abschnitt Größe von 6484 auf 7684 Bytes erhöhen. 7684 - 6484 = 1200 = 6 * 200. Und 800 - 600 = 200. So sehe ich den Thread-Stack ist in "ZI Data" Abschnitt.

Meine Frage ist: Bedeutet es, Auto/lokale Variablen im Thread werden in "ZI Daten" Abschnitt gesetzt werden, wenn Thread-Stack in gesetzt wird "ZI Daten" im RAM? Wenn es wahr ist, bedeutet das, dass es überhaupt keinen Stack-Bereich gibt. Es gibt nur "RO/RW/ZI-Daten" und Heap-Abschnitte.

Dieser Artikel gibt mir die andere Antwort. Und ich bin jetzt ein wenig verwirrt darüber. https://developer.mbed.org/handbook/RTOS-Memory-Model

Answer 1

Der Linker bestimmt, welche Speicherbereiche existieren. Der Linker erstellt standardmäßig einige Speicherbereiche. In Ihrem Fall werden drei dieser Standardabschnitte anscheinend als "RO-Daten", "RW-Daten" und "ZI-Daten" bezeichnet. Wenn Sie nicht explizit angeben, in welchem ​​Abschnitt sich eine Variable befinden soll, wird der Linker sie einem dieser Standardabschnitte zuweisen, abhängig davon, ob die Variable als const, initialisiert oder nicht initialisiert deklariert ist.

Der Linker erkennt nicht automatisch, dass Sie ein RTOS verwenden. Und es hat keine speziellen Kenntnisse darüber, welche Variablen Sie als Thread-Stacks verwenden möchten. Der Linker erstellt also nicht automatisch unabhängige Speicherbereiche für Ihre Thread-Stacks. Stattdessen behandelt der Linker die Stapelvariablen wie jede andere Variable und fügt sie in einen der Standardspeicherbereiche ein. In Ihrem Fall werden die Thread-Stacks offenbar vom Linker in den ZI-Data-Bereich gestellt.

Wenn der Linker spezielle unabhängige Speicherabschnitte für Ihre Thread-Stacks erstellen soll, müssen Sie dies dem Linker über die Linker-Befehlsdatei explizit mitteilen. Und dann müssen Sie auch angeben, dass sich die Stack-Variablen in Ihren benutzerdefinierten Abschnitten befinden sollen. Sehen Sie im Linker-Handbuch nach, wie das geht.

Answer 2

Aufgabenstacks müssen von irgendwo kommen - in RTX sind sie standardmäßig statisch zugewiesen und haben eine feste Größe.Der os_tsk_create_user() ermöglicht es dem Aufrufer, einen Stapel zu liefern, der auf beliebige Weise (statisch oder vom Heapspeicher; Zuordnung vom Aufruferstapel ist möglich, aber ungewöhnlich, wahrscheinlich sinnlos und sicherlich gefährlich) zugeordnet werden kann, solange es 8 hat Byteausrichtung. Ich finde die automatische Stapelzuweisung von RTX fast nutzlos und selten in allen außer der einfachsten Anwendung geeignet.