ich hoffe, dass ich die Sprache richtig als C/Cpp interpretiert habe .. bin mir aber da noch nicht mal so sicher ^^. Dennoch bräuchte ich hilfe beim verstehen des Quellcodes. Dieser ist für ein Gerät. Daten werden von diesem Gerät per HEX an den PC weiter gegeben, dort sollen sie verarbeitet werden und in anderer Form zurück gegeben werden. Diese Funktion ist ursprünglich jedoch nicht vorgesehen gewesen (leider).

uword calc_ampoule_chksum( mem_amp_entry_t* ampoule_data )
{
  ubyte *p;
  uword chksum;

  chksum = 0;
  for(p=(ubyte*) ampoule_data;
      p<(ubyte*) &(ampoule_data->chksum); p++) {
    chksum += *p;
  }
  return chksum;
}

Hier wird eine checksum berechnet. Jedoch verstehe ich diesen Algorythmus nicht so wirklich. Vor allem die passage " p<(ubyte*) &(ampoule_data->chksum)". Wie funktioniert diese Schleife? Und was wird in checksum geschrieben. (ampule_data sind Daten ... also die werden einfach generiert durch einlesen).

Vielen Dank schon mal und lieben Gruß
GnR

(tschuldigung für alle Rechtschreibfehler)

p=(ubyte*) ampoule_data; // Weise p den Wert von ampoule_data (die Anfangsadresse des hier betrachteten Objekts) zu

p<(ubyte*) &(ampoule_data->chksum);  // Solange p kleiner ist als die Adresse des Objektmembers chksum

p++     // Setze p auf das nächste Byte des Objekts

Selbst in C ist dies höchst gewagt und kann an unzähligen Stellen schiefgehen, in C++ ist so gut wie sicher, dass dies explodiert. Es kann unter gewissen Umständen mit genau bekanntem Compiler und Compilereinstellungen etwas sinnvolles rauskommen, aber kleinste Änderungen am System hätten fatale Auswirkungen, die man sogar nicht einmal sofort bemerken würde!

P.S.: C und C++ sind zwei unterschiedliche Sprachen!

Eine Amp inner HEX sieht folgendermaßen aus:

41 00 22 4E 00 00 (ab hier geht der eigentliche Datensatz los) 51 57 45 52 54 5A 55 49 4F 50 ... (viele Nullen) ... D9 03

Ich muss nur das ganze jetzt auf dem PC Verarbeiten ... da hab ich dann jedoch HEX werte. Muss ich diese erst einmal in Bytes umwandeln !? oder wie kann ich das am besten machen?

Eine Amp inner HEX sieht folgendermaßen aus:

41 00 22 4E 00 00 (ab hier geht der eigentliche Datensatz los) 51 57 45 52 54 5A 55 49 4F 50 ... (viele Nullen) ... D9 03

Du hast da direkt eine Textdatei vorliegen, die die Hexadezimalwerte in Textform enthält?

... und da das auf einen µC geschrieben wird, wird es denke ich mal C sein

Das hindert niemanden, trotzdem portabel zu programmieren.

{
  unsigned short chksum=0;
  size_t x = offsetof(mem_amp_entry_t,chksum);
  unsigned char *p=ampoule_data;
  while( x-- )
    chksum+=*p++;

  return chksum;
}

GnR1993 schrieb:

Ich muss nur das ganze jetzt auf dem PC Verarbeiten ... da hab ich dann jedoch HEX werte. Muss ich diese erst einmal in Bytes umwandeln !?

Natürlich nicht.
Sofern auf beiden Systemen/Compilern CHAR_BIT gleich ist, sollte es kein Problem geben.
Es muss aber auch das Alignment/struct padding zwischen PC und μC übereinstimmen, oder du setzt es (bei der struct Deklaration) explizit auf 1 (d.h. keine struct-Paddingbytes), das geht nicht portabel aber viele Compiler bieten dies an.

[...]
Du hast da direkt eine Textdatei vorliegen, die die Hexadezimalwerte in Textform enthält?

jo ... die wird so auf den PC übertragen ... die letzten 4 Ziffern (D903) sind vermutlich die Checksum ^^

Wutz schrieb:

GnR1993 schrieb:

... und da das auf einen µC geschrieben wird, wird es denke ich mal C sein

Das hindert niemanden, trotzdem portabel zu programmieren.

{
  unsigned short chksum=0;
  size_t x = offsetof(mem_amp_entry_t,chksum);
  unsigned char *p=ampoule_data;
  while( x-- )
    chksum+=*p++;

  return chksum;
}

GnR1993 schrieb:

Ich muss nur das ganze jetzt auf dem PC Verarbeiten ... da hab ich dann jedoch HEX werte. Muss ich diese erst einmal in Bytes umwandeln !?

Natürlich nicht.
Sofern auf beiden Systemen/Compilern CHAR_BIT gleich ist, sollte es kein Problem geben.
Es muss aber auch das Alignment/struct padding zwischen PC und μC übereinstimmen, oder du setzt es (bei der struct Deklaration) explizit auf 1 (d.h. keine struct-Paddingbytes), das geht nicht portabel aber viele Compiler bieten dies an.

Öhm .. ich versteh nur Bahnhof .. Sorry ... danke schon mal ^^ aber danke ^^ die Software wurde vor längerer zeit programmiert ..und die umzuschreiben wäre nicht praktikabel! ... wie kann ich das denn auf dem PC am besten realisieren? .. ohne etwas in der SW zu ändern oder den Compiler zu ändern? .. habe ja schon die HEX und die Funktioniert (bidirektionale Übertagung) .. die soll halt nur geändert werden. Dafür muss ich jedoch eine neue Checksum berechnen

LG

Das hindert niemanden, trotzdem portabel zu programmieren.

{
  unsigned short chksum=0;
  size_t x = offsetof(mem_amp_entry_t,chksum);
  unsigned char *p=ampoule_data;
  while( x-- )
    chksum+=*p++;

  return chksum;
}

Was ist daran portabel?

Wutz schrieb:

Das hindert niemanden, trotzdem portabel zu programmieren.

{
  unsigned short chksum=0;
  size_t x = offsetof(mem_amp_entry_t,chksum);
  unsigned char *p=ampoule_data;
  while( x-- )
    chksum+=*p++;

  return chksum;
}

Was ist daran portabel?

ICh hab mal eine Frage. Vor einer Weile hab ich gelesen:

N3337 9.2, Klausel 14 schrieb:

Implementation alignment requirements might
cause two adjacent members not to be allocated immediately after each other;

Also definiert keiner, an welcher Stelle im Speicher relativ zur Adresse einer Instanz von mem_amp_entry_t chksum steht. Heißt das nicht, dass auch nicht definiert ist, welches Ergebnis bei der Aufsummierung herauskommt?

ICh hab mal eine Frage. Vor einer Weile hab ich gelesen:

N3337 9.2, Klausel 14 schrieb:

Implementation alignment requirements might
cause two adjacent members not to be allocated immediately after each other;

Also definiert keiner, an welcher Stelle im Speicher relativ zur Adresse einer Instanz von mem_amp_entry_t chksum steht. Heißt das nicht, dass auch nicht definiert ist, welches Ergebnis bei der Aufsummierung herauskommt?

Ich bin mir nicht sicher, ob du das richtige meinst. Es ist durchaus definiert, an wievielter Stelle checksum und auch alle anderen Member kommen. Jedoch ist undefiniert, ob dazwischen nicht noch irgendwas anderes (=Datenmüll) steht. Und ja: Wenn hier noch irgendwas anderes zwischen den Membern stehen sollte, dann ist das Ergebnis der Rechnung auch Müll. Falls Padding unterdrückt wurde (ein verbreitetes Compilerfeature), dann ist das Ergebnis durchaus halbwegs definiert.

durchaus halbwegs

Es ist durchaus definiert, an wievielter Stelle checksum

Das ist mir klar, ich meinte dass hier:

0x351368f Adresse der Instanz
...
0x351369e Ist definiert, ob *hier* der Member xyz beginnt? Nein, also kann das aufsummieren aller zwischenliegenden Bytes auch keinen Sinn machen, oder?

Ach ja ... was ich vielleicht hätte sagen sollen:
es handelt sich hier um einen S-Record ... hilft das was?

Also hab am anfang der Zeile:
S38540C00080

und am ende halt meine S-Record Checksum ... hmmm

bin atm etwas überfragt ^^ bin noch kein so guter Programmierer! (na ja ... eher Hobby level)

Hmm, danke schon mal .. aber heißt ja dann mehr oder weniger, dass es nicht möglich ist, oder?

Du kannst den Code in deinem ersten Beitrag problemlos nachmachen. Bloß dieser war falsch und wird in vielen Fällen nicht funktionieren. Wenn er jedoch funktioniert hat, dann wird auch die Nachmache funktionieren.

Das heißt ja, dass:

p=(ubyte*) ampoule_data; // Weise p den Wert von ampoule_data (die Anfangsadresse des hier betrachteten Objekts) zu

(SeppJ) so viel Bedeutet, wie den Wert, den dieses Objekt an der Stelle hat, und nicht den wert der Adresse also Adresse XY im Speicher, oder? ... wie gesagt: hobby programmierer