Jeg er programmør og jeg skal sende data til maskinen, men jeg skal tilføje kontrolsum i slutningen af dataene . Kan nogen vise mig et eksempel på, hvordan man gør det, så jeg kunne derefter skrive et program til beregning af kontrolsummen for mig.
Reglerne: Bitvis inversion af 1 bytesummen af bytes, der begynder med den mest betydningsfulde adressebyte og slutter med den byte, der går forud for kontrolsummen. (For at udføre en bitvis inversion, “eksklusiv ELLER” den ene bytesum med FF-hex.)
Tak
Kommentarer
- Hvad har dette at gøre med tagget: power-electronics?
Svar
Definitionen ret godt dækker det.
Bitvis inversion af 1 bytesummen af bytes, der begynder med den mest betydningsfulde adressebyte og slutter med den byte, der går forud for kontrolsummen. (For at udføre en bitvis inversion, “eksklusiv ELLER” den ene bytesum med FF-hex.)
Eksempel
- Besked “Hej” = Hex: 48 65 6C 6C 6F.
- Tilføjelse af disse ved hjælp af min Windows Calc.exe i programmør-tilstand får jeg & h01F4.
- Tag den sidste byte og ignorér alt andet: & hF4.
- & hF4 XOR & hFF = & h0B – din kontrolsum.
For at afklare den sidste bit:
&hF4 = 1111 0100 &hFF = 1111 1111 --------- XOR = 0000 1011 = &h0B Opdatering
Af en eller anden grund fungerer det ikke for mig. Her har jeg CA 00 01 70 00, jeg tilføjer dem for at få 13B, jeg tager den sidste byte, som er 3B og XOR med FF, så får jeg c4, som er forskellig fra 8E (et eksempel, jeg fik fra manualen). Savner jeg noget ved reglen?
En websøgning efter reglen kastede et dokument fra NESLAB . På side B-2 læser vi:
Figur 1. Kontrolsumregionen er den eneste del, der bruges i kontrolsummen.
Dette skal forklare din forvirring. Hovedkarakteren er ikke inkluderet i beregningen. Hvis vi nu kører en kontrol på CA 00 01 70 00, kan vi droppe CA og står tilbage med et par nuller, 01 og 70, der summerer til & h71.
& h71 XOR & FF = & h8E. Voila!
Kommentarer
- Tak. Jeg var forvirret over " Bitvis inversion af 1 bytesummen af bytes ". Jeg vidste ikke, det betyder at tage den sidste byte, men du ryddede det ud. Mange tak !!
- Bare nysgerrig, hvorfor XOR med h ' FF? Er det ikke ' dette som bare at invertere hver bit (0- > 1, 1- > 0). Ser ud til at begge gør det samme mod mig. Derefter kan du repræsentere det som " Bitvis inverteret endelig byte af summen af alle bytes i en meddelelse "
- Ja, du har ret, men XOR bruger kun en instruktion til at vende alle 8 bits. Jeg kan ' ikke tænke på en mere effektiv metode. Kan du?
- Af en eller anden grund virker det ikke for mig. Her har jeg CA 00 01 70 00, jeg tilføjer dem for at få 13B, jeg tager den sidste byte, som er 3B og XOR med FF, så får jeg c4, som er forskellig fra 8E (et eksempel, jeg fik fra manualen). Savner jeg noget ved reglen?
- @transistor: Tak for afklaring. Nå, jeg kender ikke ' programmeringssproget, det giver bare mere mening for mig sådan. Jeg ved i perl, at den ' bare er ~ variabel. Jeg tror i praksis, at det ikke ' ikke gør en forskel på nogen måde
Svar
Din påkrævede kontrolsum beregnes på baggrund af data således:
Du ikke inkluderer hovedtegnet 0xCA i kontrolsummen, kun det skyggefulde bytes.
En simpel C-kode til beregning af dit eksempel:
int main() { int i; unsigned char cs; unsigned char a[] = {0x00, 0x01, 0x70, 0x00}; cs=0; for (i=0; i< sizeof(a); i++) { cs += a[i]; } cs ^=0xFF; printf("cs = %X \n", cs); return 0; } Og resultatet er som forventet:
sh-4.3$ gcc -o main *.c sh-4.3$ main cs = 8E Da jeg erklærede variablen cs som et usigneret tegn, smider den de øverste bits væk ved hver tilføjelse. Tilføjelse er bare det samme som andre eksempler, du kan smide de øverste bits i slutningen, hvis du gør det manuelt. Bare vær virkelig forsigtig i disse tilfælde nøjagtigt hvad er og hvad ikke er inkluderet i kontrolsummen.