MAL Wieder "C" Frust

[Siro]

Hallo CEOS,
für mein count Problem habe ich jetzt auch einen anderen Weg genommen,
scheinbar ähnlich deiner Beschreibung.
Ich habe jetzt getrennte Einlese und Auslesezeiger.
Der Empfangs RX-Interrupt benutzt nur "seinen" Einlesezeiger.
Das Hauptprogramm seinen "Auslesezeiger"
Hier kann man nun, um die Anzahl Bytes im RX Puffer zu ermitteln,
ohne Probleme beide Werte voneinander abziehen.
Es spielt nun auch keine Rolle mehr ob es indexe in das Array sind
oder direkt Zeiger auf die entsprechende Pufferpositionen.

rx_count = abs(inPtr-outPtr) // oder auch umgekehrt.

Ein Problem könnte aber immer noch auftauchen,
bei 8 Bit Controllern, wenn er Low und High Byte bei Zugriffen separat tätigt.
also:

inc(LowByte); wenn LowByte = 0 dann inc(HighByte)

Microchip PIC-Code:
incfz rx_count+0 // increment low byte of count, scip next Line if Zeroflag is set
incf rx_count+1 // else increment also the High Byte of count

Eine wasserdichte Software zu schreiben ist eine echte Herausforderung.....
Interrupts sperren mag ich eigentlich überhaupt nicht, ist aber manchmal unumgänglich.
-----
Zu deinem Konstrukt:
Ui, da muss ich erstmal durchblicken....ich analysiere aber noch.
Im Prinzip habe ich es, glaube ich zumindest, verstanden um was es geht.
Bei Dir bildet sich die case Schleife selbständig indem Du die obige Struktur erweiterst.

Etwas ähnliches (ist aber doch um einiges anders) habe ich in meinem Setupmenü gemacht.

/* every menu point has the following structure */
typedef struct
{
  U16 menu_no;             /* displayed menu no */
  U8  flags;               /* 3 flags for User, Service, Internal Setupmode */
  S16 min;                 /* min value of parameter for range check */
  S16 max;                 /* max value of parameter for range check */
  U8  led_code[3];         /* 3 Digit LED Information Text, only 2 digits used */
  U8  lcd_code[20];        /* 20 Digit LCD Information Text, not used at time */
  void (*MenuFunc)();      /* call this function if menu point want to change */
  void (*OnChangeFunc)();  /* maybe call a special function if param changed */
  } TMenuPoint;

/* here is the complete initialized Setup Menu */
const TMenuPoint menu[]={
{ 1,   /* Key Beep Volume Frontpanel Buttons */
  F_USER + F_SERVICE + F_INTERNAL,
  BEEP_MIN_VOL,BEEP_MAX_VOL,
  {SEG_CODE_b,SEG_CODE_0,0},       /* displaycode "b0" */
  "Key Beep            ",
  Setup_VolumeKeyBeep,
  OnChangeBeeper
  },
  
  { 2,   /* Overpressure Beep Volume */
  F_USER + F_SERVICE + F_INTERNAL,
  BEEP_MIN_VOL,BEEP_MAX_VOL,
  {SEG_CODE_b,SEG_CODE_1,0},        /* displaycode "b1" */
  "Overpressure Beep   ",
  Setup_VolumeOverpressureBeep,
  OnChangeBeeper
  },
  
.......

Mein Code ist doch was ganz anderes, stelle ich grad fest, ist auch kaum statisch zu analysieren denke ich...

Ich habe mit Macros noch nicht viel gemacht in "C" hier kann man sich doch Einiges vereinfachen wie ich deinem Code entnehme.
Im PIC Assembler habe ich aber derart viele Macros geschrieben, das es später schon fast wie ein Hochsprache aussah.

Mit Code coverage usw. habe ich auch noch nichts zu tun gehabt. Machst Du solche Tests mit "Tessy" ? oder welche Tools benutzt Du dafür ?



Siro

[Siro]

Ich lese grade über "statische" Codeanalyse und da tauchte folgender Text auf:

Problematiken in "C"
Das wären unter anderem die undefinierte Auswertungsreihenfolge bei arithmetischen Ausdrücken,
compilerabhängige Ergebnisse beim Rechts-Shift von negativen ganzen Zahlen und die undefinierte Bitbreite des Datentyps int.

Nun bin ich doch etwas verunsichert:
Ich benutze ja sehr gerne mal das Shiften in alle Richtungen, zumindest links und rechts...

Das stellt ja ein "erhebliches" Risiko dar, wenn nicht eindeutig festgelegt ist, was der Compiler daraus macht.
Ist natürlich auch etwas problematisch mit dem shiften und abhängig vom Datentyp, wer mal Assembler programmiert hat
weis um die Problematik des Vorzeichenbits. Hier gibt es teilweise unterschiedliche Befehle zum Schieben,
die das Vorzeichen beachten, auffüllen, rotieren usw.

Kann man sich bei "C" darauf verlassen, dass ein Schieben mit "unsigned" immer richtig funktioniert ?
Einen signed, egal welchen Typs, würde ich eh nicht shiften wollen, da das Ergbenis ungewiss...

Durch die "Integer promotion" wird ja generell erstmal alles zum int gecastet und der hat ein Vorzeichen,
Aber selbst diese Aussage stimmt in "C" ja nicht weil:
Bei Bitdefinitionen ist es wiederum compiler spezifisch festgelegt bzw. einstellbar ob es ein signed oder unsigned ist.
Der C-Compiler von IAR Embedded Workbench z.B. interpretiert einen "int" bei Bitdefinitionen vorzeichenlos,
also wie ein "unsigned int" Möchte man eine Bitkombination mit Vorzeichen haben, muss man explizit einen "signed int" benutzen,
was ursprünglich ja der default int wäre(war, ist ?) oder wie auch immer...
Somit gehört in meinen Augen ein "int" als VERBOTEN, da dieser Typ nicht festgelegt ist.
Das habe ich auch schon seit Jahren in meiner Doku entsprechend spezifiziert und benutze ihn auch nicht.
Ein int könnte demnach Alles sein was mindestens 16 Bit hat. Mehr sagt es anscheinend nicht aus.

Na wie dem auch sei, je mehr ich mich mit der C Programmierung beschäftige, umso mehr erkenne ich wie schwierig es ist,
Fehler zu vermeiden. Eine "sinnvolle" statische Codeanalyse erscheint mir auch nicht wirklich sinnvoll, denn
ich müste dem Tool ja erstmal die ganzen "Eigenheiten" meines verwendeten Compilers verraten.

Ich glaube ich kann eure Gedanken lesen
Der Siro meckert nur immer....
Das ist aber nicht so, das sieht nur so aus...
ich beschäftige mich doch recht intensiv mit der Programmierung den Sprachen und deren Eigenheiten
um halt bessere Software zu schreiben, also versteht es bitte nicht falsch.
Ich schöpfe ja auch immer wieder viele neu Informationen von euch und das ist gut so.

Siro