FreeRTOS -> LCD task

[Vincent H. (vinci)]

Grüß euch

Ich arbeite mich gerade in FreeRTOS ein und würde gern ein paar kleine 
Projekte realisieren die von verschiedenen Features gebrauch machen. 
Ziel der Aufgabe soll sein ein wenig ein Gefühl dafür zu bekommen, was 
bezüglich Design-Paradigmen Sinn ergibt und wie man klassische 
Interrupt-basierte Programme auf Tasks aufteilt.

Wozu ich momentan noch überhaupt keine Idee habe ist, wie man ganz 
einfache graphische Ausgaben, etwa an ein LCD, am vernünftigsten löst. 
Während das bei Interrut-basierten Programmen bei mir wohl ein Timer 
wäre, der auf jede Menge globale Variablen ("shared data") zugreift um 
sich die nötige Information für die Ausgabe zusammenzuklopfen, bin ich 
nicht so sicher ob das bei einem RTOS auch zielführend ist.

Nur wie kommt ein einziger LCD-Task sonst vernünftig an etwa zig 
verschiedene Variablen? Nehmen wir mal an man möchte für ein Steuergerät 
etwa
- Drehzahl
- Geschwindigkeiten
- Motorstrom/spannung
- Akkuspannung
- Uhrzeit
etc. ausgeben, dann sind das wohl oder übel Informationen die aus zig 
verschiedenen Tasks kommen würden. Im schlimmstenfall sind das dann 
nicht nur einzelne Werte, sondern größere Datenmengen... Wie handhabt 
man solche Fälle am besten?

[Markus M. (adrock)]

Naja, bein kein RTOS Spezialist, aber es gibt m.E. mehrere 
Möglichkeiten:

- Die auszugebenden Daten von den anderen Tasks per Message/Queue an den 
Anzeigetask schicken lassen

- Du teilst Speicherbereiche zwischen den Tasks und regelst ggf. den 
Zugriff über eine Sempahore

[Vincent H. (vinci)]

Beides erscheint mir bei vielen verschiedenen Quellen als umständlich. 
Dutzende Semaphore regeln ist vermutlich fehleranfällig, während eine 
Queue ja jedes mal allokiert/kopiert werden müsste...? Je nach Umsetzung 
im Code ist das bei großen Datenmengen wohl auch nicht so vernünftig?

[moep (Gast)]

Vincent H. schrieb:
> Dutzende Semaphore regeln ist vermutlich fehleranfällig,

Warum dutzende?

Du könntest eine Struktur definieren, die dein "Prozessdatenabbild" 
darstellt.

struct {
  int drehzahl;
  int akkuspannung;
} processData;

In die Struktur selbst packst du jetzt den zugehörigen Mutex.

struct {
  SemaphoreHandle_t mutex;
  int drehzahl;
  int akkuspannung;
} processData;

Die Struktur legst du zu Beginn einmal an und verteilst den Pointer auf 
darauf an alle Tasks die schreibend/lesend darauf zugreifen.
Innerhalb der Tasks kannst du dann den Mutex locken und sicher 
zugreifen.

for(;;)
{
  xSemaphoreTake( processData->mutex, portMAX_DELAY  ); // try to take mutex, block task if not obtainable

  UpdateDisplay( processData );

  xSemaphoreGive( processData->mutex ); // put putex when done

  vTaskDelay( 1000 / portTICK_PERIOD_MS ); // sleep 1sec
}

Das selbe dann für die schreibenden Zugriffe. Hier müssen dann natürlich 
die Taskprioritäten passen. Die Displaytask wird vermutlich recht 
niederprior sein, dennoch nicht ständig verdrängt werden, damit dein 
Display noch regelmäßig refreshed wird.

[Markus M. (adrock)]

Ja, so würde ich es auch machen. Es ist quasi eine globale Struktur 
zwischen allen Tasks, die durch Mutex gegen den konkurrierenden Zugriff 
geschützt ist.

Du kannst auch dem Display-Task bei Veränderungen an den Daten noch eine 
Art "Signal" schicken, dann weiß er, dass er die LCD Anzeige jetzt 
updaten muss.

Erinnert mich irgendwie an die Amiga Programmierung :-)

[Jens (Gast)]

Hallo,

ich arbeite gerade auch mit FreeRTOS und habe mir eine Art Kommando 
Struktur angelegt, welche ich durch eine Queue zum entsprechenden Task 
schicke.
Bei Daten (Strings) reserviere ich mir den Speicher mit malloc bis der 
Task die Daten abgearbeitet hat. Der Task gibt den Speicher dann wieder 
frei.
In deinem Fall könntest du eine Struktur in die Queue schreiben, welche 
den Zielort und einen Textpointer beinhaltet.

Wenn der zu sendende Task dann noch eine Antwort braucht könnte dieser 
eine Queue zur Verfügung stellen, in die die Antwort geschrieben wird.

Jens

[Frank S. (Gast)]

Hallo Jens,

könntest Du dazu mal ein kurzes Beispiel aufzeigen?

Danke, Frank

[Jens (Gast)]

Klar,

die Struktur:

typedef struct {
  QueueHandle_t Sender;
  char CMDType:4;
  char* CMD;
  char* DATA;
} S_CMD;


int AddCMD(QueueHandle_t Sender, char CMDType,  char* cmd, char* waitfor, char* data){
S_CMD CMD;
CMD.CMDType=CMDType;
CMD.DATA=data;
CMD.Sender=Sender;

if(cmd){
  CMD.CMD = malloc(strlen(cmd)+1);
  strcpy(CMD.CMD, cmd);
}else{
  CMD.CMD = 0;
}

/* Daten in die CMD queue schreiben */
if(!(pdTRUE == xQueueSend(xQueueCMD, &CMD,10))){ //Kommando Absetzen
  if(CMD.CMD) free(CMD.CMD);
  printf("Add command fail\n");
  return 0;
}

Der LCD Task kann dann die Daten auslesen und verarbeiten
In meinem Fall hatte ich noch einen WaitFor Befehl drin, welcher in 
Sender (Queue Pointer) Daten zurück geschickt hat.
Ich nutze das ganze mit einem SIM808 GPRS / GPS Modul zur UART 
Schnittstelle.

Jens

[Guest (Gast)]

Der Fehler liegt wohl schon in der Auswahl des RTOS ;-). Nimm lieber 
embOS, https://www.segger.com/embos.html. Musst ja keine Lizenz kaufen 
für deinen privaten Kram.

Die Idee mit Mailbox/Queue war schon die richtige. Letztlich geht es ja 
auch darum, das die LCD Task nur dann was macht, wenn auf dem LCD etwas 
verändert werden muss. Die einzelnen Task können ihre neuen Daten 
einfach in die Mailbox schreiben und sobald neue Daten in der Mailbox 
sind wird die LCD Task aktviert und arbeitet die Messages ab.

[kopierer (Gast)]

Das Problem ist mehr das das wichtige Dokument "Using the FreeRTOS Real 
Time Kernel - A Practical Guide - Cortex-M3 Edition" nur im Land der 
Kopierer kostenfrei zu finden ist ;)

[Vincent H. (vinci)]

Guest schrieb:
> Der Fehler liegt wohl schon in der Auswahl des RTOS ;-). Nimm lieber
> embOS, https://www.segger.com/embos.html. Musst ja keine Lizenz kaufen
> für deinen privaten Kram.

Segger ist leider der "Apfel" unter den embedded Firmen. Überteuerte 
Produkte, dekadenter Service. Nein Danke.


Die Ideen mit globalen Strukturen gefallen mir eher weniger. Ich denke 
mit immer weiteren Abstraktionen in Richtung Betriebssysteme sollte und 
kann langsam mal auf hochsprachigere Design Methoden zurückgreifen und 
da is "global und shared" halt doch eher verpöhnt.

Ich werd mir mal ansehn was FreeRTOS an Queues/MailBoxes(?) bietet.

[Guest (Gast)]

Vincent H. schrieb:
> Segger ist leider der "Apfel" unter den embedded Firmen. Überteuerte
> Produkte, dekadenter Service. Nein Danke.

Könntest du das bitte näher erklären? Vielleicht verwechselt du 
Hobbybereich bzw. Hobbypreise mit kommerziellen Produkten?

Davon abgesehen das ich einen J-Link EDU für 42,- Euro und eine embOS 
Trial für 0,- Euro nicht als überteuert empfinde.
Und was ist bei dir dekadenter Service?
Ich finde gerade im Service unterscheidet sich Segger von anderen.
Die waren bei mir immer sehr freundlich und kompetent bei den Antworten.

kopierer schrieb:
> Das Problem ist mehr das das wichtige Dokument "Using the FreeRTOS Real
> Time Kernel - A Practical Guide - Cortex-M3 Edition" nur im Land der
> Kopierer kostenfrei zu finden ist ;)

Das ist echt ein Witz bei FreeRTOS das ich für das User Manual als PDF 
Geld bezahlen soll. Das embOS Manual ist z.B. nur einen Klick entfernt 
und natürlich kostenlos: 
https://www.segger.com/downloads/embos/UM01001_embOS.pdf

[Bilal Bastürk (Gast)]

Guest schrieb:
> Könntest du das bitte näher erklären? Vielleicht verwechselt du
> Hobbybereich bzw. Hobbypreise mit kommerziellen Produkten?

Wahrscheinlich weil selbst im Hobbybereich ein RTOS mit maximal drei 
Threads bzw. nur 12 Stunden Laufzeit für vielen Anwendungen nicht zu 
gebrauchen ist....

[hzddd (Gast)]

prinzipiell über mailbox ...

entweder die texte selbst in die box legen ...
oder nur  events  senden

im task dann nur :

void *Event_mbox = NULL;

void SendEvent( event_t evt, ... ){
   struct user_msg msg;
   msg.event   = evt;
   xQueueSend( Event_mbox, msg, 0 );
}

void task( * param){
   struct user_msg msg;
   Event_mbox = xQueueCreate( 6, sizeof( struct user_msg ) );

   for(;;){
      if ( pdTRUE == xQueueReceive( Event_mbox, &msg, 0xffffffffUL ) ){
        switch ( msg.event ){
  case LCD_WERT1:
           lcd_write(.....)
     break;
  case LCD_WERT2:
     break;
  case LCD_WERT3:
     break;
      }
   }
}

[Tester (Gast)]

Bilal Bastürk schrieb:
> Guest schrieb:
>> Könntest du das bitte näher erklären? Vielleicht verwechselt du
>> Hobbybereich bzw. Hobbypreise mit kommerziellen Produkten?
>
> Wahrscheinlich weil selbst im Hobbybereich ein RTOS mit maximal drei
> Threads bzw. nur 12 Stunden Laufzeit für vielen Anwendungen nicht zu
> gebrauchen ist....

Was heißt denn "selbst"? Im nicht Hobbybereich wird ja die Lizenz 
gekauft und damit hat man natürlich diese Limitierung nicht...

Mit drei Threads kann man aber schon eine Menge machen. Davon abgesehen, 
das man ja auch noch einiges in embOS Software Timern erledigen kann und 
dafür gibt es keine Limitierung.

Und irgendwie sehe ich auch ein das Segger mit embOS eigentlich Geld 
verdienen möchte und das nicht nur für den Hobbyanwender entwicklelt 
;-).

[Vincent H. (vinci)]

Guest schrieb:
> Vincent H. schrieb:
>> Segger ist leider der "Apfel" unter den embedded Firmen. Überteuerte
>> Produkte, dekadenter Service. Nein Danke.
>
> Könntest du das bitte näher erklären? Vielleicht verwechselt du
> Hobbybereich bzw. Hobbypreise mit kommerziellen Produkten?

Der JLINK hatte in einer vergangenen Hardware-Version schwerwiegende 
Fehler, die das interne Flash zerschossen haben. Ich hab den Fehler bei 
der Pro Version beobachtet, aber ich nehm an er war überall drin... 
steckt ja auch in jedem von den Dinger der selbe Schrott drin soweit ich 
weiß.

Seitens Segger gab es damals dazu
a) KEINERLEI Service
b) nicht einmal eine offizelle Firmware-Version

Also Kunde konnte man sich somit lediglich eine (natürlich illegale) 
Firmware Version besorgen, die man selbst neu aufgespielt hat... Hat 
aber auch nicht viel gebracht, weil das Flash eine halbe Stunde später 
wieder futsch war.


> Das ist echt ein Witz bei FreeRTOS das ich für das User Manual als PDF
> Geld bezahlen soll. Das embOS Manual ist z.B. nur einen Klick entfernt
> und natürlich kostenlos:
> https://www.segger.com/downloads/embos/UM01001_embOS.pdf

embOS ist mit seinen 2.490€ aber leider nicht ganz kostenlos...



/edit
Ich kann nicht sagen dass embOS ein schlechtes Produkt wäre. Aber mit 3 
Tasks fang ich persönlich einfach nix an. Und bei FreeRTOS gibts 
keinerlei Beschränkung und gratis is der Spaß auch noch... mal davon 
abgesehn dass der OpenSource Gedanke natürlich zu unterstützen ist.

[René K. (cyprius)]

Tester schrieb:
> Mit drei Threads kann man aber schon eine Menge machen.

"Eine Menge" ist subjektiv. Was, wenn es dann doch mal nicht ausreicht 
aber man die Einarbeitungszeit schon investiert hat? Ich bin mir sicher, 
dass nicht viele Hobby-Entwickler 5k€ für eine Lizenz bezahlen möchten, 
egal wie gerechtfertigt das Geld dafür ist.
Du bellst leider gerade einfach den falschen Baum hoch, der TE hat sich 
nicht über sein RTOS beschwert sondern eine recht generische 
Konzeptfrage gestellt.

[Pandur S. (jetztnicht)]

Man schreibt mit genau einem Prozess auf den display. Der laeuft 
natuerlich nicht in einem interrupt und hat auch keinen Delay. Ein 
Display wird wie oft ge-updated ? 10 mal pro sekunde ? Was geschieht 
wenn die nicht alle Daten aufeinander passen ?
Meine Erfahrung : es ist egal. Mehr als 10 Updates ist sowieso sinnlos, 
weil man's nicht mehr sieht. Und ob eine Zahl eine Zeitscheibe spaeter 
kommt, was soll's. Die Werte sind sowieso kontinuierlich, stetig. Denn 
wenn die Werte ueber die Zeit nicht stetig sind, kann man nicht 
aufnehmen. Also keine Semaphore, nichts. Das Datenfeld zum Display wird 
irgendwoher erneuert, und der Display prozess schreibt's auf den 
Display. Und Fertig.

[Guest (Gast)]

Vincent H. schrieb:
> Der JLINK hatte in einer vergangenen Hardware-Version schwerwiegende
> Fehler, die das interne Flash zerschossen haben. Ich hab den Fehler bei
> der Pro Version beobachtet, aber ich nehm an er war überall drin...
> steckt ja auch in jedem von den Dinger der selbe Schrott drin soweit ich
> weiß.

Das halte ich für unwahrscheinlich aber kann man jetzt hier eh nicht 
weiter nachvollziehen. Naja, Schrott ist das wohl kaum, ansonsten würden 
nicht soviele verkauft und erfolgreich eingesetzt werden. Ich arbeite 
seit über 10 Jahren mit J-Link und bin sehr zufrieden.

Vincent H. schrieb:
> Also Kunde konnte man sich somit lediglich eine (natürlich illegale)
> Firmware Version besorgen, die man selbst neu aufgespielt hat... Hat
> aber auch nicht viel gebracht,
Lol, ernsthaft?? Du spielst illegal irgendeine Software auf, erwartest 
das damit irgendwas funktioniert und gibst Segger die Schuld?

Vincent H. schrieb:
> Ich kann nicht sagen dass embOS ein schlechtes Produkt wäre. Aber mit 3
> Tasks fang ich persönlich einfach nix an. Und bei FreeRTOS gibts
> keinerlei Beschränkung und gratis is der Spaß auch noch... mal davon
> abgesehn dass der OpenSource Gedanke natürlich zu unterstützen ist.
Klar, das vertehe ich. Das sind halt zwei Welten, Open Source und Leute, 
die damit Geld verdienen müssen.

René K. schrieb:
> Ich bin mir sicher,
> dass nicht viele Hobby-Entwickler 5k€ für eine Lizenz bezahlen möchten,
> egal wie gerechtfertigt das Geld dafür ist.
Es sind nur 2.5 KEuro, aber klar, das ist natürlich für einen 
Hobbyentwickler zuviel!

> Du bellst leider gerade einfach den falschen Baum hoch, der TE hat sich
> nicht über sein RTOS beschwert sondern eine recht generische
> Konzeptfrage gestellt.
Ja ok, sehe ich ein, ich wollte auch nur mal eine Alternative aufzeigen, 
weil ich selbst damit so zufrieden bin.

[Vincent H. (vinci)]

Guest schrieb:
> Lol, ernsthaft?? Du spielst illegal irgendeine Software auf, erwartest
> das damit irgendwas funktioniert und gibst Segger die Schuld?

Bitte lern sinnerfassend lesen. Segger verweigerte jeglichen Support und 
empfahl ein neues Gerät zu kaufen. Um sich einen Fehler in der 
Entwicklung einzugestehn war man sich offenbar zu gut.

Selbst die Firmware des Gerätes, die man ja selbst ohne Probleme hätte 
flashen können, wollte man nicht rausrücken. Aus diesem Grund wurde eine 
illegale Version eingespielt, mit der das Gerät kurzfristig wieder 
lauffähig wurde... zumindest solang bis der interne Flash sich wieder 
verabschiedete.