[PIC] Jämföra två byte data?

[Klas-Kenny]

Jag tänkte försöka få två PIC'ar till att kommunicera med varandra, dock tänkte jag för att få lite felsäkerhet skicka varje byte två gånger, och kolla att de båda blivit likadana, och om inte, begära omsändning.

Dock undrar jag nu då, hur gör jag (i ASM) för att jämföra de två variabler med data?

Alltså ungefär:
-Jämför de två variablerna
-De va likadana, kör på!
-De va inte likadana, begär omsändning.

Funderade även på som antingen alternativ, eller komplettering till detta, en paritetsbit, hur kollar jag om pariteten stämmer?
Alltså hur kollar jag om en byte + paritetsbit bildar jämn paritet?

Handlar för tillfället om PIC16F690, om det skulle spela någon roll.
Hoppas jag fått med allt nu

[ToPNoTCH]

Nu har du ju inte skrivit HUR du överför data mellan dom.

Men principen är den samma.

- Ta emot byte(1)
- Lagra i variabel
- Ta emot byte(2)
- subtrahera byte(2) från variabel(1)
- Kolla statusregistret för Zero och om den är satt så är dom lika.

Koden kan se olika ut beroende på hur du överför

Men om vi leker med tanken att du tar emot byten parallellt på PORTA, så skulle kode bli rätt kort, och något i stil med:

Kod: Markera allt

**Sänd byte från PIC1**
movfw     PORTA
**Sänd byte från PIC1 igen**
subwf     PORTA,0
btfsc      STATUS,Z
goto       inte_lika
goto       lika

Givetvis måste PIC2 veta när PIC1 har sänt/omsänt byten så den vet när den skall läsa.
Det tar ju inte mitt exempel höjd för, men det var väl principen du var ute efter.

I detta exempel användes ju ingen variabel (enligt principen jag beskrev först), eftersom W kan lämnas orörd mellan operationerna. I en skarp kod och med exempelvis överföring med USART så skulle du sannolikt behöva mellanlagra byte(1)
i en variabel, av den anledning att W sannolikt behöver ändras innan byte(2) kan tas emot.

Med trött hjärna så tror jag det vart rätt, fan vad jag känner mig dålig på att förklara

[Klas-Kenny]

Stämmer bra att jag bara är ute efter principen, och ditt svar vart alldeles utmärkt! Tackar för det
Nu har jag att koda imorgon för att testa lite.
Att veta när den ena sänt osv. kan jag lösa, men just detta kunde jag inte klura fram men nu har jag lite att gå på.


Frångan ang. paritetskontroll kvarstår dock.

[bearing]

Finns mycket skrivet på nätet om det mesta som gäller PIC. Första google-träffen på: pic parity
http://www.dattalo.com/technical/softwa ... cprty.html

Hittade effektivare kod för paritet här:
http://www.retards.org/library/technolo ... nippet.htm
#20 (och ev. #19)

[Swech]

Om du nu skall bemöda dig om att sända samma byte 2 gånger,
T.ex master skickar
23,23 och väntar på att slaven säger ok eller det sket sig.

så kan du ju istället låta master skicka 23
vänta på slaven som tar emot 23 och skickar tillbaks 23
så kan ju mastern i sig kolla om det gick fram eller inte..

Men oavsett så finns det bättre sätt att skicka med checksummor istället..

Swech

[Klas-Kenny]

bearing: Den andra länken där innehöll ju mycket matnyttigt

Tror jag kör på endast paritet då, eftersom det vart så enkelt. Att skicka samma byte två gånger fördubblar ju trots allt risken för fel, och dessutom halverar det ju överföringshastigheten. Riktigt så kritisk är min applikation trots allt inte

Swech: Det har du en poäng i
Men som sagt, tror jag skrotar idén att skicka varje byte två gånger.

[sodjan]

> Att skicka samma byte två gånger fördubblar ju trots allt risken för fel,

Samtidigt ökar det chansen att upptäcka felet från "noll" till "ganska stor"
vilket sannolikt är en större ökning än en fördubbling...

[Klas-Kenny]

Fast det är ju inte noll chans att upptäcka fel när man kör med paritet

[vfr]

Nä, det får vi verkligen inte hoppas. Då skulle pariteten inte göra någon som helst nytta. Du kanske menar att det inte är 100% chans att upptäcka ett fel?

[Icecap]

Med paritet kan man bara upptäcka fel vid 1, 3, 5, eller 7 bits fel, inte vid 2, 4, 6, eller 8 bits fel. Paritet är helt enkelt inte värd att slösa tid på, en kontrollsumma (t.ex. CRC) är långt bättre.

Lite mer bök att få till det men värd hela mödan om det är "kritiska" instruktioner som t.ex. styrning av saker där fel kommandon kan ge problem (personfara eller liknande).

[Klas-Kenny]

Visst är paritet inte något att ha vid kritiska tillfällen, men i mitt fall är det inte så, paritet duger gott och väl, så kan man klara sig undan några av felen i alla fall.

Men skulle jag någon gång bygga någonting mer kritiskt skulle kontrollsumma eller liknande absolut användas

[spaderkung]

För principen om felkontroll och för att slippa återsända, så skulle du alltid kunna skicka byten 4 ggr och ta medianen för varje bit. Metoden har ett namn som jag inte kommer ihåg.

[ToPNoTCH]

Det där lät konstigt. Median för en bit ?

Är det någon form av interpolation, så låter det mer som att man får fram det "mest sannolika" resultatet, vilket är kanon
om man läser av en temperatur inför skidturen, men mindre bra om man avgör om katapultstolen i en JAS skall avfyras

Men det är säkert jag som inte fattar.

I övrigt så tycker jag att icecap's förslag är det absolut bästa, men med tillägget att CRC är en metod.
Jag vill med det säga att det finns enkla och svåra CRC algoritmer (runt 35 standarder har jag för mig), och att det därmed
inte obligatoriskt är krångligt utan styrs av vad man väljer.

Behöver jag påpeka att högre tillförlitlighet oftast innebär högre komplexitet

[ToPNoTCH]

För övrigt så om vi skall vara noggranna (och det skall vi ju i detta forum eller hur), så kollade jag nu och det verkar vara som så att paritetskontroll = CRC-1

Så rent semantiskt har icecap missat det genom att säga "skippa paritet och kör CRC".

Vad värre är så har även jag det indirekt, då jag höll med

Så det jag (och icecap sannolikt) EGENTLIGEN menar är: Använd en BÄTTRE CRC kontroll än CRC-1

[v-g]

En checksumma är väldigt enkel tycker jag, man kör enklast med en Byte som man regelbundet kör XOR på sen har man troligen en fast eller rörlig längd på datat. Så antigen kör man CRC-byten från början eller slutet (vilket som). Jag kör även en slags kontroll att datat är mottaget från MASTER-sidan mao begär svar och är det rätt så är allt ok om inte skicka om osv.

Såklart kan en CRC-check bli lurad även den men har man en byte är det en på 256 och två kvadrerar felchansen. Ju längre data ju längre CRC.