FreeRTOS Shared Memory

Ok, ist dann folgender schematischer Ansatz richtig? Ich habe 4 Tasks.
Task 1: Liest Sensorwerte vom ADC
Task 2: Statemaschine welche anhand dieser Werte den Status ändert
Task 3: Sendet die Werte über den UART zur weiteren Verwendung
Task 4: Zeigt die Werte auf einem Display

Ich dachte, es ist sinnvoll die Werte in einen Shared Memory zu 
schreiben und die 3 Tasks holen sie sich ab wen sie diese benötigen.

Ich schreibe eine globale Zugriffsfunktion zum Schreiben und Lesen auf 
diesen Memory in etwa so:

Schreiben:
- Memory Allokieren und Handler generieren. Der Handler ist nur in der 
Funktion bekannt.
- Mutex setzten
- Werte schreiben
- Mutex löschen

Lesen:
- Mutex setzen
- Werte lesen mit Handler.... Wie übergebe ich der Funktion den Handler 
am besten?
-Mutex löschen

Zur Laufzeit wird der Speicher nie mehr freigegeben. Ist das gut so?

Danke euch!

Der MemoryPool ist auch eher eine Speicherverwaltung wie malloc, dafür 
threadsafe und bei gleich großen Blöcken kann man Speicherzerstückelung 
vermeiden.
Um Werte von einem Thread in einen anderen zu schicken bieten sich 
Queues an. Durch die Q kommen dann alle Werte sicher an solange die Q 
nicht überläuft. Für ein GUI ist das nicht unbedingt nötig, da reicht 
oft ein asynchrones reingreifen in die aktuellen Werte (atomare 
Datentypen vorrausgesetzt). Änderungen kann man da auch durch Eventflags 
signalisieren. Das sind einfache Flags an denen ein Thread warten kann 
und man spart sich ein polling. Bringt natürlich nur was wenn sich die 
Werte selten ändern.

Daten tauscht man zwischen Tasks mit Queues aus.
Ein Task füllt die Queue, ein anderer bedient sich aus der Queue bei den 
ankommenden Daten. Die Queue ist FIFO, RTOS kümmert sich um die 
Kommunikation.
Natürlich kann man um das RTOS Konzept herumprogrammieren, in dem man 
Semaphoren und globale Variablen verwendet, aber jeder kann schliesslich 
so proggen wie er es für richtig hält.

drm schrieb:
> Daten tauscht man zwischen Tasks mit Queues aus.

Werden dann die Daten in die Queue kopiert oder  sind auch Pointer 
möglich?

„Using queues that pass data by copy does not prevent queues from being 
used to pass data by reference. When the size of a message reaches a 
point where it is not practical to copy the entire message into the 
queue byte for byte, define the queue to hold pointers and copy just a 
pointer to the message into the queue instead.“

https://www.freertos.org/Embedded-RTOS-Queues.html

Ergo70 schrieb:
> the queue to hold pointers and copy just a pointer to the message into
> the queue instead.“

Wozu dann shared memory?

Mucky F. schrieb:
> Wozu dann shared memory?

Wohin zeigt der Pointer denn sonst?

Aber wenn das Zielsystem keine MMU/MPU hat und Du nicht FreeRTOS-MPU 
benutzt, ist aller Speicher aus Sicht der Tasks shared. Da gibt es keine 
Prozessisolation wie z. B. bei Linux auf Architekturen mit MMU, wo man 
shared memory explizit mit mmap() oder shmget() anfordert und dann über 
Prozessgrenzen hinweg benutzen kann.

>> Natürlich kann man um das RTOS Konzept herumprogrammieren, in dem man
>> Semaphoren und globale Variablen verwendet,
>Semaphoren sind Teil des RTOS-Konzepts.

um Signale zwischen Tasks auszutauschen, nicht Daten
z.B., Achtung, Task01 verwendet den einigen I2C Bus, alle anderen Tasks 
Finger weg von I2C

besseres Beispiel:
Daten von Task1 an Task2 über eine Queue schicken,
Task gibt eine Semaphore frei um Task2 zu signalisieren das neue Daten 
verfügbar sind. Task2 nimmt die Semaphore um zu signalisieren, das die 
Daten geholt + bearbeitet werden (es passt z.B. nur eine definierte 
Menge Daten in die Queue). Nach Abarbeitung gibt Task2 die Semaphore 
wieder frei um Task1 zu signalisieren das neue Daten entgegengenommen 
werden könnten.

Vorteil:
Task2 konsumiert keine Rechenzeit so lange es nichts zu tun gibt.
Task1 konsumiert keine Rechenzeit so lange Task2 am Arbeiten ist.

In dem Fall ist eine Semaphore unnötig, weil ein Task auch wartend auf 
Daten in der Q blockieren kann. Sowohl beim put als auch beim get.
Aber auch ein Speicherbereich ist eine Resource die man per Semphore 
schützen kann wenn ein Block konsistent sein soll, also z.B. eine 
Struktur enthält die ja in mehreren Schritten gelesen/geschrieben wird.

>Ich hab mir das Buch Hands-On-Rtos gekauft.
ISBN ?

Herausgeber ‏ : ‎ Packt Publishing (15. Mai 2020)
Sprache ‏ : ‎ Englisch
Taschenbuch ‏ : ‎ 496 Seiten
ISBN-10 ‏ : ‎ 1838826734
ISBN-13 ‏ : ‎ 978-1838826734

igitt, nur englisch

ergo70 schrieb:
> Mucky F. schrieb:
>> Wozu dann shared memory?
>
> Wohin zeigt der Pointer denn sonst?

Eben, was will der TE mit shared memory wenn das RTOS n besseres Konzept 
hat?

> Aber wenn das Zielsystem keine MMU/MPU hat und Du nicht FreeRTOS-MPU
> benutzt, ist aller Speicher aus Sicht der Tasks shared.

s.o. aber wenn er schon RTOS nutzt muss er sich nicht drum kümmern.

drm schrieb:
> Task gibt eine Semaphore frei um Task2 zu signalisieren das neue Daten
> verfügbar sind. Task2 nimmt die Semaphore

Das die Unterprogramme sich irgenwie einigen müssen wer was wann damit 
macht finde ich irgenwie selbstverständlich.

Warum da so ein unübersichtliches Semaphorengebastel sein muss verstehe 
ich aber eher weiniger. Da enstehen lokale interdependenzen die schwer 
zu tracken sind, zuminmest für mich.  Das kann man imo mit ner zentralen 
Statusvariable und enum einfacher lösen.

Was anderes habe ich doch auch nicht geschrieben. Da es keinen 
speziellen Speicherschutz gibt, ist aller Speicher geteilter Speicher. 
Und die Frage wohin der Pointer zeigt, sollte eigentlich nur darauf 
hinweisen, dass er auf Speicher zeigen sollte der auch allokiert ist.