Jag håller på och leker lite med ett projekt här hemma där jag har två 16F876A som behöver utbyta en del data mellan varandra. Den ena agerar "datainsamlare" och den andra är "display- och kontroll-panel".
Överföringen kommer att ske seriellt över "vanlig" koppartråd på ca 10m avstånd.
Datamängden ser ut att bli ca 65 bytes per "paket" och är inte tidskritisk annat än att hänsyn måste tas till en 10ms timer-interrupt på ena PIC:en, så överföringen måste nog styckas upp i dessa "luckor".
Spontant, känns det enklaste men osäkraste, att köra asynkront och skicka några bytes åt gången tillsammans med en CRC för hela klabbet.
Jag skulle hällre vilja ha en sykron överföringav något slag, men då kommer diverse funderingar. Vad ska man välja för teknik? Måste jag låsa en som Master och en som Slav? Hur buffrar jag ett dubbelrikt I/O?
Kommunikation PIC <-> PIC
f87X-serien har väl inbyggd I2C- och SPI-enheter vilka är synkrona standardiserade serieöverföringssätt. Om du sänker hastigheten mycket kanske det funkar på 10 meter.
Annars tycker jag asynkront verkar säkrare eftersom det bara krävs en ledare. Är det två kanske den ena blir lite längre så de hamnar ur fas.
Annars tycker jag asynkront verkar säkrare eftersom det bara krävs en ledare. Är det två kanske den ena blir lite längre så de hamnar ur fas.
Jo, dom har bl.a. I2C för synkron överföring som jag tittat lite på. Jag har dock bara använt I2C till eeprom på några cm avstånd.
Jag kanske har fått nå't om bakfoten, men har man inte synkrona överföringar just för att kommunikationen inte ska komma ur fas.
Sätt DataBit, pulsa Clock. Sätt nästa DataBit, pulsa Clock... o.s.v.
Jag kanske har fått nå't om bakfoten, men har man inte synkrona överföringar just för att kommunikationen inte ska komma ur fas.
Sätt DataBit, pulsa Clock. Sätt nästa DataBit, pulsa Clock... o.s.v.
Nej, USART'arna är fria. Du menar "pin til pin" asynkront, eller hur?
I så fall är det nå't åt det hållet jag hade tänkt mig i första skedet innan jag rörde till i hjärnan med andra eventuella lösningar...
Enklast känns ju som sagt att bara banga på asynkront.
Bör man buffra PIC:en i ett sån't här fall? Nu kommer jag att ha optokopplare på ena sidan i alla fall, men hur mycket kan/bör man lita på dom interna skydden?
Inte för att jag tror att jag behöver det här utan är mest bara nyfiken, men hur buffrar man ett dubbelriktat I/O t.ex. I2C DataPin eller en 1-wire krets?
I så fall är det nå't åt det hållet jag hade tänkt mig i första skedet innan jag rörde till i hjärnan med andra eventuella lösningar...
Enklast känns ju som sagt att bara banga på asynkront.
Bör man buffra PIC:en i ett sån't här fall? Nu kommer jag att ha optokopplare på ena sidan i alla fall, men hur mycket kan/bör man lita på dom interna skydden?
Inte för att jag tror att jag behöver det här utan är mest bara nyfiken, men hur buffrar man ett dubbelriktat I/O t.ex. I2C DataPin eller en 1-wire krets?
Jag vet iofs inte hur mycket som kan hända på 10-meter. Men det tar ju en stund för pulserna att färdas genom sladdarna vilken kan få dem ur fas om det är höga frekvenser och sladdarna är olika långa. Finns nog även risk för interferens.Pjoms skrev:Jag kanske har fått nå't om bakfoten, men har man inte synkrona överföringar just för att kommunikationen inte ska komma ur fas.
Sätt DataBit, pulsa Clock. Sätt nästa DataBit, pulsa Clock... o.s.v.
För att kommunikationen ska komma ur fas krävs ju att hårdvaran ska missa en puls någonstans, med asynkron är det på 1 signal det kan hända, med synkront är det 2, alltså den dubbla risken.
Sedan är synkron signalering INTE till för "ökad säkerhet", den används där det ska gå snabbt. "Vanlig" seriell kommunikation använder ju tiden för att dela upp bitsen, detta medför att varje bit ska ha en viss tidslucka och höga hastigheter ställar större krav på hårdvaran. Likaså är de flesta störningar korta pulser vilket är lätta att filtrera bort om datadelen av signalet är "långa" pulser, alltså är en 9600,n,8,1 kommunikation "säkrare" än en synkron kommunikation.
Så gör som sodjan skriver och det går bra, använd t.ex. en MAX232 i varje ända, då kan störningar inte komma direkt in i PIC'arna.
Sedan är synkron signalering INTE till för "ökad säkerhet", den används där det ska gå snabbt. "Vanlig" seriell kommunikation använder ju tiden för att dela upp bitsen, detta medför att varje bit ska ha en viss tidslucka och höga hastigheter ställar större krav på hårdvaran. Likaså är de flesta störningar korta pulser vilket är lätta att filtrera bort om datadelen av signalet är "långa" pulser, alltså är en 9600,n,8,1 kommunikation "säkrare" än en synkron kommunikation.
Så gör som sodjan skriver och det går bra, använd t.ex. en MAX232 i varje ända, då kan störningar inte komma direkt in i PIC'arna.
Jag trodde att en synkron överföring skulle vara säkrare i och med att man "talar om" när det finns ny data att läsa.
Så är det alltså inte och man har lärt sig nå't nytt idag också! Trevligt
Som jag tidigare skrev har jag optokopplare på ena sidan så där har jag ju en rätt bra buffert och på andra sidan får jag väl stoppa i nå'n buffertkrets av nå't slag.
Är t.ex. en 74HC14 nå't att ha som buffert, eller ska man gå på mer speciella kretsar?
Så är det alltså inte och man har lärt sig nå't nytt idag också! Trevligt
Som jag tidigare skrev har jag optokopplare på ena sidan så där har jag ju en rätt bra buffert och på andra sidan får jag väl stoppa i nå'n buffertkrets av nå't slag.
Är t.ex. en 74HC14 nå't att ha som buffert, eller ska man gå på mer speciella kretsar?
> Jag har dock bara använt I2C till eeprom på några cm avstånd.
Precis vad det är avsett för. Glöm I2C eller SPI för 10 m.
Sen när det gäller "synkron". Jag vet att man kallar I2C och SPI
för "synkron", men jag tänker mer på t.ex SNA/SDLC och liknande
protokol.
Synkron kommunikation är där sändare och mottagare har *var sin* klocka
som går "synkront". D.v.s det överförs ingen klocksignals alls mellan
sändare och mottagare. Förrutom en "synk" då och då för att återställa
eventuella klockskillnader.
Fördelen med synkron komm är att man använder linjen bättre eftersom
det inte finns någon "start" eller "stop" bitar. Alla bitar (utom en synk
då och då) är "data".
I fallet med I2C och SPI är det ju den ena änden (mastern) som styr
"klockan". Vid asynk komm har i och för sig varje ände en egen klocka,
men de behöver inte vara lika noggranna som vid synk komm eftersom
man synkroniserar klockorna efter *varje* överfört tecken.
När det gäller USART till USART over ca 10 meter, så är det nog inget
problem om du kör t.ex 1200 buad. Är det "hemma-miljö" så skulle jag
inte vara så orolig för störningar. Koppla upp och prova.
Du bör köra med kristaller så att timingen blir rätt. Om du har samma
kristall på båda PICarna, så behöver du inte bry dig om att du inte
träffar helt rätt på buadraten.
Precis vad det är avsett för. Glöm I2C eller SPI för 10 m.
Sen när det gäller "synkron". Jag vet att man kallar I2C och SPI
för "synkron", men jag tänker mer på t.ex SNA/SDLC och liknande
protokol.
Synkron kommunikation är där sändare och mottagare har *var sin* klocka
som går "synkront". D.v.s det överförs ingen klocksignals alls mellan
sändare och mottagare. Förrutom en "synk" då och då för att återställa
eventuella klockskillnader.
Fördelen med synkron komm är att man använder linjen bättre eftersom
det inte finns någon "start" eller "stop" bitar. Alla bitar (utom en synk
då och då) är "data".
I fallet med I2C och SPI är det ju den ena änden (mastern) som styr
"klockan". Vid asynk komm har i och för sig varje ände en egen klocka,
men de behöver inte vara lika noggranna som vid synk komm eftersom
man synkroniserar klockorna efter *varje* överfört tecken.
När det gäller USART till USART over ca 10 meter, så är det nog inget
problem om du kör t.ex 1200 buad. Är det "hemma-miljö" så skulle jag
inte vara så orolig för störningar. Koppla upp och prova.
Du bör köra med kristaller så att timingen blir rätt. Om du har samma
kristall på båda PICarna, så behöver du inte bry dig om att du inte
träffar helt rätt på buadraten.
>Synkron kommunikation är där sändare och mottagare har *var sin* klocka som går "synkront". D.v.s det överförs ingen klocksignals alls mellan sändare och mottagare. Förrutom en "synk" då och då för att återställa eventuella klockskillnader.
Rätta mig om jag har fel men man kan ju även bygga in klockan i datasignalen. då synkas ju klockan vid varje positiv flank, vilket ger totalt synkade klockor. iofs ca 3 ggr så långsamt men jämfört med att dra en extra ledning för klocksignal så är kan man nog leva med det. om man nu är rädd för osynkade klockor.
Rätta mig om jag har fel men man kan ju även bygga in klockan i datasignalen. då synkas ju klockan vid varje positiv flank, vilket ger totalt synkade klockor. iofs ca 3 ggr så långsamt men jämfört med att dra en extra ledning för klocksignal så är kan man nog leva med det. om man nu är rädd för osynkade klockor.
Eller "självklockande" som t.ex Manchester-kod. Ger dock inte optimalt
utnyttjande av bandbredden.
> jämfört med att dra en extra ledning för klocksignal...
Och det är ju helt omöjligt om man har t.ex en IR-länk.
De (gamla) synkrona protokollen (t.ex SDLC) är väl mest tänkta för att pressa ur
maximal bandbredd ur en viss ledning. "Priset" är en mer komplex
teknik med höga krav på klockorna i varje ände...
utnyttjande av bandbredden.
> jämfört med att dra en extra ledning för klocksignal...
Och det är ju helt omöjligt om man har t.ex en IR-länk.
De (gamla) synkrona protokollen (t.ex SDLC) är väl mest tänkta för att pressa ur
maximal bandbredd ur en viss ledning. "Priset" är en mer komplex
teknik med höga krav på klockorna i varje ände...
Men alltså....10m....stor avstånd?
Nej, 10m är INTE stort avstånd. Jag har lyckats med att köra stabilt multidrop 2400baud på 650m nergrävd KULO-kabel och _det_ är stort avstånd i den sammanhang men 10 m är det INTE.
Vad jag vill föreslå är att se till att ha någon form av buffer så att de störningar som iaf. kommer att samlas upp av ledningen inte kan komma direkt in i µC'n och kan man få till en optokopplare så att de är galvanisk skilda är det perfekt. Optokopplarna ska sitta i mottagareändan.
Nej, 10m är INTE stort avstånd. Jag har lyckats med att köra stabilt multidrop 2400baud på 650m nergrävd KULO-kabel och _det_ är stort avstånd i den sammanhang men 10 m är det INTE.
Vad jag vill föreslå är att se till att ha någon form av buffer så att de störningar som iaf. kommer att samlas upp av ledningen inte kan komma direkt in i µC'n och kan man få till en optokopplare så att de är galvanisk skilda är det perfekt. Optokopplarna ska sitta i mottagareändan.
