Jeg er programmerer og jeg må sende data til maskinen, men jeg må legge til kontrollsum på slutten av dataene . Kan noen vise meg et eksempel på hvordan jeg gjør det, så jeg kan da skrive et program for å beregne kontrollsummen for meg.
Reglene: Bitvis inversjon av 1 bytesummen av byte som begynner med den mest betydningsfulle adressebyte og slutter med byten som går foran kontrollsummen. (For å utføre bitvis inversjon, «eksklusiv ELLER» den ene bytesummen med FF-heks.)
Takk
Kommentarer
- Hva har dette med merkelappen: kraftelektronikk å gjøre?
Svar
Definisjonen ganske bra dekker den.
Bitvis inversjon av 1 bytesummen av byte som begynner med den mest betydningsfulle adressebyten og slutter med byten som går foran kontrollsummen. (For å utføre bitvis inversjon, «eksklusiv ELLER» den ene bytesummen med FF-heks.)
Eksempel
- Melding «Hello» = Hex: 48 65 6C 6C 6F.
- Legge til disse ved hjelp av Windows Calc.exe i programmeringsmodus får jeg & h01F4.
- Ta den siste byten og se bort fra alt annet: & hF4.
- & hF4 XOR & hFF = & h0B – kontrollsummen din.
For å avklare den siste biten:
&hF4 = 1111 0100 &hFF = 1111 1111 --------- XOR = 0000 1011 = &h0B Oppdatering
Av en eller annen grunn fungerer det ikke for meg. Her har jeg CA 00 01 70 00, jeg legger dem sammen for å få 13B, jeg tar den siste byten som er 3B og XOR med FF, så får jeg c4, som er forskjellig fra 8E (et eksempel jeg fikk fra manualen). Savner jeg noe med regelen?
Et websøk etter regelen kastet et dokument fra NESLAB . På side B-2 leser vi:
Figur 1. Kontrollsumregionen er den eneste delen som brukes i kontrollsummen.
Dette skal forklare forvirringen din. Hovedpersonen er ikke inkludert i beregningen. Nå hvis vi kjører en sjekk på CA 00 01 70 00, kan vi slippe CA og sitter igjen med noen få nuller, 01 og 70 som summerer til & h71.
& h71 XOR & FF = & h8E. Voila!
Kommentarer
- Takk. Jeg var forvirret over " Bitvis inversjon av 1 bytesummen av byte ". Jeg visste ikke at det betyr å ta den siste byten, men du fjernet den. Tusen takk !!
- Bare nysgjerrig, hvorfor XOR med h ' FF? Er ikke ' t det samme som å bare invertere hver bit (0- > 1, 1- > 0). Virker som at begge gjør det samme med meg. Da kan du representere det som " Bitvis omvendt sluttbyte av summen av alle byte i en melding "
- Ja, du har rett, men XOR bruker bare en instruksjon for å snu alle de 8 bitene. Jeg kan ' ikke tenke meg en mer effektiv metode. Kan du?
- Av en eller annen grunn fungerer det ikke for meg. Her har jeg CA 00 01 70 00, jeg legger dem sammen for å få 13B, jeg tar den siste byten som er 3B og XOR med FF, så får jeg c4, som er forskjellig fra 8E (et eksempel jeg fikk fra manualen). Savner jeg noe med regelen?
- @transistor: Takk for at du avklarte. Vel, jeg vet ikke ' programmeringsspråket, det gir meg mer mening for det. Jeg vet at det ' bare er ~ variabelt. Jeg antar at det i praksis ikke ' ikke gjør noen forskjell uansett
Svar
Kontrollsummen din kreves beregnet på grunnlag av data:
Du ikke inkluderer hovedtegnet 0xCA i sjekksummen, bare det skyggelagte byte.
En enkel bit C-kode for å beregne eksemplet ditt:
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 Siden jeg erklærte variabelen cs som en usignert røye, kaster den de øvre bitene ved hvert tillegg. Å legge til er akkurat det samme som andre eksempler, du kan kaste de øvre bitene på slutten hvis du gjør det manuelt. Bare vær veldig forsiktig i disse tilfellene nøyaktig hva er og hva ikke er inkludert i kontrollsummen.