Svenska ElektronikForumet

Jag hade tänkt att koppla ihop flera PIC till en dator (dom olika PIC:arna kommer mäta temperatur och annat och skicka det bland annat). Viken är den smidigaste bussen enligt er?

En seriell bus är väl kanske det enklaste.

Använd den (seriella) buss som det finns hårdvarustöd hos i de flesta av dina PICar (ska de vara av samma modell?). Kvar får du då antagligen att välja på:
¤ Vanlig asynkron seriell kommunikation via UARTen.
¤ Synkron seriell överföring (I2C eller TWI).

Eftersom datorns serieport använder asynkron seriell överföring så är det helt klart lättast att haka på.
En fördel är om dina PICar då stöder "Multi-processor communication", d.v.s att du kan ge alla en unik adress som kommer lyssna till när du vill skicka till dem.
Alternativet är att du sätter en PIC som sköter kommunikationen mellan datorn och din buss.

Jag är inne på samma idé som dig!

Jag hade tänkt använda mig av en RS485 buss genom att bygga en RS232 till RS485 "converter" som jag kan koppla till min server (Behövs i princip bara en RS232 och en RS485 drivare för att åstakomma detta).

Den stora fördelen med RS485 är att jag utan problem kan dra kabeln runt hela huset utan att få några problem med räckvidden och störningar.

Det stora problemet är ju att konstruera någon form av synkront protokoll som kan undvika kollisioner på något fiffigt sätt. Jag har inte använt mig av I2C eller TWI, hur fungerar dom? Är det endast ett Master-Slave förhållande eller kan "slavarna" skicka data utan request också?

/Nicke

>> Croaton
I2C/TWI är främst en master-slave-buss, men man kan krångla till det och göra en multi-master-buss.
Hur hade du tänkt dig sammankopplingen av I2C och RS485? Det är väl lättast att köra RS485 direkt mot alla µC (med nivåomvandlare så klart)!?

$tiff: Jag hade bara tänkt köra en RS485 driver direkt mot PIC:en, tror det blir lättast så.

Det enda problemet som jag ser det är att jag skulle vilja att vilken "enhet" som helst ska kunna skicka data på bussen när som helst. Dvs om jag har en enhet som t.ex. övervakar temperaturen eller larm från min pelletsbrännare så vill jag att den skall skicka denna status så fort som eventet sker.... Problemet är ju att undvika kollisioner när flera enheter vill skicka data samtidigt.

Den enklaste lösningen är ju att låta servern/mastern polla data från de olika enheterna i tur och ordning.... men den lösningen är inte lika snygg.

/Nicke

Man kan också välja en annan lösning:
Om du pollar från mastern kan du göra det så att det finns en tidslucka där slaver kan trycka iväg "panik" meddelanden, alltså:
Lucka 1: master pollar enhet.
Lucka 2: slav svarar.
Lucka 3: ledig till brådskande meddelanden
sen lucka 1 osv....

Då får du en blanding av pollande master samt panik slav.

Det går även att, varannan pollning, fråga "är det någon som har problem alls?" eller så, om det är 2 som svarar samtidig och stör ut varandra måste man ha ett kolla på detta men de kan ju fördröja sitt "JA!" beroende på deras adress t.ex., då kan det komma ett flertal felmeddelanden in på "samma gång" så att säga.

Icecap: Jag har faktiskt funderat på något liknande som du nämner..

Vettigaste (enklaste) sättet för att undvika kollisioner är nog att fördröja skickandet baserat på kretsens adress/id, men för att det ska fungera så måste man ha någon form av refferens tidsmässigt... Om man då använder din första idé med kombinerad pollning/push så får man ju automatiskt en refferens.

Måste rita upp några scheman över hur kommunikationen skall fungera så att jag får en klarare bild över hur det kommer att fungera.

Seven11: Sorry för att jag snodde din tråd lite, det var inte meningen!

God Jul!
/Nicke

En ide kanske kan vara någon form av CAN-buss?
Kör man dessutom balancerat mellan enheterna så blir olika potentialer inga problem.
Du kan köra riktigt långa bussar om man håller sig borta från 500kbit´s hastigheter.
Här kan alla snacka med alla, och prioritering mm löses enkelt.

Visst, man får lägga några kronor mer på hårdvaran, men det kanske är värt det i längden?
Skall själv börja leka med Atmels AVR-serie med inbyggt CAN-stöd. (AT90CAN128 tex.)

Inom bilindustrin använder man ofta LIN som är en master-slave-buss man kan implementera mha UART. Du kanske kan surfa runt och knycka bra ideer som LIN använder? (Jag har för mig att man använder ett klurigt trick för att adresserar mha 9-bitars tecken men jag kanske blandar ihop det...)

Annars är ju CAN klockrent men det kräver ju särskild hårdvara.

Enligt min erfarenhet så hamnar man ofta i slutändan på ett poll-förfarande iställer för de snyggare eventen, iallafall om säkerheten är kritisk. Missar man en poll så rättar ju dethela till sig nästa pollning, det är svårare att tänka ut vad som händer i ett eventdrivet system.

Croaton: Ingen fara, kul att se när ideer poppar upp som jag inte tänkt på.

Men jag var inne (precis som JJ föreslog) på CAN en del... har kollat lite på SN65HVD1050 och undrar om inte den skulle kunna hjälpa en del, dock så verkar den behöva väldigt mycket kringkomponenter samtidgt hittar jag ingen driekt förklaring på hur det lokala protokollet fungerar, kanske är USART kompitabelt iof (pinnar heter RDX och TXD) vilket vore uuuunderbart =)

Låt mig veta vad ni tror!

God Jul btw

Läs om hur CSMA-CD fungerar i Ethernet och hur I2C bussen hanterar kollisionsdetektering. Det är inte så svårt att göra samma sak i en RS485-miljö.

En princip som funkar är att den nod som vill skicka något först kollar om linjen är ledig under en viss tid. Tiden som noden skall kolla linjen skall vara slumpvis vald inom ett visst intervall. Gissningsvis är tiden det tar att skicka ett tecken ett bra min värde och så kan man kanske ha 5ggr den tiden som max.
Anledningen att man skall polla en slumpvis vald tid är för att minska risken för att två noder skall börja sända samtidigt.

Är linjen ledig under pollningstiden så begär noden linjen genom att skicka ett kommando, t.ex. binärt 10101010. Sedan väntar noden på bekräftelse (ACK) från mottagarnoden.

OM mottagaren inte får ett riktigt startkommando så beror det på att två noder kolliderat genom att trots allt börja sända nästan samtidigt. Mottagaren skickar då ett resetkommando istället för ett ACK till bussen. Att två noder skulle skicka 10101010 EXAKT samtidigt är totalt osannolikt, om dom bara hamnar *lite* i otakt så blir det mottagaren ser något i stil med 10111110 eller så...

OM det blir kollision och mottagaren skickar RESET så skall alla noder som vill sända vänta en slumpvis vald tid innan de försöker på nytt. Då kommer det ju "antagligen" inte försöka samtidigt igen, iaf inte flera gånger.

Vips så har du byggt en multimaster buss! =)

//B1n4ry

B1n4ry: Jag funderade lite på TCP protokollet tidigare, men när du lägger upp det på det där sättet så är det ju bus(s)enkelt!

Det största problemet som jag ser det är ju att generera slumptalet, hur löser man det lämpligast på en PIC eller AVR ?? (Har inte kört AVR tidigare, men funderar på det så att jag kan köra gcc)

God Fortsättning!

/Nicke

Det är ju inte hyperkritiskt att det är ett statistiskt sett helt korrekt slumptal...
Ta ett mätvärde rakt av från noden och multiplicera upp det lite.
Även om du t.ex. mäter temperatur på flera noder så blir det ju inte exakt samma temp på två ställen... Det borde räcka som slumptal...

En annan möjlighet om man kan tänka sig någon extra krets (eller om mikrokontrollern har en extra RC-oscillator) är en enkel brusgenerator. Typ en liten oscillator vars utgång du kopplar till en ledig ingång på processorn. När du sedan vill ha ett 8-bit slumptal så läser du av "oscillatorpinnen" 8 gånger och då kommer du ju slumpmässigt att få 1:or och 0:or beroende på hur fort oscillatorn går. Vips har du ett slumptal! Det räcker ju med en inverterare, en konding och en resistor...

//B1n4ry

Trodde du skulle bygga en riktig buss...