I2C över långa avstånd <20 meter

[Aristoteles]

Jag håller på att skissa på ett system för att styra mitt hem. Tanken är att 5-6 nätverkskopplade µC (kanske Arduino för att göra det lite lättare) som kommunicerar via UDP med en server där merparten av intelligensen ska finnas. Innan jag startar vill jag vara säker på att jag börjar med rätt plattform därför har jag två frågor:

1. I2C över långa avstånd?
För kommunikation mellan µC och sensorer skulle jag vilja välja I2C men jag har förstått att det är många som är skeptiska till detta när det gäller längre avstånd (max 20 meter i mitt projekt). Läser man specarna från leverantörer av extenders verkar det inte vara några problem. Vad säger ni? Bör jag använda något annat? OBS trådlöst är inte aktuellt. Jag vill att det ska bli ett stabilt system.
2. Kan slavarna initiera kommunikation?
För att minska belastningen på bussen och på µC skulle jag vilja att sensorerna triggar kommunikation. Är detta möjligt?

De sensorer jag ska koppla in är rörelsesensorer, magnetbrytare, temperaturgivare, RFID
Det jag behöver styra är solenoider, ledlampor (dimmer) samt några trefasmotorer.

[Klas-Kenny]

I2C i sig går klart utmärkt, allt hänger på spänningar, kablar och hastighet.

Många slav-kretsar brukar ha en signal ut för "Jag vill skicka något!", dock kräver det ju en egen tråd eftersom att de inte kan köra någon klocka och där med inte skicka något. Dock kan man ju köra multi-masters istället, så kan alla initiera kommunikation.

Men varför inte 1-Wire, som så många andra system?

[psynoise]

NXP på har applikationskommentarer AN11084 angående I²C över långa avstånd.

http://www.nxp.com/documents/applicatio ... N11084.pdf

Jag själv har dock inte läst dokumentet.

[Micke_s]

I2C har ju ett annat problem. Finns inget sätt att återhämta sig vid fel. Då är smbus bättre.

Annars kolla på LIN-bus MCP201 t.ex. 40meter har de i alla fall. Du kan ju köra din egen variant på uart trafiken, du behöver inte köra lin bus standard om du inte vill. Uart har ju de flesta MCU:er

[blueint]

Tips:
* Differentiellt
* Twistad kabel
* DC-balanserat
* Multidrop

[Micke_s]

Med 3trådar kan du mata noderna också. MCP201 innehåller en 5v sp. reg också(3.3v finns också)
Gör noderna med en liten MCU attiny2313 t.ex.

[andpe]

Blueint : Hva mener du med punktene dine DC-balansert, multidrop og differensielt?

[SeniorLemuren]

I2C har ju ett annat problem. Finns inget sätt att återhämta sig vid fel. Då är smbus bättre.

Här kan man läsa om skillnaderna: Comparing the I²C Bus to the SMBus.

In the I²C bus, if the slave locks up and holds either Clock or Data low, error recovery is impossible. Very few slave devices actually have the ability to hold Clock. As a result, the most common bus error is slave devices that have ended up in a state where Data (the data line) is low. In the I²C bus, a master accomplishes error recovery by clocking Clock until Data is high and then issuing a Start followed by a Stop.

[TomasL]

Vill du ha ett säkert system, så kör du med RS485, inget annat, sedan kan du hiva på vilket digitalt protokoll du känner för..

[Micke_s]

Problemet att köra clock recovery att man kan mata in skit i enheten som har hamnat "out of sync". Men visst, det funkar.

[blueint]

Det är därför man har kontrollkoder såsom CRC

[Micke_s]

Fast CRC är inte en del av I2C tyvärr...

[blueint]

Det kan nog finnas anledning att formulera om upplägget

[PaNiC]

Det finns en buss som gör detta, användes av Hiross en gång i tiden och kallas för Hirobus. Det är I2C med RS485-nivåer. Detta används i kommunikation mellan deras klimataggregat fram tills för några år sedan.

[TomasL]

Jamen det är ju en fullständig omöjlighet, såvida man inte kör över två par, 1 klocka och en data med dubbla tranceivers.