Val av databuss

[cjonash]

Jag håller på att skissa lite på en uppsättning moduler som behöver kunna kommunicera med varandra (det är en utveckling av det här projektet: http://elektronikforumet.com/forum/view ... =3&t=66010), och undrar om någon har förslag på vilken standard man ska välja. Det gäller både elektrisk och protokoll standard.

Kraven som finns är:
- Ingen master (alla enheter kan skicka data närhelst de önskar, men också på förfrågan från valfri enhet)
- Bussen skall kunna vara upp till ca 400 meter (eller längre såklart)
- Minst 100 noder skall kunna finnas på bussen

Önskemål (alternativt bättre förslag):
- Data skall skickas på en partvinnad kabel (ett par, två trådar)

Utöver detta så är det önskat att så få komponenter som möjligt krävs för att implementera bussen, liksom att det overhead som skapas i programvaran till noderna är så liten som möjligt. Det handlar om att ansluta enstaka givare eller signalenheter (t.ex. en lampa) till varje nod, så kostnaden för att göra intelligenta noder skall helst vägas upp av fördelarna (central administration t.ex.) och av den underlättade installationen. Med andra ord kan inte noderna kosta obegränsat med pengar, då antalet noder blir ganska högt även i en relativt liten installation.

Jag tittade lite på CAN-bussen, och den skulle kunna fungera. Den uppfyller de flesta kraven, och komponenterna är överkomliga i såväl antal som pris. Dock är en nackdel att man bara kan skicka med 8 byte nyttodata i varje sändning, och det är lite i minsta laget för min applikation. Det går att komma runt med ytterligare ett lager av protokoll, men då blir det genast mera komplext i mjukvaran...

Hoppas någon har lite tips att komma med!

[Icecap]

RS485. Gjort för partvinnat och kan klara 1500m+.

Sedan behöver man lite bus-congestion-styrning, det kan enkelt fixas vid att låta mottagardelen av bufferkretsen vara på jämt och jämföra det man sänder med vad som avlyssnas på linjen.

Då kan du bygga ett protokoll som kan vara åt CAN-bus hållet: meddelanden är inte med adresser till enheter men istället med kommandon: gör detta eller hint. De enheter som anser att de ska göra deras del använder då de data. Ska det svaras väntar varje enhet en "slumpmässig" tid innan svaret skickas.

[H.O]

Beträffande RS485, med så många enheter på bussen gäller det att välja tranceiver-krets med omsorg.
Det vanligaste tror jag är att trancievern är gjord för upp till 32 enheter men det finns de som klarar fler. Alternativet är såklart att ha "repeatrar" utspridda.

[AndLi]

Sen ska man fundera lite på om det är rätt tänk att 100 enheter kan prata när som helst, risken för kollision beror ju såklart på hur ofta och hur länge varje enhet kommunicera, men den är rätt stor med många enheter.
Och vilka "realtidskrav" man har...

[rawsezx]

Har i ett projekt stött på ett liknande vägval. Det föll dock på CAN den gången och kan säga att vi praktiskt kopplade ihop 64 noder i samma slinga med mcp2551 kretsen utan problem.

[TomasL]

RS485. Gjort för partvinnat och kan klara 1500m+.

Personligen, RS485 är ett mycket olämpligt val, då den är specifikt konstruerad för Master/slavsystem, välj istället ethernet och TCP/IP eller CAN, då dessa är konstruerade för just detta.

Ett annat vettigt val är ZigBee eller dess derivater, men då är det radio, dock kan man köpa färdig hårdvara mycket billigt.

[sodjan]

Hela specen i förstainlägget luktar CAN.
Väldigt mycket ingår "på köpet" med CAN.
Varje nod behöver bara bekymra sig om sin egen roll
och vad den ska sända eller ta emot, vad de andra
noderna gör behöver den inte bry sig om. Kollisioner och
omsändningar tas om hand av hårdvaran. o.s.v. o.s.v.

[cjonash]

Tack för alla förslag!

@Sodjan: Jo, visst finns mycket av mina önskemål i CAN - och till viss del beror det säkert på att just den bussen hade jag läst på om i andra sammanhang. Nackdelen med CAN är att jag behöver skicka paket som är större än de 8 byte som specen tillåter.

@TomasL: En IP baserad lösning hade haft många fördelar (inte minst installation eftersom i många fall finns redan infrastrukturen, och dessutom får man fördelen att lätt förgrena bussen med switchar). Problemet som jag ser är att det ökar komplexiteten på noderna. Det krävs lite mer för att hantera TCP/IP än seriell data - och jag får för mig att det därmed blir dyrare.

En idé: skulle man inte kunna ta de fysiska egenskaperna hos CAN bussen (t.ex. genom att använda samma drivkrets), men låta mikrocontrollern sköta hela protokollet och därmed kunna definiera en större (och möjligen variabel) paketlängd? Visserligen inte längre en standard, men det bekymrar mig inte speciellt mycket i det här projektet. Eller är det en dum idé, vad tycker ni?

[Nerre]

Du måste ju inte köra tcp/ip över ethernet, du kan ju köra ett enklare hemmasnickrat protokoll?

Med ren ethernet så har du ju redan adresserna (MAC) och hanteringen av att alla kan snacka när som helst (CSMA/CD).

Problemet blir väl segementlängden, men sitter det switchar med jämna mellanrum borde det ju gå att göra en längre kedja.

[Micke_s]

Du skulked kunna ta ett wiznet och köra broadcast med UDP, förutsatt att alla noder ska prata med alla.

Dock så behöver du implementera dhcp client om du behöver det, har också sett lösningar där noden hittar en egen address om dhcp inte finns. Typ som windows gör (169.något)

[anrhm]

Du skulle kunna titta på CAN-FD.
http://e2e.ti.com/blogs_/b/analogwire/a ... d-can.aspx
http://www.can-wiki.info/doku.php?id=can_fd

CAN FD tillåter högre bandbredd och större datapaket.
Det verkar vara en bit kvar tills det är standardiserat men det känns som att det skulle kunna vara något som löser dina problem.

[TomasL]

Det krävs lite mer för att hantera TCP/IP än seriell data - och jag får för mig att det därmed blir dyrare.

Det beror väl på vad man menar med dyrare, EN MAC/PHY costar inte mer än andra lösningar, men visst det blir en aning mer komplext, dock till exempel uChip har färdiga exempelprogram för sånt här, dessutom, rätt många uP har inbyggd CAN-controller, uCHIP har dessutom färdiga applikationesexempel för Ethernet/TCP/IP, CAN ZIGBEE mm.
DU skall glömma alla seriella protokoll och titta på de protokoll som använder sig av någon form av CSMA/CD direkt i hårdvaran.

[rawsezx]

Jag vill nog hävda att ur komponentsynpunkt så är ethernet en dyrare lösning, ca 30 komponenter resp. 10 st för CAN, kollade lite snabbt BOM-listan på vår mastermodul som innehåller båda.
LAN8720 är billigare men kräver lite dyrare komponenter, RJ45 kontaktdon samt kristall mfl.

PHY = LAN8720 (6,96 SEK)
CAN = SN65HVD230 (10,64 SEK)

Med tanke på kabellängder så kanske Ethernet är bättre då den är isolerad mellan switch/hubb och modul.
Sen så är TS fråga lite svävande angående antalet, minst 100 st moduler, vad är maxantalet? SN65HVD230 klarar 120 noder medans MCP2551 klarar 112 st.

//K