Vad ska man ha CRC på?

[Pajn]

Jag håller på med ett protokoll som kommer gå över RS485 och sitter och funderar på CRC.
Ett meddelande ser ut såhär: {mottagare,annan_mottagare;sändare;data;CRC}
Det jag funderar över är CRC'n. Ska den bara vara på datan eller på allt?

Problemet med att ha den på allt (mottagare, sändare och data) är väl att jag måste spara det hela i minnet, vilket går åt skogen på en lite klenare PIC om det är många mottagare.
Problemet med att ha CRC bara på datan är ju att ett meddelande kan gå till fel mottagare eller ange fel sändare.
Hur skulle ni ha gjort? Eller vet ni ett bättre sätt så att jag inte behöver spara hela meddelandet i minnet men ändå ha en kontrollsumma på det?

[bearing]

Du använder kontrollsumma och CRC som om de vore samma sak, och det är de inte. En vanlig summa beräknas väldigt enkelt genom att addera den byte som just sänds/tas emot med summan. En riktig CRC är mer avancerad.

[cyr]

Det går väl bra att beräkna CRC "on the fly" ? Jag har FPGA-kod som beräknar en Ethernet-CRC (32bit) på två bitar data åt gången t.ex.

Hur stort är varje fält i meddelandet? Är verkligen headern så stor att du inte har plats att spara den tills du tagit emot hela paketet och
kollat CRC?

Ett alternativ som kanske funkar på RS485 och ger tillräckligt skydd mot enstaka bitfel kunde kanske vara att köra med paritet?

[kimmen]

Även för CRC går det att ha bara en liten ackumulator som man uppdaterar för varje inkommet tecken. Gör man så behöver man inte lagra hela meddelandet i RAM utan bara ackumulatorn.

[Pajn]

Headern kan vara oändligt stor då man ska få skicka till hur många mottagare man vill.
Men problemet är inte att meddelandet är speciellt stort utan att vissa PICar har väldigt lite ram (12F629 har tex. 64 Byte, visserligen kanske jag får skippa de allra lägsta men 16F648A med 256 Byte skulle vara bra om det fungerade på).

Är det någon som har lite pseduokod för att generera CRC "on the fly"?

[sodjan]

Cyr> Är verkligen headern så stor att du inte har plats att spara den tills du tagit emot hela paketet
Kimmen> Även för CRC går det att ha bara en liten ackumulator som man uppdaterar för varje inkommet tecken.

Notera att det är sändning som Pajn specifikt frågar om, inte mottagning...

[sneaky]

Går det inte att ha en ackumulator för varje skickat tecken också då sodjan? CRC skickas ju sist?

[AndLi]

Jag kan inte påminna mig om att jag stött på en CRC16 rutin som inte gått att köra on the fly, du behöver ju bara komma ihåg ett 16 bitars värde mellan varje byte du tar emot/skickar. Hitta någon CRC funktion på nätet och titta på hur den gör... http://www.lammertbies.nl/comm/software/index.html kan kanske vara en start..

Sen är ju inte en CRC16 tillräckligt för oändligt långa paket. Risken att få en falsk rätt CRC ökar ju med längden av paketet.

[sodjan]

> Går det inte att ha en ackumulator för varje skickat tecken också då sodjan? CRC skickas ju sist?

Kanske det. Det har jag ingen som helst åsikt om...

[blueint]

Eller så kan man göra som IPv4 som har en mindre CRC bara för sändar-IP och mottagar-IP.

[kimmen]

Jo, visst går det både för mottagning och sändning.

För kod, ta en titt här:
http://en.wikipedia.org/wiki/Computation_of_CRC

Notera att alla kodsnuttarna ytterst har en slinga som itererar över datan i ordning från början till slut. Det går ju lätt att göra om till något som arbetar på ett tecken i taget.

Notera att det är sändning som Pajn specifikt frågar om, inte mottagning...

Är det? Det ser jag inte någonstans.

[Pajn]

>Går det inte att ha en ackumulator för varje skickat tecken också då sodjan? CRC skickas ju sist?
Jo det borde ju funka.

Ska kolla lite på olika CRC funktioner samt läsa länkarna, kanske återkommer jag med fler frågor.

>Sen är ju inte en CRC16 tillräckligt för oändligt långa paket. Risken att få en falsk rätt CRC ökar ju med längden av paketet.
Nej jag vet, men det är inga livskritiska funktioner utan jag vill bara att det "ska funka". Och om det inte gör det så "bad luck", testa igen.
Så länge det funkar nästan alltid så är jag nöjd. Dessutom, många fel (tex. att det kommer till en annan mottagare (som antagligen inte finns, då det finns > 13miljoner ID'n)) så kommer inte sändaren få något svar och kommer då försöka skicka det igen.

Jag uttryckte mig väl inte helt kart, men det är dubbelriktad kommunikation det handlar om.

[blueint]

Om alla mottagare dubbelkollar allt med CRC32 i slutändan kan man optimera för hastighet med enklare CRC för addresserna. Blir det fel är enda kostnaden processorkraft.

CRC32 används för att skydda SCSI-U320 data/kommandon och S-ATA data.

[Andax]

Fast måste du ändå inte kunna hålla allt i minnet. Huruvida du ska använda data eller inte på mottagarsidan beror ju på om CRC stämmer eller inte?!? Och CRC kommer sist!

[blueint]

Släng in en mindre CRC i mitten?