Seltsames Programmverhalten

da weiste doch .... 42 :-)

Hatte die bool Variable im private Bereich unter einer Klasseninstanz in 
welcher ich string Variablen initialisiere. (std::string a = "123";)

Habe die bool Variable davor gesetzt und nun verhält sich das Programm 
wieder wie zu erwarten.

Muss morgen mal schauen, was ich in der Klasse  mit den string Typen 
genau mache. Möglicherweise passt da was nicht.

Denke es liegt genau daran!

uli schrieb:
> Habe gerade keine Idee, was dieses reproduzierbare Verhalten verursacht.

Nicht das Programmverhalten ist seltsam, sondern deine 
Erwartungshaltung.

Der Controller wird mit großer Wahrscheinlichkeit tun, was du 
programmiert hast.

Problem habe ich leider noch nicht wirklich gelöst.

Hier ein Ausschnitt meiner Klasse.

--------------------------------------------------
private:

  const QueueHandle_t sma_rx_qh;

  uint8_t TrnEscapedTelegram[200];

  uint8_t TrnEscapedTelegramLength;

  CSMAData oCSMAData;

  CTelegramBody oTelegramBodyReceived;

  CTelegramBody oTelegramBodyToSend;

  bool transmittedAndReceived = false;


  void Fn_Process(void);
----------------------------------------------------

Also, wenn ich "transmittedAndReceived" über
"CTelegramBody oTelegramBodyToSend;"
setze, dann stimmt das Programmverhalten.
Ebenso, wenn ich
"CTelegramBody oTelegramBodyReceived;" und
"CTelegramBody oTelegramBodyToSend;" in den Zeilen gegeneinander tausche 
und "transmittedAndReceived" in die Zeile dazwischen setze.

Wenn ich das wie oben lasse, dann enthält die Variable 
"transmittedAndReceived" nicht false sondern 200.

Denke, dass Array "TrnEscapedTelegram[200]" ist hier deklariert und 
sollte auch 200 Felder im statischen Speicher groß sein.

https://www.youtube.com/watch?v=x40XnMGI75M

Aha.....kan ich die Stackgröße irgendwie selber festlegen?

uli schrieb:
> Habe die bool Variable davor gesetzt und nun verhält sich das Programm
> wieder wie zu erwarten.

uli schrieb:
> Hier ein Ausschnitt meiner Klasse.

uli schrieb:
> Also, wenn ich "transmittedAndReceived" über
> "CTelegramBody oTelegramBodyToSend;"
> setze, dann stimmt das Programmverhalten.
> Ebenso, wenn ich
> "CTelegramBody oTelegramBodyReceived;" und
> "CTelegramBody oTelegramBodyToSend;" in den Zeilen gegeneinander tausche
> und "transmittedAndReceived" in die Zeile dazwischen setze.
>
> Wenn ich das wie oben lasse, dann enthält die Variable
> "transmittedAndReceived" nicht false sondern 200.
>
> Denke, dass Array "TrnEscapedTelegram[200]" ist hier deklariert und
> sollte auch 200 Felder im statischen Speicher groß sein.

Ja - oder auch nein.

Da keiner hier im Forum Dein Programm kennt ist nur vorstehende Aussage 
möglich.

uli schrieb:
> Youtube-Video "Ich brauche mehr Details"
>
> Aha.....kan ich die Stackgröße irgendwie selber festlegen?

Kenne deinen Prozessor nicht, aber das Fehlerbild.

Typische Ursachen:
1. Stack Heap Kollision
2. Zeiger, welcher in die Wiese zeigen
3. Array Grenzen Überschreitung

Tipp:
Der Fehler ist nicht da, wo du ihn suchst
(denn dann hättest du ihn schon).
Der Fehler steckt da, wo du ihn nie vermuten würdest.
(darum zeigst du auch völlig unwichtigen Code)
Er steckt an der Stelle, wo zu zuletzt suchst.

Jobst M. schrieb:
> Aber eigentlich helfen da keine Details mehr. Die Details schweben schon
> singend am Abendhimmel.

Na, dann kannst Du das ja sicherlich allen hier ausführlich erklären - 
ich bin gespannt.

Sagt mal, wenn ich ein Array im header deklariere...
Also so....


*.h

uint8_t TrnEscapedTelegram[200];

Dann sollte doch ein 200er Feld von dem Typ uint8_t im Speicher angelegt 
worden sein... oder?

Und ich kann da von [0] ... bis ... [199] reinschreiben.

Denke ja oder?

Wenn dieses 200er Feld im Speicher angelegt wird, steht da default 0x00 
in jeder Zelle oder was X beliebiges?

Danke und Gruß

Also ich bilde auch eine Instanz von der Klasse .... klaro.

uli schrieb:
> Also ich bilde auch eine Instanz von der Klasse .... klaro

Ich weiß wo Deine Haus wohnt :-)

@ Dieter F.
Das freut mich für dich.

Wenn auch noch deine fachliche Meinung zu meiner Frage hier zum besten 
geben könntest, dann hätte ich mir dieses "Rumgetippe" jetzt sparen 
können.

Wenn aber jetzt auf stur schalten magst, .... bitte, gibt noch andere.
;-)
Legende:
;-) bedeutet Augenzwinker, da locker geschrieben.

Also gebe dir nen Ruck .... kann auch unter falschem Namen sein.

uli schrieb:
> Wenn auch noch deine fachliche Meinung zu meiner Frage hier zum besten
> geben könntest,

Wenn Du mal Deinen Code veröffentlichen würdest (die andere 
Schgreibweise verkneife ich mir hier) ...

uli schrieb:
> kann auch unter falschem Namen sein.

Das ist Dein Metier - nicht da meine ...

uli schrieb:
> .... bitte, gibt noch andere.

Ich könnte dir eine Kristallkugel aufs Auge drücken.
Schon leicht angebraucht, aber mit allen Updates.

Selbst ist der Mann.
Ich kriege das schon hin.

Danke und Gruß

Ja, das schaffst du!

Und dann wirst du auch erkennen, dass du uns keine Chance gegeben hast.

was ist CTelegramBody? Wo und wie wird oTelegramBodyToSend initialisiert 
bzw. geschrieben? Da schreibt möglicherweise jemand zu viel.

uli schrieb:
> Selbst ist der Mann.
> Ich kriege das schon hin.

Schwaller :-)

class CTelegramBody {
public:
  CTelegramBody();
  virtual ~CTelegramBody();

  uint8_t    StartByte;
  uint8_t    Adress;
  uint8_t    Control;
  uint16_t   Protokol;
  uint16_t   Quelle;
  uint16_t   Ziel;
  uint8_t    Ctrl;
  uint8_t    PktCnt;
  uint8_t    Cmd;
  uint8_t    Data[200];
  uint8_t    DataBytes;
  uint16_t   CRC16;
  uint8_t    StopByte;

};

Declaration in Header CTelegramBody.h siehe oben.

Implementiert in CTelegramBody.cpp ist nichts. Nur Constructor und 
Destructor.


In CTelegram.h habe ich dies drinnen. In der dargestellten Reihenfolge.
Nehme ich "bool transmittedAndReceived = false;" zwei Zeilen höher, hat 
die
transmittedAndReceived den Wert false.
So wie dargestellt hat "transmittedAndReceived" 200.

CTelegramBody oTelegramBodyToSend;
bool transmittedAndReceived = false;

Das Data[200] Array endet an der Adresse 0x2001ffd5
transmittedAndReceived hat die Adresse 0x2001ffdc.

Weiterhin hältst du die fehlerhafte Stelle geheim.
Offensichtlich sogar vor dir selber.

Naja, ich glaube, die Fehlersuche wird sich noch etwas strecken....

uli schrieb:
> Declaration in Header CTelegramBody.h siehe oben.
>
> ...
>
> Das Data[200] Array endet an der Adresse 0x2001ffd5
> transmittedAndReceived hat die Adresse 0x2001ffdc.

Dieter F. schrieb:
> Schwaller :-)

Sorry - ich musste reduzieren - macht aber nichts :-)

Was soll das mit dem Array zu tun haben? Offenbar ist diese 
bool-variable ja ganz wo anders.

Abgesehen davon, warum ist der dtor virtuell?

Wenn sich das Fehlerbild abhängig vom Layout der Klasse ändert dann 
schreibt irgendwer irgendwas out of bound(s). Ohne den Code zu sehen 
kann man nicht sagen was.

Für die liebe Fan Gemeinde, sei mal so viel mitgeteilt....


ich benutze freeRTOS -neu- und die Methode "Fn_Process(void)" wird vom 
Scheduler des OS nun vereinfacht, permanent aufgerufen. Es gibt keine 
anderen Tasks.

Habe da alles herausgenommen, was zum Eingrenzen des Problems nicht 
notwendig ist. Ergebnis ist unten.


Und nun das für mich unverständliche:
Wenn ich hier beim Debuggen (F5-Step Into) also single Step nutze, ist 
alles wie zu erwarten. "transmittedAndReceived" ist immer auf false, da 
so im header initialisiert.

Wenn ich aber (F8-Resume) also Run until Breakpoint nutze, dann zeigt 
mir
die "Watch Expression" Liste die 200 in "transmittedAndReceived" und 
dies führt dazu, dass in den If Block hineingegangen wird.

Es passt bei (F5-Step Into) und bei (F6-Step Over)
Es passn nicht bei (F7-Step Return) und bei (F8-Resume)

???
Morgen versuche ich das mal mit dem Atollic True Studio oder gebe die 
Variable über die Serielle Schnittstelle aus.

Eure Meinung dazu interessiert mich aber.


void CTelegram::Fn_Process(void)
{


  uint8_t count = 0;

  for(;;)
  {


*     if(transmittedAndReceived == true)  // Hier habe ich ein 
Breakpoint
      {
  count+=1;

      }
      count+=2;


  }
}

Habe nun etwas herumgetüftelt......

Kurz wichtige Quellcodestellen:

So geht es nicht...
----------------------------------------------------------
void TaskScheduler(void)
{
  :
  :
  CTelegram oCTelegram(sma_rx_qh);
  :
  :
  xTaskCreate(  oCTelegram.Fn_Thread,
          (const char*)"t3",
    1000,
    &oCTelegram,
    2,
    NULL
       );

  vTaskStartScheduler();

  for(;;)
  {
    // Should never reached.
  }
}

Implementierungen in CTelegram.cpp

void CTelegram::Fn_Thread(void* pvParameters)
{
  static_cast<CTelegram*> (pvParameters)->Fn_Process();
}

void CTelegram::Fn_Process(void)
{

  uint8_t count = 0;

  for(;;)
  {


*   if(transmittedAndReceived == true)  // Hier habe ich ein Breakpoint
    {
      count+=1;

    }
    count+=2;
  }
}

----------------------------------------------------------
Vor dieser Zeile
static_cast<CTelegram*> (pvParameters)->Fn_Process();
ist die Variable "transmittedAndReceived" false, was stimmt.
Single Step ... also nach dieser Zeile
static_cast<CTelegram*> (pvParameters)->Fn_Process();
ist die Variable "transmittedAndReceived" irgendwas, was so nicht 
gewollt ist..
Alles andere Verhalten war OK.





So tut es soweit...
----------------------------------------------------------
CTelegram *oCTelegram = nullptr;

void TaskScheduler(void)
{
  :
  :
  oCTelegram = new CTelegram(sma_rx_qh);
  :
  :
  xTaskCreate(  oCTelegram->Fn_Thread,
          (const char*)"t3",
    1000,
    oCTelegram,
    2,
    NULL
       );

  vTaskStartScheduler();

  for(;;)
  {
    // Should never reached.
  }
}


Implementierungen in CTelegram.cpp

void CTelegram::Fn_Thread(void* pvParameters)
{
  static_cast<CTelegram*> (pvParameters)->Fn_Process();
}

void CTelegram::Fn_Process(void)
{

  uint8_t count = 0;

  for(;;)
  {


*   if(transmittedAndReceived == true)  // Hier habe ich ein Breakpoint
    {
      count+=1;

    }
    count+=2;
  }
}

----------------------------------------------------------

Vor dieser Zeile
static_cast<CTelegram*> (pvParameters)->Fn_Process();
ist die Variable "transmittedAndReceived" false, was stimmt.
Single Step ... also nach dieser Zeile
static_cast<CTelegram*> (pvParameters)->Fn_Process();
ist die Variable "transmittedAndReceived" false, was stimmt.
Alles andere Verhalten ist OK.


Ich bin erstmal happy das das tut und sofern mir hier keiner sagen mag 
oder kann, wieso das so war, werde ich morgen mal selber näher darüber 
nachgrübeln.


Bin noch nicht so vertraut mit freeRTOS und C++.
Aber C++ ist nicht nur gemein sondern Hundsgemein.

sorry .... aber worin genau liegt die Verarschung???

Ich hatte Fragen und es gab Antworten.
Und du glaubst doch net das ich meinen ganzen Source Code hier poste.
Schaut sich doch keine Sau an. Hätte ja eh keinen Sinn gemacht bei dem 
Fehlerbild..... wie auch jemand meinte, da kann von ganz anderer Stelle 
was nicht passen ..... was ja auch der Fall war.
Zudem haben die Anstöße der Comumnity doch gefruchtet.

Meine letzte Frage würde mich immer noch interessieren.

Nur das wir uns nicht falsch verstehen....
Ich bin in C++ und freeRTOS ein Anfänger und die Rückmeldungen 
interessieren mich um mein Halbwissen da auszubauen.

Offenbar ist aber nicht klar was das eigentliche Problem war und obs 
wirklich nachhaltig behoben ist. Vermutlich ist der out-of-bounds 
Zugriff noch immer vorhanden und radiert potentiell in Zukunft eine 
andere Datenstruktur aus.


Für zukünftige Fragestellungen:

* Weiterhin Salamitaktik verwenden und Infos nur scheibenweise 
herausrücken. Auch dann immer nur das allernotwendigste sagen, 
unwichtige und nebensächliche Details wie z.B. Platform, (RT)OS, 
Compiler, Programmiersprache, Warnings und Compile-Fehler und anderes 
nicht erwähnen, das lenkt nur vom eigentlichen Problem ab.

* Programme möglichst nicht als Quellcode ins Forum einstellen sondern 
mit möglichst blumiger und mit vielen Adjektiven ausgeschmückter Prosa 
beschreiben.

* Wenn schon Quellcode verwendet werden muss dann darauf achten dass er 
syntaktisch inkorrekt ist, z.B. alle schliessenden Klammern am Schluss 
weglassen; auf keinen Fall darf das Problem auf eine einzige 
kompilierbare Datei zusammengekürzt dargestellt werden. Verwendung von 
Auszeichnung für Quellcode der Foren-Software vermeiden, das stört durch 
die ruppige Unterbrechung im Grauwert den Lesefluss der Prosa.

* Quellcode von Programmen am besten gleich verschlüsselt schreiben, 
Struktur und Konsistenz bei Namen von Eigenschaften, Klassen, Methoden 
schon im Ansatz vermeiden. Einrückungen verschwenden nur Speicherplatz.

Na ja, du schreibst hier offensichtlich mehr in das feld buf als dieses 
speicher vom compiler zugewiesen bekommen hat.

Erkennt das nicht der compiler?

Ich kann nahezu ausschließen, das ich sowas in meinem selbst 
geschriebenen source  habe.

Habe freeRros komplett raus genommen und da hat alles gepasst.
FreeRtos rein in den zwei varianten wie oben zu sehen und konnte den 
fehler mit der einen nicht mehr herbeiführen. Mit der anderen immer.

Sieht so aus als habe ich die freertos funktion xtaskcreate nicht 
richtig bedient.

Also möglicherweise kann wer meine zwei varianten erläutern und den 
bestätigen, das die eine variante zu solchem fehlverhalten führen kann.

Man sieht ja wo und wie ich die objekte erzeuge.
Einmal wird das im fehlerfall meiner meinung nach auf dem stack 
angelegt?? Denke ich.
Und das andere mal auf dem heap.

Ansonsten übergebe ich der funktion noch die adresse auf das objekt 
oCTelegram und mache dann einen typcast im Fn_Thread da freeRtos das mit 
c++ nicht auf die reihe bekommt.

Nachtrag...
Der einzige unterschied liegt ja darin, das ich das objekt oCTelegram 
unterschiedlich erzeuge.

Möglicherweise lag da der fehler.
Deswegen der post und das könnte ja bewerzet werden.
Wenn jemand erfahrenes sagt das passt soweit alles, dann muss ich weiter 
suchen.

Setz doch einfach einen Watchpoint auf die Variable. Dann hält der 
Debugger das Programm an, sobald auf die Speicherstelle geschrieben 
wird.

Eric B.
Tipp am rande. Soltest mal dein feeling checken lassen.

Also ich hab 128kByte ram. 500kByte flash.

Default eingestellt war:
Heap 512 byte
Stack 1024 byte.

Habe das nun vervierfacht.
Heap    800h     2048dez
Stack 1000h     4096dez

Liegt das objekt auf dem stack schlägt es immer noch fehl liegt es auf 
dem heap geht es.
Siehe oben variante 1 und 2.
Auch wenn ich Stack auf 8000h setze geht es mit variante 1 nicht.

Auch wenn ich den parameter, für den task stack, der xCreateTask 
funktion anschließend auf 2000dez setze, .....nada.....
Gleiches verhalten der variante 1.

Zu wenig stack dürfte ausgeschlossen sein.

Und CTelegram hat zwar einen buffer von 200 Byte und ich habe von der 
klasse 2 objekte im thread und dann lass nochmal 400 byte dazukommen.
Die 1k stack werde ich nie benötigen.
Stack wird ja nur benötigt, tja .... wann eigentlich genau.... wenn 
variablen innerhalb einer geschweiften klammer angelegt werden.
Also
{
  int a = 0
}
Läge auf dem stack.
Beim verlassen dieser klammer ist die variable nicht mehr gültig und 
nicht mehr auf dem stack.

Wie ich den watchpoint setzen soll, da bin ich noch dran.

Ansonsten sehe ich ja beim single Step was passiert und habe das oben ja 
geschrieben.

So geht es nicht...
----------------------------------------------------------


void TaskScheduler(void)
{
  :
  :
  CTelegram oCTelegram(sma_rx_qh);
  :
  :
  xTaskCreate(  oCTelegram.Fn_Thread,
                (const char*)"t3",
                1000,
                &oCTelegram,
                2,
                NULL
             );

  vTaskStartScheduler();

  for(;;)
  {
    // Should never reached.
  }
}



Implementierungen in CTelegram.cpp

void CTelegram::Fn_Thread(void* pvParameters)
{
  HIER PASSIERT WAS MIT "transmittedAndReceived"########
  static_cast<CTelegram*> (pvParameters)->Fn_Process();
  WAS KOMISCH IST ######################################
}

void CTelegram::Fn_Process(void)
{

  uint8_t count = 0;

  for(;;)
  {


*   if(transmittedAndReceived == true)  // Hier habe ich ein Breakpoint
    {
      count+=1;

    }
    count+=2;
  }
}
----------------------------------------------------------
Vor dieser Zeile
static_cast<CTelegram*> (pvParameters)->Fn_Process();
ist die Variable "transmittedAndReceived" false, was stimmt.
NUR SINGLE STEP und kein Schritt weiter  ... also nach dieser Zeile
static_cast<CTelegram*> (pvParameters)->Fn_Process();
ist die Variable "transmittedAndReceived" irgendwas (200), was so nicht
gewollt ist..
Alles andere Verhalten war OK.

Also, ich kenne ja die Stelle, wo das Verbiegen von 
"transmittedAndReceived" zumindest für mich passiert.

Dies ist die Variante 1. Variante 2 mit der es Funktioniert ist auch 
oben.
Daher meine Vermutung, dass ich freeRtos mit Variante 1 nicht richtig 
bedient habe.

Hierzu hat sich leider noch niemand geäußert.

uli schrieb:
> Hierzu hat sich leider noch niemand geäußert.

Doch, die gleichlautende Vermutung ist, dass der Fehler im nicht 
gezeigten Code liegt, einmal die Variable "transmittedAndReceived" (sic) 
überschreibt und ein andermal irgendwas anderes, was derzeit offenbar 
ohne negative Konsequenz ist.

Eh Axel W. Ich muss mich grad beherrschen.
Wenn ich das alles durchscrolle, kam von dir nur bullshit.

NUN FÜR DICH.

GEHE  AB HIER ZU MEINEM LETZTEN BEITRAG UND LESE IHN.
DORT STEHT DOCH EINDEUTIG DASS VOR DEM AUSFÜHREN VON

static_cast<CTelegram*> (pvParameters)->Fn_Process();

ALLES OK IST UND NACH NUR DIESER ANWEISUNG DIE BESAGTE BOOL VARIABLE

transmittedAndReceived

EINEN ANDEREN WERT HAT.

DER TYPECAST IST OK..... DA DIE FUNKTION

Fn_Process()

ANGESPRUNGEN WIRD.

UND NUN SAGE ER MIR WAS SICH DA IM HINTERGRUND VON MIR UNBEMERKT 
ÜBERSCHREIBEN SOLL?

ALLEN RELEVANTEN SOURCECODE HAT ER.
ERKLÄR MIR MAL DEN UNTERSCHIED DER ZWEI VARIANTEN.

Ein unbemerktes überschreiben von mir schliesse ich nahezu aus. So viel 
quellcode habe ich noch nicht erstellt.

uli schrieb:
> static_cast<CTelegram*> (pvParameters)->Fn_Process();
>
> ALLES OK IST UND NACH NUR DIESER ANWEISUNG DIE BESAGTE BOOL VARIABLE

Fn_Process von oben beinhaltet eine Endlosschleife, da kann man also 
kaum drübersteppen.

Habe ja oben geschrieben, dass ich mehr als genug Stack eingestellt 
habe.
Auch dem freeRtos Thread habe ich mit 2000Byte mehr als genug Stack 
gegeben.

Wenn ich das Objekt oCTelegram auf dem Heap anlege, dann ist alles OK.

HEAP

CTelegram *oCTelegram = nullptr;

void TaskScheduler(void)
{

  const uint32_t QUEUE_LENGTH = 1;

  const uint32_t QUEUE_ITEM_SIZE = sizeof(STC_MSG_TELEGRAM*);

  qh = xQueueCreate(QUEUE_LENGTH, QUEUE_ITEM_SIZE);

  sma_rx_qh = xQueueCreate(QUEUE_LENGTH, QUEUE_ITEM_SIZE);

  oCTelegram = new CTelegram(sma_rx_qh);  ################

  xTaskCreate(  oCTelegram->Fn_Thread,
            (const char*)"t3",
          2000,
          oCTelegram,
          2,
          NULL
        );

  vTaskStartScheduler();

  for(;;)
  {
    // Should never reached.
  }

}






Version mit STACK .... der besagte Fehler


void TaskScheduler(void)
{

  const uint32_t QUEUE_LENGTH = 1;

  const uint32_t QUEUE_ITEM_SIZE = sizeof(STC_MSG_TELEGRAM*);

  qh = xQueueCreate(QUEUE_LENGTH, QUEUE_ITEM_SIZE);

  sma_rx_qh = xQueueCreate(QUEUE_LENGTH, QUEUE_ITEM_SIZE);

  CTelegram oCTelegram(sma_rx_qh);  #####################

  xTaskCreate(  oCTelegram.Fn_Thread,
         (const char*)"t3",
          2000,
    &oCTelegram,
          2,
    NULL
       );

  vTaskStartScheduler();

  for(;;)
  {
    // Should never reached.
  }

}






Version mit RAM geht auch.

QueueHandle_t sma_rx_qh = xyz;    //Beispiel
CTelegram oCTelegram(sma_rx_qh);  #### Modulglobal #######


void TaskScheduler(void)
{

  const uint32_t QUEUE_LENGTH = 1;

  const uint32_t QUEUE_ITEM_SIZE = sizeof(STC_MSG_TELEGRAM*);

  qh = xQueueCreate(QUEUE_LENGTH, QUEUE_ITEM_SIZE);

  sma_rx_qh = xQueueCreate(QUEUE_LENGTH, QUEUE_ITEM_SIZE);

  xTaskCreate(  oCTelegram.Fn_Thread,
         (const char*)"t3",
          2000,
    &oCTelegram,
          2,
    NULL
       );

  vTaskStartScheduler();

  for(;;)
  {
    // Should never reached.
  }

}


*Der Queue übergebe ich nur einen Zeiger.
*Stack mehr als genug eingestellt
*Vermutlich (waage) bediene ich in der Stack Version FreeRtos nicht
 richtig. Das ist mit C geschrieben und ich werkel hier mit C++ herum.


CTelegram sieht so aus.

--------------------------------------------------
private:

  const QueueHandle_t sma_rx_qh;

  uint8_t TrnEscapedTelegram[200];

  uint8_t TrnEscapedTelegramLength;

  CSMAData oCSMAData;

  CTelegramBody oTelegramBodyReceived;

  CTelegramBody oTelegramBodyToSend;

  bool transmittedAndReceived = false;


  void Fn_Process(void);
----------------------------------------------------


Ich verabschiede mich nun und konzentriere mich auf die Version die 
läuft.
Ist private Beschäftigung und das Wissen über C++ freeRtos ist im 
entstehen.