I2C na dolgih linijah

[s54mtb]

Celo popoldne sem se zezal z I2C preko dolgih linij. Na koncu se mi je najbolj obnesla varianta s pullupi (600 ohm) na obeh koncih kabla in s taktom 10kHz. Malo sem še povečal rise in fall time in stvar deluje zanesljivo in brez prenihajev.

Zanimajo me praktične izkušnje na tem področju.

[xfce]

Celo popoldne sem se zezal z I2C preko dolgih linij. Na koncu se mi je najbolj obnesla varianta s pullupi (600 ohm) na obeh koncih kabla in s taktom 10kHz. Malo sem še povečal rise in fall time in stvar deluje zanesljivo in brez prenihajev.

Zanimajo me praktične izkušnje na tem področju.

Hm, dobro, deluje. Ampak kako je pa potem v praksi, če imaš recimo 10m kabla, ki je priključen direktno na dva pina od MCU? Občutek imam, da se hitro zna zgoditi kakšna prenapetost in druge motnje... Je to sploh smiselno in dovolj zanesljivo?
Je mogoče rešitev v kakšni zaščiti?

[Cloud]

Celo popoldne sem se zezal z I2C preko dolgih linij. Na koncu se mi je najbolj obnesla varianta s pullupi (600 ohm) na obeh koncih kabla in s taktom 10kHz. Malo sem še povečal rise in fall time in stvar deluje zanesljivo in brez prenihajev.

Zanimajo me praktične izkušnje na tem področju.

Hm, dobro, deluje. Ampak kako je pa potem v praksi, če imaš recimo 10m kabla, ki je priključen direktno na dva pina od MCU? Občutek imam, da se hitro zna zgoditi kakšna prenapetost in druge motnje... Je to sploh smiselno in dovolj zanesljivo?
Je mogoče rešitev v kakšni zaščiti?

Glede na to da imaš 600Ohm na napajanje, bi moralo to kar dovolj dobro odvajati na napajanje in posledično na claming diode

[borisz]

Jaz na dolgih linijah uporabim I2C extenderje. Nekaj stane, ampak potem deluje zanesljivo tudi na 50m kabla.
https://www.poscope.com/product/poneti2cextender/

[mucek]

Odlicno, to sploh nisem vedel, da obstaja!

[javr]

sicer o I2C nimam pojma, so pa v bivši firmi neke računalniške povezave delovale preko tokovnih zank po včasih tudi, ohmsko gledano, zelo slabih telefonskih kablih

[marko]

V kakšnem okolju pa to uporabljaš?

[s54mtb]

Gre za prototip za projekt PoPri, kjer tri osnovnošolke rabijo IoT merilnk porabe energije in temperature. Okolje je "gospodinjsko".

[borisz]

Marko,
PCA9600 gre do 50m s CAT5 kablom. Uporabljamo ga našem I2C extenderju: https://www.poscope.com/product/poneti2cextender/
P82B715 je pa bolj na steroidih.

[TilenS]

Kadarkoli gre I2C povezava izven vezja obvezno buffer. Z P82 imaš tudi opcije diferencialne komunikacije sem testiral klasično povezavo z 100kHz (vsaj kolikor se spomnim) na 130m UTP kabla in dejansko nisem zaznal nekih posebnih težav.

[zanka]

Gre za prototip za projekt PoPri, kjer tri osnovnošolke rabijo IoT merilnk porabe energije in temperature. Okolje je "gospodinjsko".

Čemu ne 485, ki je temu namenjen?

[borisz]

Če imaš senzor na I2C, je enostavneje uporabiti I2C extender.

[tilz0R]

Gre za prototip za projekt PoPri, kjer tri osnovnošolke rabijo IoT merilnk porabe energije in temperature. Okolje je "gospodinjsko".

Čemu ne 485, ki je temu namenjen?

I2C senzor na RS-485 rabi (skoraj zagotovo) še en MCU

[zanka]

Menda so ARM-i poceni

[borisz]

So, ampak rabiš še RS485 vmesnik, ki stane toliko kot I2C extender.

[s54mtb]

Saj to sem tudi naredil pred časom, celo protokol sem se "zmislil" na osnovi HDLC:
https://e.pavlin.si/2016/06/04/hdlc-lik ... via-rs485/

ampak vzel sem, kar sem imel pri roki in je zahtevalo še najmanj truda. Vse ostalo bi bilo daljše od pol dneva "telovadbe".

Sem pa vesel, da se je razvila debata in da pristavi vsak svoje praktične (ok, tudi komercialne) izkušnje.

LP,
M.

[marko]

Ko že govorimo o praktičnih izkušnjah

Jaz imam zelo slabe izkušnje z I2C in ga niti približno ne bi uporabil v komercialnem produktu. HW s temi senzorji me je hecal do onemoglosti. Če me res ne bi kdo prisilil, oz. da bi res obstajal nek senzor samo v I2C konfiguraciji, bi ga namontiral, sicer absolutno ne. Je to bilo sicer že nekaj časa nazaj in v RTOS okolju to sicer ne bi bil več tak problem, ampak meni se je I2C bus konstantno obešal. SDA (mislim da) je šel v LOW in ga je bilo težko obuditi. Sam protokol je napisan tako, da se ti lahko zaklene cel bus in potem moraš z 100 in enim načinom to poskušat resetirat. Vse naprave "crknejo". Ne rečem, vem da je bil najbrž HW design problem, ampak po N (dragih) poskusih, ni bilo več ekonomsko smotrno, da nadaljujem. Na istem vezju, sem potem uporabil samo SPI senzor in problemi so magično izginili in se niso nikoli več pojavili. Zame je to bil game over za I2C.
Za zunanje komunikacije pa uporabljam izključno CAN.

[borisz]

Marko, lahko je bil problem tudi v programu. I2C, če je pravilno uporabljen, je zelo zanesljiv.

[marko]

Uporabljal sem hardverski I2C. Opcija za to je torej samo če je AVR imel hardwerski bug, ampak tega nisem preverjal.

[bluel]

Jaz sem uporabljal i2c tudi na 30m kablih, brez ekstenderjev, le malo filtrov in zascite pred uC in je slo brez problemov.

[s54mtb]

Najprej je treba vedeti, kaj i2c sploh je: "inter integrated circuit" komunikacija, kot že ime pove. Tam tudi deluje in se obnaša v specifikacijah. Kadar je aplikacija izven tega, npr z dolgimi "žnorami", je treba vedeti kaj to pomeni. Linija, ki ima le open-drain izhod rabi pullup. Če je poleg še C ib L od kabla, postanejo pravokotni signali vse kaj drugega kot pravokotni.

Najhuje, kar se lahko zgodi je, da eden od poslušalcev potegne eno od linij na GND. Komercialnih aplikacij z I2C je neskončno. Tudi bugov je lahko veliko, zato je poleg pisanja driverjev potrebno prebrati tudi " errata" dokumente, saj eni celo proizvajamo izdelke z vgrajenim bugom (priloga).

[marko]

Jaz sem znotraj vezja imel težave (avtomobilska elektronika). Da bi spravljal i2c izven vezja, mi niti približno ne pade na misel

[PrimozL]

Z I2C imam dve zanimivi izkušnji.

Prva je bila v kolegovem sistemu avtomatizacije kurilnice. Razdalje do senzorjev so do 10 metrov. Ko nič ni delalo, kot bi moralo, so bili ukrepi na las podobni Maretovim (nižanje pull-up uporov na obeh straneh linije, nižanje hitrosti komunikacije do 20 kHz). Že skoraj 10 let dela brez težav.

Druga izkušnja je bila pri I2C povezavi preko treh vezij, ki je bila izvedena s ploščatimi kabli. Pa še pretvorniki nivoja z "boosterji", ki generirajo tokovne konice, so bili vmes. Presluh je povzročil ogromno težav. Rešitev je bila v uporabi pretvornikov nivoja brez "boosterja" ter s prerazporeditvijo signalov v ploščatih kablih, da je bila med SCL in SDA masa, na njihovi zunanji strani pa napajanje (drugače ni šlo). Največja težava presluha na I2C je, da je v času, ko je tranzistor zaprt, linija zaključena z relativno visoko impedanco in kot taka "pobere" iz okolice prav vse, kar se da.

[SamoBr]

i2C je bil narejen za komunikacijo znotraj škatle od televizorja. In tam dela odlično.

[s55m]

S kočijo se je odlično peljati po Lipici. Do Dunaja pa raje izberite avto.

[VolkD]

S kočijo se je odlično peljati po Lipici. Do Dunaja pa raje izberite avto.

In to pove nekdo, ki je v Plovdivu!

[PrimozL]

S kočijo se je odlično peljati po Lipici. Do Dunaja pa raje izberite avto.

Dobra. To je bil sicer še vedno bolj izlet do Divače ali Kozine, ampak ja - čista zloraba I2C glede na to, čemu je namenjen.

[s55m]

S kočijo se je odlično peljati po Lipici. Do Dunaja pa raje izberite avto.

Dobra. To je bil sicer še vedno bolj izlet do Divače ali Kozine, ampak ja - čista zloraba I2C glede na to, čemu je namenjen.

Plovdiv? Update man, update

[VolkD]

Plovdiv? Update man, update

Ah ja, predmestje Bostona.

[s54mtb]

Plovdiv? Update man, update

Ah ja, predmestje Bostona.

Da ni Boston predmestje Plovdiva

[Dorijan]

POglej si ta članek
https://hackaday.com/2017/02/08/taking- ... ong-wires/

[Aljosa]

Tudi sam sem imel nemalo težav z I2C senzorji (IMU-ji) že na krajših razdaljah tj. na istem pcb-ju kot mcu. Podobni simptomi kot jih zgoraj omenil Marko.

Če se le da vedno uporabljam I2C z DMA prenosom, kar običajno izboljša delovanje, še posebej pri prenosih 400kHz ali več.
Meni najbolj zanimiv primer je bil ko sem z logičnim analizatorjem opazoval signal in je bil v vseh časovnih mejah specifikacij ampak je v nekem trenutku periferija na mikrokrmilniku vseeno obstala.
Vzporedno sem meril napajanje in napetosti na pullupih in je bilo vse v standardih.
Lahko narediš HW po specifikacijah pa še ni zagotovila, da bo delovalo ok. Tudi FW se lahko spiše tako, da ima čimmanjši vpliv na sam prenos/uporabo I2C periferije pa še vedno ne gre.

Rešitve ("gverilske") so potem različne. Vsekakor moramo najprej zaznati, da je prišlo do neodziva s strani senzorja ali periferije na MCU-ja:
1. Veliko proizvajalcev MCUjev ima v errati napisano kaj narediti in običajno gre za ti. clock-out metode, kjer pine za SDA in SCL spremenimo v digitalne izhode in pač enostavno
s prisilo generiramo uro. Dostikrat to priklopljeni senzor postavi v stanje, ko spet deluje normalno. Včasih pa tudi to ni dovolj...
2. Stikalo na napajanje senzorja in ti. hard reset.
3. Reset celotne I2C periferije na MCU-ju.
4. Senzor na drugem vodilu (npr. SPI)

Po vseh izkušnjah, ki jih imam z I2C senzorji, besedi stabilnost in zanesljivost ne sodita ne sodita k I2Cju. Pogovarjal sem se s kolegi, ki delajo podobne projekte (stabilizatorji kamer, gimbli, oculus rift itd) in imajo z I2C vsi podobne izkušnje.
Skupno jim je bilo to, da so mi vsi svetovali da naj se v primeru moje aplikacije definitivno izognem uporabi I2C če je le mogoče.

To je moje mnenje in moje izkušnje.