Hilfe bei Quellcode

Belli

ampoule_data scheint eine Datenstruktur zu sein, die unter anderem ein Member namens chksum enthält. In der Schleife werden alle Bytes der Struktur bis zu diesem Member ausschließlich genommen und aufaddiert.

GnR1993

Ja, dass das unterschiedliche sprachen sind, weiß ich auch ^^ ... und da das auf einen µC geschrieben wird, wird es denke ich mal C sein (ist ja eigentlich typisch), war mir nur nicht sicher ... auf dem gerät Funktioniert alles (ich habs auch nicht geschrieben, sondern ein professioneller ^^). 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

SeppJ

Die Frage nach dem Unterschied zwischen Hex und Bytes ist wie die Frage nach dem Unterschied zwischen Arial und einem Buch.

Bashar

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 !? 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?

Wutz

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.

GnR1993

Bashar schrieb:

[...]
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

camper

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?

Sone

camper schrieb:

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?

SeppJ

Sone schrieb:

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.

Caligulaminus

SeppJ schrieb:

durchaus halbwegs

Sone

SeppJ schrieb:

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?

GnR1993

Hmm, danke schon mal .. aber heißt ja dann mehr oder weniger, dass es nicht möglich ist, oder? ... am QT fürs Device kann ich nicht schrauben!

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)

SeppJ

GnR1993 schrieb:

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.

muss ich dafür nicht wissen, an welcher Stelle im Programm das Byte steht? ... oder Verstehe ich das ganze hier gerade Falsch ?

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