LSB Parity Checksumme

[Berserker]

Hi.

Kann mir von euch jemand helfen?
Ich muss von einem HEX-Wert eine Parity berechnen
Beispiel: FFDCH muss DCH ergeben

Ich benötige das für die Steuerung einer Dome-Kamera
In meinem Manual steht was von LSB of FFDCH = DCH.

Wenn jemand eine Idee hat wie man dies Bewerkstelligen kann wäre ich dankbar.

MfG, Ronny

[OldGrumpy]

Also LSB bedeutet einfach nur "das Byte am unteren Ende" einer Zahl die sich über mehrere Bytes erstreckt. Ohne Doku zu Deiner Dome-Cam wird das nix, meine Kristallkugel nimmt gerade ihren Jahresurlaub. Von Parity-Berechnung ist in deiner bruchstückhaften Beschreibung nix zu sehen... Um es mal mit einem Filmzitat zu sagen: "Mehr Input!"

[Berserker]

Hi.

Danke erstmal für die schnelle Antwort.

Also ein Befehl sind 8 Bytes.
Byte1 bis Byte8.

Die Summe von Byte2 bis Byte8 wird von FFFFh abgezogen.
Funtkioniert auch.

Jetzt muss nur von der Summe die übrig bleibt das LSB rauskommen.

Beispiel:

Byte2: 00h
Byte3: 01h
Byte4: 01h
Byte5: 00h
Byte6: 01h
Byte7: 20h
Byte8: 00h

= Dezimal: 35
= Hex: 23h

FFFFh - 23h = FFDCh

LSB of FFDCh = DC;

brauche also nur eine Funktion für das LSB.

[BUG]

Hallo Berserker,

wenn du das "hintere" Byte brauchtst, probiere es mit mod 100h.

FFDCh mod 100h = DCh

MfG,
Bug

[OldGrumpy]

Simples "and" ist schneller:

Delphi-Quellcode:

LSB:=Ergebnis and $00ff;

Je nach Datentyp von LSB und Ergebnis empfiehlt es sich, den Wert auf die gleiche Größe aufzublasen, nur um sicher zu gehen dass der Compiler weiss was er da machen soll ;)

Sind die beiden also z.B. Cardinals, müsste da $000000ff stehen, sind es nur Words (wie ich vermute), reicht das angegebene $00ff.

[Basilikum]

Zitat:

Zitat von OldGrumpy

Je nach Datentyp von LSB und Ergebnis empfiehlt es sich, den Wert auf die gleiche Größe aufzublasen, nur um sicher zu gehen dass der Compiler weiss was er da machen soll ;)

Sind die beiden also z.B. Cardinals, müsste da $000000ff stehen, sind es nur Words (wie ich vermute), reicht das angegebene $00ff.

also das wäre mir jetzt ganz neu... bist Du sicher, dass die Anzahl der führenden Nullen einen Einfluss auf den generierten Assembler-Code hat ? ich habe dies kurz getestet mit Delphi 7, aber ich konnte keinen Unterschied im Assembler-Code feststellen... ob ich jetzt keine führende Null oder 20 hingeschrieben habe, er hat sich brav nach dem Ziel-Datentypen gerichtet...

[OldGrumpy]

Ich hatte irgendwann mal einen Fall wo das klemmte, das ist aber schon ewig her - ich kann aus dem Effeff nicht mal sagen, welcher Compiler das damals war, vielleicht sogar noch Turbo Pascal :)
Ich habs mir dann halt angewöhnt, bei bitweisen Verknüpfungen immer gleich große Werte zu verwenden, für mich persönlich machts den Code auch besser lesbar weil ich auf Anhieb sehe wie groß die beteiligten Datentypen sind.

OT: Vor einem halben Jahr etwa hatte ich unter VS2003 (VC++) mal einen entfernt ähnlichen Fall der sehr kurios war. Aufruf einer Funktion in einer DLL, Parameterliste enthielt mehrere Pointer, sowie als letzten Parameter einen optionalen BOOL (MS-Spezialität, nicht verwechseln mit boolean...). Auf der Aufruferseite wurde der vorletzte Pointer vergessen, der Compiler meckerte aber nicht! Auf dem Stack landete dann ein einzelnes Byte aus dem BOOL (ja, im Assemblercode wurde wirklich das LSB isoliert als DWORD auf den Stack gepackt!) und der auf DWORD-Format aufgeblasene Defaultwert für den der Meinung des Compilers nach fehlenden letzten Bool-Typ. Mein Kollege damals war mit seinem Latein am Ende, warum das immer eine AV gab, im Assemblercode wars dann aber relativ schnell lokalisiert und klar :) Ich muss dazu sagen dass diese Aufrufe wirklich krank aussahen und tonnenweise Antipatterns beinhalteten - Altlasten halt ;)

[Reinhard Kern]

Zitat:

Zitat von OldGrumpy

Ich hatte irgendwann mal einen Fall wo das klemmte, das ist aber schon ewig her - ich kann aus dem Effeff nicht mal sagen, welcher Compiler das damals war, vielleicht sogar noch Turbo Pascal :)
....

Hallo,

generell geht Borland mit der Auswahl von Zahlenformaten alles andere als intelligent um - ich hatte da schon bessere Compiler, die z.B. wissen, dass man für ein Ergebnis in Double auch alle Zwischenergebnisse innerhalb einer Formel in Double rechnen sollte. Bei Borland lag (liegt?) das aber am deklarierten Typ des Zwischenergebnisses, und ich musste daher manchmal ein solches Zwischenergebnis typecasten, etwa auf Double, damit der Compiler keine unerwünschten Rundungen durchführt. Das wird auch irgendwo in den Unterlagen beschrieben, aber man muss trotzdem erst mal draufkommen, warum die Ergebnisse so ungenau sind.

Im vorliegenden Fall ist das egal, weil das Ergebnis ja weniger Stellen hat als alles andere, aber deine Vorsichtsmassnahmen sind sicher richtig und ersetzen das von mir verwendete Typecasting.

Gruss Reinhard