default von Switch wird nicht abgearbeitt

[Pier S. (bigpier)]

Hallo Experten,
bin wider mal mit meinem Latein am Ende.
Habe folgenden Code und verstehe nicht warum die default Marke meines 
Switch Blockes nicht ausgeführt wird. Jedenfalls sagt das AvrStudio beim 
erstellen eines bookmark das dieser Teil vom Code der Optimierung zum 
Opfergefallen ist.

void RxProt(volatile uint8_t input)
{
  extern protoIn Proto[2];
  static uint8_t pos;
  static uint8_t error;
  
  extern volatile uint8_t protoflag;
  static uint8_t *ptr;

  switch(pos)
    {
        default:// recive
          if (input==START)
      {  
        Proto[0].start= input;
        Proto[1].start= input;
        pos++;
          }
          break;
    case 1:
        
      Proto[0].len= input;
      Proto[1].len= input;
      pos++;
      break;
    case 2:
      pos++;
      switch(input)
      {
        case 1:
          ptr = &Proto[0];
          protoflag |= (1<<RxCh1);
          Proto[0].adress= input;
          break;
        case 2:
          ptr = &Proto[1];
          protoflag |= (1<<RxCh2);
          Proto[1].adress= input;
          break;
        default:
          pos=0;
          break;
      }
      break;
    //case 1:
    //case 2:
        case 3:
    case 4:
    case 5:
    case 6:
    case 7:
    case 8:
    case 9:
    case 10:
    case 11:
    case 12:
    case 13:
      case 14:    
      *(ptr+pos )= input;
      pos++;
      break;
    case 15:
      *(ptr+pos )= input;
      pos++;
      //protoflag |= (1<<RxComp);  
      //t= CalcCRC16(dataRX,15);
      if (CalcCRC16(ptr,15)!=0)//CalcCRC16(dataRX,15)
      {
        error++;
        pos=0;
      }
      else
      {
        pos=0;
        protoflag |= (1<<RxComp);  
        protoflag |= (1<<RxCh1);  
        RxLedPort ^= (1<<RxLed);    
      }
  }
}

Ich spreche vom zweitem Switch Block.
das input kommt vom Empfangsinterrupt.
Die Funktion RxProt wird auch im Empfangsinterrupt der Uart aufgerufen

Kann mir jemand auf die Sprünge helfen.
Wenn ich die Optimierung ausschalte dann Funktioniert das Ganze.
Ich habe zwar auf volatile gedacht aber leider kriege ich es nicht hin.

Vielen Dank für Eure Hilfe

Peter

[Noname (Gast)]

Aus dem gezeigten Code-Ausschnitt lässt sich die Ursache nicht 
ermitteln.

Reduziere den Code so weit wie möglich, so das er das Problem noch 
zeigt, aber auch kompilierbar ist. Poste ihn als Anhang. Poste auch alle 
Warnings die Du angezeigt bekommst.

[Peter II (Gast)]

Pier S. schrieb:
> Jedenfalls sagt das AvrStudio beim
> erstellen eines bookmark das dieser Teil vom Code der Optimierung zum
> Opfergefallen ist.

das hat estmal nicht zu sagen. Macht denn der code noch was er soll?

[Noname (Gast)]

Ganz allgemein kann man noch hinzufügen, das der Compiler aus Deinem 
Quelltext geschlossen hat, das der Default-Fall nie eintreten kann.
Im allgemeinen gilt dieser Schluss auch. Die Ursache wird also in Deinem 
Code liegen.

[Noname (Gast)]

Ich gehe übrigens davon aus, das Du im List-File nachgeschaut hast und 
gesehen, das der Code für den Default-Fall tatsächlich nicht vorhanden 
ist.

[Pier S. (bigpier)]

Danke für die Antworten.
Der Code ist Funktioniert mit Optimierung nicht mehr.
Fakt ist das die variable input mit Sicherheit nicht immer 1 oder 2 ist.
Input ist ja mit den Daten von der Uart gefühlt kann also von 0 bis 255 
alles beinhalten.
Ich werde vrsuchen den Code zu verkleinern und zu Posten.

Danke für Eure Hilfe
Peter

Ps mit Sicherheit ligt der Fehler bei mir.

[Pier S. (bigpier)]

Noname schrieb:
> Ich gehe übrigens davon aus, das Du im List-File nachgeschaut hast und
> gesehen, das der Code für den Default-Fall tatsächlich nicht vorhanden
> ist.

Ja im List_File kommt die default Marke nicht vor.

Peter

[Noname (Gast)]

>Danke für die Antworten.
Bitte.

>Der Code ist Funktioniert mit Optimierung nicht mehr.
Ein Hinweis, das Du was anderes geschrieben hast, als Du denkst.

>Fakt ist das die variable input mit Sicherheit nicht immer 1 oder 2 ist.
>Input ist ja mit den Daten von der Uart gefühlt kann also von 0 bis 255
>alles beinhalten.
So das sich dann die Frage stellt, warum Du nicht alle 256 Möglichkeiten 
im Switch berücksichtigt hast.
Abgesehen davon, kann es auch durch den Kontrollfluss möglich sein, das 
der Wertebereich an der Stelle des Aufrufs der Funktion eingeschränkt 
ist und der Compiler das aus dem Code statisch analysieren kann. Der 
Eingabewertebereich allein ist nicht entscheidend.

>Ich werde vrsuchen den Code zu verkleinern und zu Posten.
Gut.

>Ps mit Sicherheit ligt der Fehler bei mir.
Nun, "mit Sicherheit" ist vermutlich auch übertrieben, aber er liegt 
wahrscheinlich bei Dir.

[Pier S. (bigpier)]

Noname schrieb:
> So das sich dann die Frage stellt, warum Du nicht alle 256 Möglichkeiten
> im Switch berücksichtigt hast.

Ich möchte ja bei allen andern Daten außer bei 1 und 2 abbrechen indem 
ich pos auf 0 setze.
Also habe ich es in einer gewissen Art und Weise alle Möglichkeiten 
berücksichtigt.

Peter

Hoffe das ich den Code bald soweit habe das ich in Posten kann

[rmf (Gast)]

Bin zwar nicht der C Guru, aber könnte es sein das der Compiler so 
komisch reagiert weil in deinem Case 15 das Break am Ende fehlt ?

gruß Udo

[Noname (Gast)]

@ Pier S.

>Ich möchte ja bei allen andern Daten außer bei 1 und 2 abbrechen indem
>ich pos auf 0 setze.
>Also habe ich es in einer gewissen Art und Weise alle Möglichkeiten
>berücksichtigt.

Ja, das hast Du. Meine Frage war nicht relevant. Ein Irrtum meinerseits.

Es bleibt die Möglichkeit das aus dem Kontrollfluss erkennbar ist, das 
andere Fälle ausser 1 und 2 nicht eintreten können.

[Pier S. (bigpier)]

rmf schrieb:
> Bin zwar nicht der C Guru, aber könnte es sein das der Compiler so
> komisch reagiert weil in deinem Case 15 das Break am Ende fehlt ?
>
> gruß Udo

Ja genau das ist es.
Vielen Vielen Dank

Schönes Wochenende

Peter

[(prx) A. K. (prx)]

Das ergibt keinen Sinn. Hinter dem letzten Fall eines Switch-Statements 
muss kein "break" stehen. Es wegzulassen ist zwar nicht anzuraten, aber 
formal notwendig ist es nicht.

[Noname (Gast)]

Sehe ich auch so. Das fehlende break kann auch nicht bewirken das der 
Code für den Default-Fall in dem untergeordneten switch fehlt.

Da muss irgendein anderes Problem existieren.

[Noname (Gast)]

Sagen wir lieber, das sollte nicht den beobachteten Effekt bewirken. 
Was für einen Compiler verwendest Du? Version?

[Pier S. (bigpier)]

Hallo Leute,
hab mich zu früh gefreut das Problem ist noch vorhanden.

Hier jetzt der Code

Danke und Gruß
Peter

[Karl H. (kbuchegg)]

In deinem Zip-File:

Ist das mit oder ohne Optimierungen compiliert?

Im LSS-File ist der fragliche Code vorhanden und auch die Sprungleiste 
sieht auf den ersten Blick vernünftig aus.


(Es kommt zwar vor, dass Compiler fehlerhaft ausgeliefert werden. Aber 
es ist selten. In >95% aller Fälle hast du den Fehler im Programm selbst 
programmiert. Compilerfehler würd ich für mich erst mal immer 
ausschliessen und den Fehler erst mal im Code suchen)

[Noname (Gast)]

>hab mich zu früh gefreut das Problem ist noch vorhanden.

Ja. Davon sind A.K. und ich ausgegangen.

OK. Code ist vorhanden. Aber ich habe keine Lust das Ganze Gewusel nun 
noch auseinander zu nehmen. Vielleicht ja jemand anders.

Falls sich keiner findet der nicht so faul ist wie ich, reduziere den 
Code soweit, das nur das allernotwendigste vorhanden ist um den Fehler 
reproduzieren zu können. Aber er muss kompilierbar sein.

Was ist eigentlich mit den Warnungen? Keinerlei Warnungen angezeigt?

[Karl H. (kbuchegg)]

Noname schrieb:
>>hab mich zu früh gefreut das Problem ist noch vorhanden.
>
> Ja. Davon sind A.K. und ich ausgegangen.
>
> OK. Code ist vorhanden. Aber ich habe keine Lust das Ganze Gewusel nun
> noch auseinander zu nehmen. Vielleicht ja jemand anders.

Geht mir eigentlich genauso.
Vor allen Dingen dann, wenn ich erst mal das Mischmasch aus 
Tabultor-Einrückungen und Leerzeichen-Einrückungen auseinandersortieren 
und aneinander angleichen muss, um zu sehen ob die { - } Hierarchien 
korrekt sind und mit der vorhandenen Einrückung übereinstimmen.

Ich denke, der fragliche Code wird bei eingeschalteter Optimierung schon 
irgendwo sein. Nur hat der Compiler das eben ein wenig umgestellt, so 
dass er nicht mehr auf den ersten Blick zu finden ist. In a nutshell: 
Ich denke, bei der Suche warum der Code in der optimierten Version nicht 
funktioniert, wird da der falsche Baum angebellt.

[Noname (Gast)]

Karl-Heinz ist da. Dann wird alles gut. :-)

>Im LSS-File ist der fragliche Code vorhanden und auch die Sprungleiste
>sieht auf den ersten Blick vernünftig aus.

Oh je. Da haben wir doch nach gefragt und der TO hat geschrieben, das 
der Code nicht vorhanden ist. 
Beitrag "Re: default von Switch wird nicht abgearbeitt"

[Karl H. (kbuchegg)]

Noname schrieb:
> Karl-Heinz ist da. Dann wird alles gut. :-)

Nicht wirklich. :-)
Ich hab hier auf dem PC kein AVR-Studio bzw. AVR-Gcc und ich hab auch 
keine Lust da extra einen zu installieren (darf ich auch gar nicht). 
Also muss Codeanalyse ran. Die Bereitschaft dazu sinkt aber gewaltig, 
wenn ich erst mal wie ein Wilder umformatieren muss, um überhaupt etwas 
zu sehen.

[Noname (Gast)]

Karl-Heinz schrieb:
>...wird da der falsche Baum angebellt.

Vermutlich. Habe mir nochmal den Eröffnungspost durchgelesen.

>Habe folgenden Code und verstehe nicht warum die default Marke meines
>Switch Blockes nicht ausgeführt wird.

>Jedenfalls sagt das AvrStudio beim
>erstellen eines bookmark das dieser Teil vom Code der Optimierung zum
>Opfergefallen ist.

Das eine hat mit dem anderen nichts zu tun. Durch die Optimierung kann 
es schon sein, das der dahinterliegende Asm-Code irgendwo und noch 
zerfasert herumliegt, so das der Debugger meint er könne die Adresse 
nicht lokalisieren.

Das müsste jetzt nochmal geklärt werden:
1. Funktioniert der Code wirklich nicht.
oder
2. Kann man nur an dem Default keinen Breakpoint (Bookmark ???) setzen.

[(prx) A. K. (prx)]

Karl Heinz Buchegger schrieb:
> Vor allen Dingen dann, wenn ich erst mal das Mischmasch aus
> Tabultor-Einrückungen und Leerzeichen-Einrückungen auseinandersortieren

4er Tabs einstellen, dann passt es.

[Noname (Gast)]

Naja. Zwischendurch werkel ich hier gerade an ner STM32F4-Geschichte 
herum. Habe gerade keine Lust so tief einzusteigen. Am Ende ist es 
ohnehin ein Missverständnis oder ein fehlendes volatile oder ne 
Initialisierung, das/die man schon mal nur per Augenschein sehen kann. 
Aber nicht in dem Verhau eben.

[Pier S. (bigpier)]

Also ich sagte ja das ich auch der Überzeugung bin das der Fehler bei 
mir liegt.

Habe den betreffenden Teil des LSS-File in ein Txt File kopiert und ich 
sehe das Default nicht behandelt.

Werde den Code nochmals versuchen zu verkleinern.

Gruß

Peter

[Pier S. (bigpier)]

Der Code funktioniert mit Optimierung nicht!
Um den Fehler zu finden (Crc ist immer Falsch ) ist mir aufgefallen das 
der Defaultblock nicht erreicht wird.
Hingegen ohne Optimierung geht der Code und es wird auch dieser 
Defaultblock
erreicht.

Gruß

Peter

[Noname (Gast)]

>Also ich sagte ja das ich auch der Überzeugung bin das der Fehler bei
mir liegt.

Ist schon gut. Ist nur die übliche professionelle Brummigkeit. :-) Denk 
Dir nichts dabei.

[Karl H. (kbuchegg)]

Pier S. schrieb:
> Der Code funktioniert mit Optimierung nicht!
> Um den Fehler zu finden (Crc ist immer Falsch ) ist mir aufgefallen das
> der Defaultblock nicht erreicht wird.

Im Debugger?

Das heißt nicht viel. Daran kannst du dich nicht orientieren.
Der Optimizer wird den Code umgestellt haben, so dass ihn der Debugger 
nicht mehr findet.

[Pier S. (bigpier)]

Karl Heinz Buchegger schrieb:
> Im Debugger?
>
> Das heißt nicht viel. Daran kannst du dich nicht orientieren.
> Der Optimizer wird den Code umgestellt haben, so dass ihn der Debugger
> nicht mehr findet.

Ja im Debugger.

Wie soll ich dann weiter vorgehen?

Danke Gruß

Peter

[Johann L. (gjlayde)]

Pier S. schrieb:

> Ich spreche vom zweitem Switch Block.

1) Der 2. switch (input) wird nur in case 2 des äusseren switch (input)
   betreten, d.h. im inneren ist input immer 2.  Ergo: der default-Fall
   wird nie gebraucht, ditto case 1.

2) Mach das volatile am Parameter weg, das ist Käse

3) ptr hat den falschen Typ. Proto[0] ist vom Typ protoIn, &Proto[0]
   demnach vom Typ protoIn* und nicht vom Typ uint8_t*.

4) externe Deklarationen gehören bis auf seltene Ausnahmen in einen
   Header, nicht ins C-Modul wo Inkompatibilitäten nicht auffallen.

5) case 15 fehlt ein break. Ist momentan zwar egal, bei Umstrukturierung
   oder Erweiterung des Codes wirst du dir aber den Wolf suchen.

Ich habe folgenden Code verwendet, weil sonst Deklarationen fehlen:

#include <stdint.h>

#define START 0

typedef struct
{
    uint8_t start;
    uint8_t len;
    uint8_t adress;
} protoIn;

enum { RxLed, RxCh1,  RxCh2, RxComp };

#define RxLedPort *((uint8_t volatile*) 42)

void RxProt (uint8_t input)
{
    extern protoIn Proto[2];
    static uint8_t pos;
    static uint8_t error;

    extern volatile uint8_t protoflag;
    static uint8_t *ptr;

    switch(pos)
    {
        default:// recive
            if (input==START)
            {  
                Proto[0].start= input;
                Proto[1].start= input;
                pos++;
            }
            break;

        case 1:

            Proto[0].len = input;
            Proto[1].len = input;
            pos++;
            break;

        case 2:
            pos++;
            switch (input)
            {
                case 1:
                    ptr = &Proto[0];
                    protoflag |= (1<<RxCh1);
                    Proto[0].adress= input;
                    break;
                case 2:
                    ptr = &Proto[1];
                    protoflag |= (1<<RxCh2);
                    Proto[1].adress= input;
                    break;
                default:
                    pos=0;
                    break;
            }
            break;
        //case 1:
        //case 2:
        case 3:
        case 4:
        case 5:
        case 6:
        case 7:
        case 8:
        case 9:
        case 10:
        case 11:
        case 12:
        case 13:
        case 14:    
            *(ptr+pos )= input;
            pos++;
            break;
        case 15:
            *(ptr+pos )= input;
            pos++;
            //protoflag |= (1<<RxComp);  
            //t= CalcCRC16(dataRX,15);
            if (CalcCRC16(ptr,15)!=0)//CalcCRC16(dataRX,15)
            {
                error++;
                pos=0;
            }
            else
            {
                pos=0;
                protoflag |= (1<<RxComp);  
                protoflag |= (1<<RxCh1);  
                RxLedPort ^= (1<<RxLed);    
            }
    }
}

hm...

Das äussere swicth ist auf pos :-/, da war ich oben zu fix...

Dafür entält der erzeugte Code Instruktionen für den default des inneren 
switch :-))

[Pier S. (bigpier)]

Johann L. schrieb:
> 1) Der 2. switch (input) wird nur in case 2 des äusseren switch (input)
>    betreten, d.h. im inneren ist input immer 2.  Ergo: der default-Fall
>    wird nie gebraucht, ditto case 1.



Der äußere switch hat pos als Parameter also kann input alles möglichen 
Werte haben .

Beim Rest hast du sicher recht werde ich ändern

Danke

Gruß

Peter

[Noname (Gast)]

Hm. Der Code geht ohne Optimierung aber nicht mit.
Guck Dir alle in interrupts benutzten Variablen an ob sie wirklich 
volatile sind.


>1) Der 2. switch (input) wird nur in case 2 des äusseren switch (input)
>   betreten, d.h. im inneren ist input immer 2.  Ergo: der default-Fall
>   wird nie gebraucht, ditto case 1.

Der äussere switch hängt nicht von input ab sondern von pos.

pos ist nicht initialisiert!


Gar keine Warnings?

[Peter II (Gast)]

Noname schrieb:
> pos ist nicht initialisiert!

doch ist es, denn sie ist static

[Karl H. (kbuchegg)]

Pier S. schrieb:

> Wie soll ich dann weiter vorgehen?

Hast du eine Möglichkeit, dir irgendwo Ausgaben machen zu lassen? (LCD, 
noch ne UART)
Wenn ja: Einen kompletten Frame da mal ausgeben lassen und ansehen, was 
du zurückbekommst.
Wenn nein: warum hast du sowas nicht? Programmentwicklung ohne sich auf 
der realen Hardware was ausgeben zu lassen hat immer was von 'Stochern 
im Nebel'

typedef volatile struct // 15 Byte
{  
  uint8_t start;
  uint8_t len;
  uint8_t adress;
  int analog[4] ;
  uint8_t  output ;
  uint8_t crcerror;
  unsigned int crc;
}protoIn;

Welche Aussage hat da der Member crcerror?
Ist das die Rückmeldung vom Gerät, dass deine Anfrage einen CRC-Error 
hatte?

[Johann L. (gjlayde)]

Pier S. schrieb:
> Johann L. schrieb:
>> 1) Der 2. switch (input) wird nur in case 2 des äusseren switch (input)
>>    betreten, d.h. im inneren ist input immer 2.  Ergo: der default-Fall
>>    wird nie gebraucht, ditto case 1.
>
> Der äußere switch hat pos als Parameter also kann input alles möglichen
> Werte haben .

Hab mich schon selbst korrigiert:

Johann L. schrieb:

> Das äussere swicth ist auf pos :-/, da war ich oben zu fix...
>
> Dafür entält der erzeugte Code Instruktionen für den default des inneren
> switch :-))

[Uwe N. (ulegan)]

Der default-Zweig wird auch vom Compiler erzeugt.
Hier der entscheidende Ausschnitt aus dem lss-File.
Der Compiler hat halt eine andere Stelle im Code gefunden, der die 
gleiche Funktion hat.
Das default-Label ist dadurch verlorengegangen, der Code ist aber da.

      switch(input)
     7da:  89 81         ldd  r24, Y+1  ; 0x01
     7dc:  81 30         cpi  r24, 0x01  ; 1
     7de:  21 f0         breq  .+8        ; 0x7e8 <RxProt+0x64>
     7e0:  82 30         cpi  r24, 0x02  ; 2
     7e2:  09 f0         breq  .+2        ; 0x7e6 <RxProt+0x62>
     7e4:  3f c0         rjmp  .+126      ; 0x864 <RxProt+0xe0> Das ist der default
     7e6:  0f c0         rjmp  .+30       ; 0x806 <RxProt+0x82>

   ...
   
      pos=0;
     864:  10 92 b1 01   sts  0x01B1, r1  ;                  in R1 steht wohl immer Null
     868:  10 c0         rjmp  .+32       ; 0x88a <RxProt+0x106>
      }

[Pier S. (bigpier)]

Karl Heinz Buchegger schrieb:
> Hast du eine Möglichkeit, dir irgendwo Ausgaben machen zu lassen?
> Wenn ja: Einen kompletten Frame da mal ausgeben lassen und ansehen, was
> du zurückbekommst.

Ja habe ich und die Daten kommen auch richtig an.Ohne Optimierung ist 
mein Programm ja auch der Meinung das die Daten richtig sind.

Karl Heinz Buchegger schrieb:
> Welche Aussage hat da der Member crcerror?
> Ist das die Rückmeldung vom Gerät, dass deine Anfrage einen CRC-Error
> hatte?

Ja damit sieht man ob die Gegenstelle Fehler beim Empfangen hatte.

[Pier S. (bigpier)]

Uwe Nagel schrieb:
> Der default-Zweig wird auch vom Compiler erzeugt.
> Hier der entscheidende Ausschnitt aus dem lss-File.
> Der Compiler hat halt eine andere Stelle im Code gefunden, der die
> gleiche Funktion hat.
> Das default-Label ist dadurch verlorengegangen, der Code ist aber da.

Also so wie Karl Heinz sagte ich belle den falschen Baum an!

[Karl H. (kbuchegg)]

Pier S. schrieb:
> Karl Heinz Buchegger schrieb:
>> Hast du eine Möglichkeit, dir irgendwo Ausgaben machen zu lassen?
>> Wenn ja: Einen kompletten Frame da mal ausgeben lassen und ansehen, was
>> du zurückbekommst.
>
> Ja habe ich und die Daten kommen auch richtig an.Ohne Optimierung ist
> mein Programm ja auch der Meinung das die Daten richtig sind.

Der Frame den du zurückbekommst ist korrekt? (Ausgeben lassen, sieht das 
plausibel aus?)
Hast du die CRC mal händisch nachgerechnet?

[Karl H. (kbuchegg)]

Andere Frage: Woran merkst du eigentlich, dass 'es nicht funktioniert'. 
Beim Drüberschauen hab ich nichts ausmachen können, das spezifisch auf 
einen CRC Fehler reagiert (ausser der static error Variablen). Du hast 
du noch eine Timeout-Sache inkludiert, kann es sein, dass die anschlägt?

[Pier S. (bigpier)]

Ich merke am RxComp Flag in der main wenn Daten richtig angekommen sind.
Und dieses Flag bleibt mit Optimierung aus.
Die CRC habe ich auch nachgerechnet. Bin ziemlich ratlos.

Gruß

Peter

[Stefan E. (sternst)]

Auf protoflag (in dem auch RxComp liegt) wird sowohl im Main- wie auch 
auch im ISR-Kontext schreibend (bzw. RMW) zugegriffen. Die Main-Zugriffe 
sind jedoch nicht geschützt.

[Johann L. (gjlayde)]

Siehe atomar

[Pier S. (bigpier)]

Stefan Ernst schrieb:
> Auf protoflag (in dem auch RxComp liegt) wird sowohl im Main- wie auch
> auch im ISR-Kontext schreibend (bzw. RMW) zugegriffen. Die Main-Zugriffe
> sind jedoch nicht geschützt.

Ja mache ich so. Aber ich verstehe nicht was das mit meinem Problem zu 
tun hat.
 Bitte um Erklärung


Danke gruß
Peter

[Washington I. (washington_i)]

kann mir jemand erklären warum der default-block von dem einen switch 
ganz oben steht? ich kenn default immer nur gaaanz am schluss.

[(prx) A. K. (prx)]

Der steht vorne, weil er ihn vorne hingeschrieben hat. Dem Compiler ist 
völlig egal, wo der steht. Ob vorne, hinten oder mitten drin.

[Pier S. (bigpier)]

Hallo,
nach einer längeren Pause habe ich wider Zeit gefunden an meinem 
Programm weiter zu machen.
Ich glaube ich mache einen bösen Fehler mit den verwendeten Zeiger.
Ich vermute das ich mir die Daten meines Structur Array zerschieße.

typedef volatile struct // 15 Byte
{  
  uint8_t start;
  uint8_t len;
  uint8_t adress;
  int analog[4] ;
  uint8_t  output ;
  uint8_t crcerror;
  unsigned int crc;
}protoIn;

void RxProt(volatile uint8_t input)
{
  
  static uint8_t pos;
  static uint8_t error;
  
  
  static uint8_t *ptr;

  switch(pos)
    {
        default:// recive
          if (input==START)
      {  
        test[0].start= input;
        test[1].start=input;
        pos++;
          }
          break;
    case 1:
      test[0].len=input;
      test[1].len=input;
      pos++;
      break;
    case 2:
      pos++;
      switch(input)
      {
        case 1:
          ptr = &test[0];
          protoflag |= (1<<RxCh1);
          test[0].adress= input;//Proto[0].adress= input;
          break;
        case 2:
          ptr = &test[1];
          protoflag |= (1<<RxCh2);
          test[1].adress= input;//Proto[1].adress= input;
          break;
        default:
          pos=0;
          break;
      }
      break;
    //case 1:
    //case 2:
        case 3:
    case 4:
    case 5:
    case 6:
    case 7:
    case 8:
    case 9:
    case 10:
    case 11:
    case 12:
    case 13:
      case 14:    
      *(ptr+pos )= input;
      pos++;
      break;
    case 15:
      *(ptr+pos )= input;
      pos++;
      //protoflag |= (1<<RxComp);  
      //t= CalcCRC16(dataRX,15);
      if (CalcCRC16(ptr,15)!=0)//CalcCRC16(dataRX,15)
      {
        error++;
        pos=0;
      }
      else
      {
        pos=0;
        protoflag |= (1<<RxComp);  
        //protoflag |= (1<<RxCh1);  
        RxLedPort ^= (1<<RxLed);    
      }
      break;
  }
}

Ich habe den Teil wo ich mit den Zeigern Arbeite nochmal beigelegt.
Ich hoffe jemand kann mir helfen den Fehler zu finden.

Vielen Dank im voraus

Peter

[Pier S. (bigpier)]

Mann o Mann bin ich blöd die Structur hat 15 Byte und ich zähle munter 
bis 16 und überschreibe mir die Daten vom nächsten Datensatz.

Vielen Dank für Eure Hilfe und Geduld

Peter

[Mark B. (markbrandis)]

Karl Heinz Buchegger schrieb:
> Ich hab hier auf dem PC kein AVR-Studio bzw. AVR-Gcc und ich hab auch
> keine Lust da extra einen zu installieren (darf ich auch gar nicht).

Du darfst keine Software installieren? Das ist als Entwickler doch wohl 
unumgänglich...

Pier S. schrieb:
> Mann o Mann bin ich blöd die Structur hat 15 Byte und ich zähle munter
> bis 16 und überschreibe mir die Daten vom nächsten Datensatz.

Das erinnert mich an einen Fehler, den ich diese Woche bei einem Code 
Review gefunden habe: Jemand deklariert ein
int array[17];
und einige Zeilen weiter unten steht dann:
array[17] = 0;

Da kriegt man schon ein wenig Kopfweh...

[Kiffka (Gast)]

Mark Brandis schrieb:
> Das erinnert mich an einen Fehler, den ich diese Woche bei einem Code
> Review gefunden habe: Jemand deklariert ein
> int array[17];
> und einige Zeilen weiter unten steht dann:
> array[17] = 0;
>
> Da kriegt man schon ein wenig Kopfweh...

... und die "magic numbers" hast du nicht angemeckert?