I2C Storingsgevoelig?

I2C wordt op veel plaatsen succesvol toegepast omdat het simpel en betrouwbaar is. Inmiddels heb ik ervaringen met I2C communicatie tussen uP's en periferie die toch wat problemen ondervonden. Enkele voorbeelden:

* Een zonne-boiler meetsysteem met een DS1307 klok-ic en een LCD-display met een PCF8574 parallel driver-chip. De RTC-klok gaat vaak over 'de rooie', terwijl ook het display random tekens vertoont. Display (en driver) zijn met de hoofdprint verbonden via 25 cm flatcable. Het geheel staat in een ruimte met pompen, watervat met heaters (enkele kW!) die in- en uitgeschakeld worden.

* Controllerboard in de deuren van een auto met MCP23017 I/O-expanders. Soms schijnt het dat het configuratie-register waarmee de ingangs-polariteit (inverteren of niet) wordt ingesteld 'omklapt'. Enen komen dan binnen als nullen.

In beide gevallen lijkt het erop dat de aangesloten IC's data ontvangen menen te hebben die nooit (bewust) is gestuurd.

De I2C bus heeft in beide gevallen (minstens) 4k7 pull-ups.

Heeft iemand hier misschien ervaring mee?

Niet alles wat op internet staat is waar... Dat geldt ook voor CO.

tja, I²C is een asymmetrische verbinding. als er storingen van voldoende amplitude inslaan op je draden (clock/data), of de ground kan het dus fout gaan.

mel

Golden Member

Je kan de weerstanden veranderen naar 2k2.

I2C kabel is wel afgeschermd?Het is nooit bedoeld voor lange afstanden trouwens.

[Bericht gewijzigd door mel op 9 september 2021 07:06:40 (50%)]

u=ir betekent niet :U bent ingenieur..

I2C kan vrij eenvoudig in een lockup (master of slave wachten op clockpulsen) situatie geraken, en de meeste systemen hebben hiervoor geen uitweg geprogrammeerd. Opnieuw opstarten is dan noodzakelijk. De signalen moeten dus absoluut betrouwbaar zijn, daarom korte signaalwegen.

bprosman

Golden Member

Het is nooit bedoeld voor lange afstanden trouwens.

Kan dit alleen maar beamen, het is van origine uitgevonden als / ontwikkeld voor "Inter IC Communication" binnen 1 apparaat (TV bijvoorbeeld).

Als het in een ruwe omgeving (pompen, boilers etc) moet denk ik al sneller aan RS232 of RS485.
Je zou ook iets van buffering kunnen proberen, bijvoorbeeld met een P82B715 I2C Bus extender.

[Bericht gewijzigd door bprosman op 9 september 2021 07:17:52 (13%)]

De jongere generatie loopt veel te vaak zijn PIC achterna.

I2C is bedoelt voor 10-20cm op dezelfde PCB. Als je er 25cm draad aan hangt, dan heb je meer storing dan waarvoor het bedoelt is.

Ik zou niet zo zuinig zijn, en pull-ups van hooguit 1k gebruiken. Misschien zelfs wel lager. Als dat tot gevolg heeft dat het niet meer op 400kHz werkt, gewoon terug naar 100kHz. 10kHz kan ook als je geen SMBUS spul gebruikt.

Die traagheid heeft als voordeel dat je extra capaciteit op de bus kunt plaatsen die (hoogfrequente) storing opeet.

In het geval van 1k pullup: plaats 4,7nF naar ground. 1k*4.7nF= 4.7us, dus 400kHz zal niet meer werken. 100 waarschijnlijk nog wel.

Afschermen kan ook helpen. Of, in een bandkabel alle aders naast de I2C aders aan ground leggen.

Op 9 september 2021 07:12:23 schreef RP6conrad:
I2C kan vrij eenvoudig in een lockup (master of slave wachten op clockpulsen) situatie geraken, en de meeste systemen hebben hiervoor geen uitweg geprogrammeerd. Opnieuw opstarten is dan noodzakelijk.

Als je zelf de controller (I2C Master) programmeert is dat vrij eenvoudig op te lossen. Toggle SCL 9 keer (SDA hoog laten) en alle (compliant) I2C devices zijn gereset.

[Bericht gewijzigd door blurp op 9 september 2021 07:27:51 (25%)]

...en als je dan over een kabel gaat, dan moet je er wel voor zorgen dat de gnd levels op beide uiteinden niet te ver uit elkaar kunnen lopen. Maw, je moet een harde gnd verbinding tussen master en slave hebben. Dat kan een dikke draad in de kabel zij (of meerdere), of dat beide aan een hard aardvlak zitten. Dat laatste kan bv in de auto. In een auto heb je dan wel weer last van flinke stoorpieken, en da's bij I2C niet fijn. Daarom hebben ze voor automotive dus CAN bedacht :-)

"We cannot solve our problems with the same thinking we used when we created them" - Albert Einstein

I2C is (indien goed gebruikt) heel betrouwbaar...
De pull-up waarde hangt van het aantal slaves, de buslengte, de bussnelheid, de (eventuele) kabelcapaciteit, en de voedingsspanning af.

(in de i2c 'bijbel' staan grafieken en berekeningen. Meestal is iets van 1k5 of 2k2 een goede keuze bij 400kHz bus.)
Voor externe slaves met kabel heb je een extender als de 715 nodig. kan ook zonder, maar dan op lage, niet standaard bussnelheden. (bijv. 10kHz)

Meeste libraries die bij compilers zitten deugen inderdaad niet, bij communicatiefouten zijn ze 'blocking' (de boel hangt voor eeuwig vast in een deadlock)
Als het betrouwbaar moet dan beter de routines zelf schrijven (dat stelt niet veel voor)

Binnen een print kunnen afstanden groter als 20cm soms best, hangt af van de capaciteit van de hele bus.
(spoortjes, slaves, master vormen allemaal een capacitieve belasting)

[Bericht gewijzigd door Arco op 9 september 2021 09:23:00 (11%)]

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com

Dan heb ik een hoop mazzel met mijn electronischkompaswatermetersensor. :P Daar zit tussen de 3 a 4 meter vier aderig telefoon/deurbel kabeltje tussen. Ging in het verleden als ik met m'n middengolfzendertje aan het testen was wel eens op tilt. Zo ook na een onweersbui soms. Sinds ik het belkabeltje bij de sensor een beetje HF heb onstoord gaat het wel beter. Scheelt in uitval i.i.g.

Waar het moederbord het meeste rookt, loopt ook de meeste stroom!
hennep

Golden Member

... bij communicatiefouten zijn ze 'blocking' (de boel hangt voor eeuwig ...

Tegen die eeuwigdurende impotentie kun je natuurlijk ook de watchdog inzetten!
Dat is wel zoiets als de deur openmaken met een koevoet maar toch wel erg effectief tegen een hangup.

Die instabiliteit van de RTC zou je kunnen omzeilen door 2x kort achter elkaar te pollen en alleen 2 identieke tijden te verwerken. (kan dat 2x per seconde?)
Dat is een lapmiddel maar toch handiger dan 1x een verkeerde tijd verwerken.

I2C is inderdaad behoorlijk storingsgevoelig. Ik heb een klein 80C32 systeem waar o.a. een lcd display middels twee pcf8574 parallel interfaces in zit.
Circa 30 cm kabel. Het draait continue (display wordt elke seconde aangestuurd en slaat ruwweg 1 x per week op tilt.
Nog wel bereikbaar; ik zie herkenbare stukjes van de gegevens verschijnen op het display en omdat het eigenbouw software is hangt de boel verder niet.

Er zitten 2k2 pull-ups op de SDA en SCL. Mogelijk dat een paar kleine c-tjes naar ground nog wat verbetering kunnen geven. Nog niet geprobeerd.
Omdat het geen kritisch systeem is heb ik uiteindelijk besloten om 1 x per dag een nieuwe rijtje initiatie commando's naar het display te sturen. Dit lijkt in deze situatie werkbaar.

Als je alles volgens de regels doet, is i2c niet 'storingsgevoeliger' als een andere seriele oplossing...
Buscapaciteit zo laag mogelijk houden (<400pF), en in storingsgev0elige omgevingen de pull-ups verkleinen (er mag 3mA lopen)

Ik heb heel veel i2c toegepast, en nooit problemen gehad. (ook met extenders en tientallen meters kabel)

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com

I2C is inderdaad bedoeld voor communicatie tussen verschillende IC's. Het was een vervanger voor de vroegere data, adress en controlbus die gebruikelijk waren bij de vroeger gangbare 8 bit cpu's. Daar was een vaak complexe adres decoder voor nodig om de juiste chip te kiezen. Vaak zat je met een op de print geëtste draadbundel van zo'n dertig draadjes die overal langs en naar toe moesten. Dat nam veel ruimte op de print in en toen de kloksnelheden wat hoger werden werd het steeds lastiger om dat door alle parasitaire capaciteiten en onvermeidelijke storingen goed werkend te krijgen. In de video techniek kwamen er toen steeds meer hele mooie analoge IC's bij die via een cpu bestuurd moesten worden. Dat kwam door de komst van de afstandsbediening. De binaire commando's op de RC5 afstandsbedieningen gingen van de afstandsbediening naar de ontvanger door de cpu over de data en adresbus naar de digitale potmeter die dan in stapjes het volume regelde. Over de drie touwtjes van een i2c netwerk ging dat veel makkelijker dan over dertig ofzo draadjes.

Praktisch was dat dus nooit meer dan een 10 of twintig cm. En dat werkte erg goed. Zo goed dat het systeem een beetje ten onder ging aan zijn eigen succes. Mensen gingen over langere afstanden werken en er kwamen extreem veel ic's die bestuurd werden met I2C.
Daarvoor zijn er ook later veel verbeteringen en extra's in het I2C protocol gekomen. Het aantal bruikbare adressen en de snelheid werd opgevoerd er kwamen oplossingen om grotere data woorden te kunnen versturen. Ook kwamen er oplossingen om grotere afstanden te kunnen overbruggen.

Al die oplossingen zijn overigens te vinden in de enorme berg applicatie notes die Philips (nu: nxp) heeft geproduceerd.

hennep

Golden Member

Of het veel of weinig storingsgevoelig is maakt op zich niet zo heel veel uit. Het kan een keer gaan hangen. Gebeurt dat met een TV of een ander apparaat waar je mee werkt of naar zit te kijken dan zet je het even uit. TS zit denk ik niet de hele tijd naar zijn zonneboiler te staren. Dan is enige vorm van zelfherstelling in code of hardware wel belangrijk, Murphy ligt om de hoek te wachten.

Zoals gezegd: dat kan alleen met beroerd geschreven firmware. (en alle i2c libraries die ik gezien heb vallen daar bijna onder)
Een i2c functie mag nooit blocking zijn; de meeste libraries zijn dat (bij fouten) wel.

Meeste libraries testen bits in de i2c registers, en wachten in een eindeloze loop tot dat bit geset of gereset wordt.
Als een slave 'hangt', gebeurt dat nooit meer en hang je voor eeuwig in een deadlock.

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com

Op 9 september 2021 18:05:51 schreef hennep:
Of het veel of weinig storingsgevoelig is maakt op zich niet zo heel veel uit. Het kan een keer gaan hangen. Gebeurt dat met een TV of een ander apparaat waar je mee werkt of naar zit te kijken dan zet je het even uit.

Ja hoor. Ik hoop dat jij geen kruisraketten ontwikkelt of zo. Een bus die in deadlock gaat is foute boel. Als er al een fout optreedt (wat bij I2C niet nodig is), dan moet je daar wel uit herstellen met een "error".

@Leo: daar heb je het weer, een kabel. Niet zo lang hier, dus het zou 100% betrouwbaar moeten kunnen. Het lijkt erop dat je gnd nivo's niet hard genoeg aan elkaar zitten.

"We cannot solve our problems with the same thinking we used when we created them" - Albert Einstein
maartenbakker

Special Member

Bij mijn weten heeft Philips de I2C bus bedacht, niet om het aantal draadjes van 30 naar 2 terug te brengen maar van ergens tussen 2+n en 3*n naar 2. Veel datatransport binnen apparaten waar de bus voor bedoeld was, geschiedde tot die tijd door middel van bitbangen. Meestal met een data, clock en enable lijn. Op zijn minst die laatste heb je dus voor elk stukje periferie apart nodig, vandaar die n in de formule

Men heeft zelf ook ervaring opgedaan met storingen op de bus; dat het misgaat in televisies met grote tot zeer grote signalen op centimeters afstand van je bus, kon je op je vingers natellen.

Als ik het goed heb, was het eerste protocol om I2C bussen langer te maken, D2B. Verder zit er op een SCART-kabel vaak ook een I2C bus en op een VGA-kabel zelfs altijd. Die blijven ook niet altijd tot een halve meter beperkt.

Ik heb op het moment een projectje waarmee ik een hooggeklokte I2C over ongeveer een meter wil transporteren. Ik ben benieuwd hoe dat gaat uitpakken. Tijdens de eerste tests geen problemen ondervonden.

www.deficientie.nl | www.elba-elektro.nl | "The mind is a funny thing. Sometimes it needs a good whack on the side of the head to jar things loose."
High met Henk

Special Member

Sommige dingen zijn gewoon een beetje anders gelopen als bedacht

I2C is bedoeld voor op een PCB en moet je daarbuiten niet gebruiken

ik ken ook bedrijven die een RS232 kabel over 100 m laten lopen en gaat goed, maar is wel DIK buiten de specs....er hoeft maar dit te gebeuren en het werkt niet meer.

Converteer die RS232 op 2 plekken naar 485 of 422 en je bent er ineens. Die dingen zijn niet voor niets compatible!

en dat 1 of andere IDIOOT bedacht heeft om I2C in VGA en SCART kabels te stoppen blijkt maar weer dat men helemaal nergens over nagedacht heeft!!!

in de industrie kies je altijd voor een betrouwbare standaard en ga je niet gokken op iets wat dan wel of dan niet werkt....

* High met Henk heeft niets tegen I2C op een PCB. Vaak zat gebruikt. Board 2 Board via connector of kort (flatcable) kaartje kan nog wel, maar verder lekker ver van weg blijven.

just my 2 cents, maar ik kan niet tegen incompetente engineering: heb daar gisteren alweer een flink lesje in gehad (zonder in details te treden)

E = MC^2, dus de magnetische compatibiliteit doet kwadratisch mee???

en dat 1 of andere IDIOOT bedacht heeft om I2C in VGA en SCART kabels te stoppen blijkt maar weer dat men helemaal nergens over nagedacht heeft!!!

Strict gesproken is dat de SMbus... ;)
En ik heb daar trouwens nog nooit problemen mee gezien, jij wel? (Laptop accu's gebruiken ook de SMbus)

Als je de juiste extenders gebruikt en pull-ups gaat i2c over langere kabels ook probleemloos.
Wij hebben vele i2c systemen met tientallen meters kabel geleverd. (soms met meer als 10 units). Dat werd intensief gebruikt en werkte probleemloos.
Werd gebruikt om rackmount pc's (voicesystemen) hardwarematig te resetten als de software vastliep.

Philips geeft zelf aan dat met extenders een afstand van een mijl mogelijk is (op lagere kloksnelheid uiteraard)

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com
High met Henk

Special Member

daarom gebruikt iedereen nu balanced bussen met twisted pair kabels, omdat het allemaal zo betrouwbaar was......

ik noem even:
Ethernet,
USB
RS485
RS422
Profinet
Can Bus
Mod bus

De enige die afwijken die ik ken is
I2C
parallel (LPT ofzo)
RS-232
AS-interface
1 wire

Gek genoeg kom je die afwijkende in de industrie (op AS-interface) eigenlijk niet meer tegen!

1 die wel afwijkt is het HART protocol.

Ethernet is wel echt een dingetje aan het worden in de industrie, maa rik zelf vind RS485 nog wel prettig.

en dat IK er nooit problemen mee heb maakt nog niet dat het geen probleem IS.

E = MC^2, dus de magnetische compatibiliteit doet kwadratisch mee???

Je vergelijkt I2C met Ethernet en co. Dat is appels en peren. I2C is niet bedoeld om veel data van A naar B te krijgen, maar om af en toe een statusregister uit te lezen, een setting te veranderen, die dingen. En dan ook nog eens in de basis op de PCB, maar soms een beetje erbuiten. Ik weet niet wat jij "in de industrie" bedoeld, maar het lijkt mij sterk dat er op een willekeurige module in "de industrie" niet ergens een I2C bus zit.

"We cannot solve our problems with the same thinking we used when we created them" - Albert Einstein
High met Henk

Special Member

dat zeg ik dus: op een PCB prima, maar tusen apparaten (dus via VGA of SCART) is gewoon een slecht plan.

en status kan ook PRIMA via UDP of MODbus

E = MC^2, dus de magnetische compatibiliteit doet kwadratisch mee???

Voor kleine hoeveelheden data werkt het goed en betrouwbaar (net als RS232 trouwens). Als het niet goed werkt, ligt dat aan de implementatie. (slechte hardware/software)
('t Is het makkelijkst om dan i2c de schuld te geven... ;) )

Heeft meer als 10 jaar gedraaid op afgelegen locaties door heel Europa, en nooit een storing gehad. (er hingen totaal meer als 15000 telefoonlijnen aan)
Als dat slecht gewerkt had, was het echt wel snel vervangen, want uitval van 1 pc met 30 telefoonlijnen kostte al gauw duizenden euro's per uur...
(en even naar Berlijn of Munchen heen en weer rijden doe je ook niet voor je plezier...)

dat zeg ik dus: op een PCB prima, maar tusen apparaten (dus via VGA of SCART) is gewoon een slecht plan.

Als de SMbus zo slecht is, waarom gebruiken dan alle monitoren en laptopbatterijen het als standaard? (zonder noemenswaardige problemen?)

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com

Bedankt voor al jullie reacties.

In de genoemde auto zitten in de deuren controllerboards waarop I2C gebruikt wordt om met MCP23017 I/O expanders te 'praten'. De PCB is nog geen 10x10 cm, dus de I2C bus-lengte is slechts enkele cm's. De print heeft een aardvlak en +5-vlak. Er zijn slechts 3 slave chips. Op de print of daarbuiten worden geen bijzonder hoge stromen of inductieve lasten geschakeld. De auto rijdt ook niet. Het is puur een demo voor wat snufjes. Eigenlijk had ik dus geen trammelant met de I2C verwacht.

Ik zal in ieder geval de pull-ups wat kleiner maken zoals iemand voorstelde. Ze zijn nu aan de hoge kant met 4k7. Als ik tijd heb zal ik een scoop aan de voeding hangen om te zien of daar veel rommel opzit. De raam-motor slurpt wel wat stroom, maar die komt uit een 12V voeding. De 5V komt van ver, een extra elko-tje is nog wel bij te plaatsen.

De genoemde deur-controllers communiceren trouwens probleemloos met een master via RS485 op 38kbit/s.

Niet alles wat op internet staat is waar... Dat geldt ook voor CO.

Op 9 september 2021 22:04:08 schreef Arco:
Als de SMbus zo slecht is, waarom gebruiken dan alle monitoren en laptopbatterijen het als standaard? (zonder noemenswaardige problemen?)

SMbus heeft een timeout, dus in geval van storing zullen alle (compatible!) devices aan de bus na enige tijd (ik geloof 10ms) resetten en kun je het opnieuw proberen.
I2C kan dat niet, die moet je softwarematig resetten.