Hej!
Om man (som jag) skall ansluta en PIC till en annan PIC och tvåvägskommunicera emellan och använda en pinne som både in/ut-gång (typ I2C), bör man då ha något emellan pinnarna (från ena processorn till den andra) för att, om man gör ett programmeringsmisstag, inte skall bränna porten/pinnen?
Jag menar om jag råkar sätta båda anslutna pinnarna på respektive PIC till utgångar och sätta 1 på ena PICen och 0 på andra, så blir väl den förstnämnda kortsluten till jord?
Bör man använda ett lämpligt motstånd mellan dem för att vara säker?
Mats
PIC till PIC kommunikationsfråga?
Varför på detta dumma sätt?
Främst är IIC en Open-Collector med pull-up och därmed kan kortslutninger inte hända.
Men varför ska du krångla till det?
Ta ett par PIC med UART, ställ dom till samma baud-rate, koppla PIC1 TX till PIC2 RX och vice-versa och då kör det!
Ditt sätt med en IIC-liknande behöver många fler pinnar som handskakning för att fungera och det var väl inte vad du vill eller hur?
Jag kan inte förstå hur du vill kommunicera vid att sätta en sändare till en sändare.
Det finns sätt att kommunicera utan UART men ska jag vara ärlig kräver det mer än du nog klarar av i detta läge, ett alternativ är mjukvara-UART men det kräver en del programmering och överblick.
Främst är IIC en Open-Collector med pull-up och därmed kan kortslutninger inte hända.
Men varför ska du krångla till det?
Ta ett par PIC med UART, ställ dom till samma baud-rate, koppla PIC1 TX till PIC2 RX och vice-versa och då kör det!
Ditt sätt med en IIC-liknande behöver många fler pinnar som handskakning för att fungera och det var väl inte vad du vill eller hur?
Jag kan inte förstå hur du vill kommunicera vid att sätta en sändare till en sändare.
Det finns sätt att kommunicera utan UART men ska jag vara ärlig kräver det mer än du nog klarar av i detta läge, ett alternativ är mjukvara-UART men det kräver en del programmering och överblick.
Beskt morgonkaffe Icecap? 
Korrekt! Undvik denna situation... dvs driv ingen av dem höga. Fast har du exempelvis ett 10k motstånd till matningsspänningen (pullup) för att ådstakomma hög nivå så kan du, även om det kanske inte rekommenderas, koppla ett 220Ohm i serie mellan dina PIC så riskerar du inga haverier. Tänk i så fall på att ditt pull-up och seriemotståndet bildar en spänningsdelare.Jag menar om jag råkar sätta båda anslutna pinnarna på respektive PIC till utgångar och sätta 1 på ena PICen och 0 på andra, så blir väl den förstnämnda kortsluten till jord?
Kanske det....om jag nu drack kaffe alls......
Jovisst, lite betskt kommenterat, den får jag nog be om förlåtelse för.
Faktum kvarstår: Kaggen vill kommunicera vid att koppla 2 utgånger ihop och det hänger inte riktigt ihop.
Visst kan man göra en lösning med pull-up á la IIC men den lösning kräver konstant avpollning eller en väldig finurlig handskakning och belaster en hel del. Man kan lösa "Open-Collector" grejen vid att styra med TRIS-registret, skriv alltså en nolla till utgången och styr sedan den utgång med TRIS-bitten, därmed kommer man som värst att lägga en '0' ihop med en '0' och det klarar de flesta processorer ju galant.
Det kan gå om man blir ganska finurlig med protokollet men det blir inte lätt och främst kommer processorna vid kommunikationstillfällen att enbart ägna sig åt kommunikationen fast det kan ju fungera ändå.
Jag vill fortfarande fasthålla att seriell kommunikation via UART är det rätta.
Jovisst, lite betskt kommenterat, den får jag nog be om förlåtelse för.
Faktum kvarstår: Kaggen vill kommunicera vid att koppla 2 utgånger ihop och det hänger inte riktigt ihop.
Visst kan man göra en lösning med pull-up á la IIC men den lösning kräver konstant avpollning eller en väldig finurlig handskakning och belaster en hel del. Man kan lösa "Open-Collector" grejen vid att styra med TRIS-registret, skriv alltså en nolla till utgången och styr sedan den utgång med TRIS-bitten, därmed kommer man som värst att lägga en '0' ihop med en '0' och det klarar de flesta processorer ju galant.
Det kan gå om man blir ganska finurlig med protokollet men det blir inte lätt och främst kommer processorna vid kommunikationstillfällen att enbart ägna sig åt kommunikationen fast det kan ju fungera ändå.
Jag vill fortfarande fasthålla att seriell kommunikation via UART är det rätta.
Eh, för att jag är bra på det!?Icecap skrev:Varför på detta dumma sätt?
Främst är IIC en Open-Collector med pull-up och därmed kan kortslutninger inte hända.
Men varför ska du krångla till det?
Jag använder redan UARTen för kommunikation mot dator.Ta ett par PIC med UART, ställ dom till samma baud-rate, koppla PIC1 TX till PIC2 RX och vice-versa och då kör det!
Tja, jag tänkte att min "huvud processor" skulle kunna begära viss data från "slaven" vid önskade tillfällen.Ditt sätt med en IIC-liknande behöver många fler pinnar som handskakning för att fungera och det var väl inte vad du vill eller hur?
Jag kan inte förstå hur du vill kommunicera vid att sätta en sändare till en sändare.
Alternativet är väl (om man istället använder envägskommunikation) att slaven sätter en pinne hög när data är redo, och sedan klockar över all data så får "mastern" ta emot eller ignorera.
Jo. Det jag egentligen vill ha är ett enkelt sätt att "slaven" kan skicka över data till "mastern", men det kanske skulle vara smidigast med en processor med två UARTs då? Jag måste även kunna kommunisera med datorn också.Det finns sätt att kommunicera utan UART men ska jag vara ärlig kräver det mer än du nog klarar av i detta läge, ett alternativ är mjukvara-UART men det kräver en del programmering och överblick.
Mats
Det ville definitivt vara smidigast med 2 UART men det beror ju på vilken kommunikationshastighet som behövs och hur mycket "spilltid" varje processor har. Man kan, med en timer, tillverka en mjukvaru-UART men det hänger ju på vad du annars har av timers tillgängliga osv. Jag ogillar kraftigt en sån lösning men den kan fungera med de rätta förutsättninger.
Jag håller inte riktigt med om att I2C är olämpligt. Det som är svårast med I2C är timingen i slav-mode, men där finns ju PIC:ar med slav-I2C i hårdvara, t.ex 16F7x. Master-mode är en baggis att skriva rutiner för.
Sedan tar den egentligen inte mer pinnar än en UART-lösning heller. UART=2 pinnar (RX+TX) och I2C=2 pinnar (SCLK+SDAT). Detta förutsatt att man behöver dubbelriktad kommunikation i UART-fallet. Hursomhelst så är det bara två pinnar.
En annan lösning är att använda SPI-bussen. Den är enklare ännu enklare än I2C.
Sedan tar den egentligen inte mer pinnar än en UART-lösning heller. UART=2 pinnar (RX+TX) och I2C=2 pinnar (SCLK+SDAT). Detta förutsatt att man behöver dubbelriktad kommunikation i UART-fallet. Hursomhelst så är det bara två pinnar.
En annan lösning är att använda SPI-bussen. Den är enklare ännu enklare än I2C.
IIC är olämplig för den software-overhead som behövs. Om man sedan väljer en hårdvara-IIC är den lika effektiv/ineffektiv som UART men i detta projekt förstod jag att UART'en redan var tagen till annat och att IIC skulle utföras i mjukvara.
Ska man börja med mjukvaru-tx/rx kan det definitivt vara värd att tänka på en UART-funktion men det bästa är en hårdvaru-kommunikation, vara sig att det är IIC eller seriellt. Efter vad jag minns är de IIC som finns i PIC en UART i IIC-läge och då är vi där igen, hårdvaran sköter själva kommunikationen.
Beroende på avstånd, strömkrav osv kan seriell kommunikation vara en del mer störsäker också då utgången drivs aktivt i motsats till IIC's open collector med pull-up. Komponentmässigt behövs 2 extra motstånder för att köra IIC.
Så jag ser inget som talar för IIC men en del som taler emot.
Ska man börja med mjukvaru-tx/rx kan det definitivt vara värd att tänka på en UART-funktion men det bästa är en hårdvaru-kommunikation, vara sig att det är IIC eller seriellt. Efter vad jag minns är de IIC som finns i PIC en UART i IIC-läge och då är vi där igen, hårdvaran sköter själva kommunikationen.
Beroende på avstånd, strömkrav osv kan seriell kommunikation vara en del mer störsäker också då utgången drivs aktivt i motsats till IIC's open collector med pull-up. Komponentmässigt behövs 2 extra motstånder för att köra IIC.
Så jag ser inget som talar för IIC men en del som taler emot.
Jo, det är riktigt att UART/I2C är en gemensam del i hårdvaran. Det var just detta som var poängen. Låter man huvudprocessorn vara I2C-master så kör man utan hårdvara och UART:en är fri till PC-kommunikation eller vad man vill ha den till. På slavprocessorn däremot behövs troligen inte UART:en till detta och kan därför användas som I2C-slav.
Fördelen med I2C jämfört med soft-UART (vilket det iallafall skulle bli i ena ändan eftersom han behöver UART:en) är att timingen inte är lika kritisk. Mastern bestämmer timingen (inom specarna) och framförallt går det att förlänga cyklerna om man behöver göra annat under tiden. Kör man soft-UART måste man hålla ganska exakt på tiderna, även om man givetvis kan dra ner baudraten.
Däremot tycker jag egentligen att SPI är väl så bra om man bara skall ha relativt enkel kommunikation mellan enheterna. SPI-hårdvaran går dessutom att köra parallellt med UART:en.
Du har givetvis rätt i att UART-kommunikation är säkrare, iallafall med ett riktigt linjeinterface, om man skall köra längre sträckor. Jag tolkade det som att det var två processorer i "samma pryl" och då spelar det egentligen ingen roll. Är det däremot två separata enheter med en längre sträcka emellan så tycker jag att UART:en är given.
Fördelen med I2C jämfört med soft-UART (vilket det iallafall skulle bli i ena ändan eftersom han behöver UART:en) är att timingen inte är lika kritisk. Mastern bestämmer timingen (inom specarna) och framförallt går det att förlänga cyklerna om man behöver göra annat under tiden. Kör man soft-UART måste man hålla ganska exakt på tiderna, även om man givetvis kan dra ner baudraten.
Däremot tycker jag egentligen att SPI är väl så bra om man bara skall ha relativt enkel kommunikation mellan enheterna. SPI-hårdvaran går dessutom att köra parallellt med UART:en.
Du har givetvis rätt i att UART-kommunikation är säkrare, iallafall med ett riktigt linjeinterface, om man skall köra längre sträckor. Jag tolkade det som att det var två processorer i "samma pryl" och då spelar det egentligen ingen roll. Är det däremot två separata enheter med en längre sträcka emellan så tycker jag att UART:en är given.
