I2C Storingsgevoelig?

Op 9 september 2021 22:13:34 schreef soldeersmurf:
..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.

Ok, dus de bus gaat niet (zoals ik gelezen had) via een kabel tussen deur en <ergens anders>, maar blijft lokaal op dat ene board? In dat geval zou het ook in een auto prima betrouwbaar moeten werken. Op zich kan een kleinere pull-up wel effect hebben. Heb je al met een scoop op de scl/sda gekeken? Daar zul je een RC tijd zien. Als je R te groot is, zul je zien dat het signaal niet op tijd terug naar '1' is.
Verder, ontkoppeling op de voeding is wel ok?

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

Ik ga voor een groot deel mee met onder andere Arco.
Punt is wel dat het systeem er tegen moet kunnen dat er af en toe een bit omvalt. Als er I2C IC's op de bus zitten is men gebonden aan hun gedrag.

Een mislukt uitlezen van een status, een display dat heel af en toe een enkele seconde onzin aanwijst, of een enkel gemist temperatuursample of zoiets zullen in het algemeen geen enkel probleem zijn, maar de uitgangen van een schietkast voor explosieven (om iets wilds te noemen) zou ik zo niet maken..

Overigens ondersteunen veel I2C IC's ook SPI, wat naar mijn gevoel wat robuuster kan zijn. (en in ieder geval gemakkelijker galvanisch te scheiden als dat gepast is).

Als twee microcontrollers communiceren via I2C kan men een extra laag in de communicatie aanbrengen die fouten ondervangt. Het blijft dan wel zaak bij het ontwikkelen in de gaten te houden hoe vaak het mis gaat. Als de interferentie structureel is in plaats van incidentieel is het eerst tijd voor het oplossen van dat probleem.

Anekdotisch kan ik vermelden dat een I2C bus van meer dan een meter over gewoon draad in een kabelboom op een schaal van jaren en honderden producten betrouwbaar kan werken, evenals I2C sensortjes aan kabels van meters. Dat gaat echter niet vanzelf goed.

Het grote probleem bij i2c is dat er inherent geen zaken als crc, parity of sumcheck geïmplementeerd zijn. Zolang het om niet kritische toepassingen gaat zal dat in het algemeen geen probleem zijn.

Is dat in zekere mate toch het geval dan zul je dat zelf moeten regelen wat best lastig is.

SPI lijkt inderdaad vaak beter te werken als i2c.
Ook al is dat theoretisch niet zo. SPI heeft een veel hogere bitrate en geen enkele vorm van error checking in tegenstelling tot I2C.
Veel i2c masters handelen de boel niet goed af. Ze ondersteunen dan bijv. geen 'clock stretching' e.d. waardoor de boel in de soep loopt.

Het grote probleem bij i2c is dat er inherent geen zaken als crc, parity of sumcheck geïmplementeerd zijn.

Da's aan de programmeur zelf om dat te implementeren, houdt de zaak juist flexibel.
Je kunt toch als laatste byte een checksum of CRC meesturen? (bij fout geeft slave geen ACK)

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

Special Member

Op 9 september 2021 21:02:28 schreef Arco:
[...]
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)

Volgens mij dateert I2C in VGA al van ver voordat SMBUS een ding was. Er stond gewoon een 24C02 ofzo over de adertjes zodat de DDC-data uitgelezen kon worden.

Op 10 september 2021 08:55:24 schreef Aart:
Anekdotisch kan ik vermelden dat een I2C bus van meer dan een meter over gewoon draad in een kabelboom op een schaal van jaren en honderden producten betrouwbaar kan werken, evenals I2C sensortjes aan kabels van meters. Dat gaat echter niet vanzelf goed.

Met dat laatste ben ik nu bezig. Wat moet je doen om dat zo goed mogelijk te laten gaan?

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."

@Arco, klopt, en dat betekent in de praktijk extra hardware om dat te realiseren.

Het probleem wat ik nu heb is dat data blijkbaar verminkt op de controller van mijn 2x16 lcd display aankomt wat er in resulteert dat deze in een andere mode terecht komt. Het display wordt door mij gebruikt als 2x16 met een 8 bit interface. Vermoedelijk komt hij terecht in de 4 bit interface.
Probeer dat maar eens op te lossen met een crc / sumcheck. De controller kan daar niets mee. Ik zou dan extra hardware moeten tussen schakelen om de data te controleren alvorens de display aan te sturen.
Ik blijf beweren dat je het i2c gebruik moet beperken tot niet-kritische toepassingen over korte afstanden.

Meestal zijn dit soort displayfouten te wijten aan timing die niet klopt (en niet zozeer aan i2c).
Display commando's zijn zeer traag, (vooral zaken als 'clear display', maar liefst 1590us!, zelfs 'gewone' writes kosten 39us)
Je moet dan tussen commando's wel voldoende delay aanhouden. (anders worden er commando's gemist of misvormd.)

Bij initialiseren van het display moet je ook goed het timingdiagram van het display volgen (meestal totaal iets van 20ms delay)

[Bericht gewijzigd door Arco op 10 september 2021 10:30:14 (16%)]

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

Slechte timing van commando's bij dit soort lcd's is idd een veel voorkomende fout. In dit geval niet (helaas).

blackdog

Golden Member

Hi,

Er is al flink wat gezegt over de i2c bus.
Zover ik heb kunen vinden heeft er maar een person gesproken over de voedings ontkoppeling.
Als je naar lage waarden voor de pullup weerstanden gaat, moet je ook zorgen dus je voedings ontkoppeling blijft voldoen.

Zomaar condensatoren paralel aan de bus zetten lijkt mij geen goed plan.
Snubbers(R en een C in serie) over de twee dat lijnen zou wel eens kunnen helpen bij moeilijke situaties.

Gebruik een scoop om te kijken hoe het signaal op de twee data lijnen er uit ziet.
Nee! niet met een lang massa touwtje van de standaard scoop probe, maas met een korte massa verbinding.
Let op de over en undershoot, het liefst natuurlijk beide geheel afwezig.

Denk ook aan de massa van de scoop, zorg er voor dat de rest van de schakeling vrij is van de scoop massa.
Anders ben je de beruchte scoop commonmode aan het meten.

Groet,
Bram

Waarheden zijn "Illusies waarvan men vergeten is dat het illusies zijn"

Op 10 september 2021 10:33:01 schreef Leo-Bolier:
.. veel voorkomende fout. In dit geval niet (helaas).

Toch moet er ook in jouw geval een reden zijn dat de bus instabiel is. Nogmaals, I2C mag normaal nooit bitfouten geven, dat moet jaren stabiel kunnen zijn zonder dat er ook maar 1 bit omvalt. Als dat wel zo is, dan staat er iets op de rand, bv slappe flanken, bitrate te hoog, geen goede gnd return, bus langs storingsbron, ....

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

Wat het ontwikkelen op de werktafel betreft ga ik daarin mee, maar het is in het algemeen onmogelijk bij het ontwikkelen jaren gebruik bij een grote groep klanten mee te nemen.
Mogelijk zet EMC de nodige limieten, maar het antieke lasapparaat van de buurman heeft daar geen boodschap aan.

Het is bij veel applicaties praktisch als de firmware niet hangt bij een incidentiele fout.

Overigens lijkt dit de discussie over het hangen van I2C bij Arduino te zijn: https://github.com/arduino/ArduinoCore-avr/issues/42
Het geeft wel een interessant beeld van dat deelonderwerp, inclusief een aantal (deel-) oplossingen.

@maartenbakker; Het was geen project van mij, maar ik zal even kijken.

Beste om zo laag mogelijke pull-ups te gebruiken in 'moeilijke' omstandigheden.
In standard/fast mode is dat 1k8 bij 5v, en 1k2 bij 3.3v (stroom moet <=3mA zijn). Dit beperkt invloed van stoorpulsen en verkleint de risetime.

(bij maximale busbelasting van 400pF en 10k pull-ups is de risetime van de bus aanzienlijk: te groot voor 400kHz fast mode)

[Bericht gewijzigd door Arco op 11 september 2021 10:14:51 (22%)]

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

Op 11 september 2021 09:23:56 schreef Aart:
Wat het ontwikkelen op de werktafel betreft ga ik daarin mee, maar het is in het algemeen onmogelijk bij het ontwikkelen jaren gebruik bij een grote groep klanten mee te nemen.
Mogelijk zet EMC de nodige limieten, maar het antieke lasapparaat van de buurman heeft daar geen boodschap aan.

Die eerste zin moest ik 5 keer lezen :-)
EMC? Dat is toch een kwestie van goed ontwerpen! Als de bus over een harde, ononderbroken groundplane loopt ben je al aardig op weg. Je moet de bus niet over een switched mode regelaar laten lopen natuurlijk.

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

@Flipflop, natuurlijk heb je gelijk. Met een kabeltje van maar enkele decimeters zou i2c gewoon netjes moeten draaien. Er zit weliswaar een schakelend relais in de buurt maar die doet dat 2 x per dag...en schakelt alleen een led lamp.
Maar ik moest gewoon verder met dit projectje....dus maar een work-around.

Op 11 september 2021 00:53:13 schreef blackdog:

Zover ik heb kunen vinden heeft er maar een person gesproken over de voedings ontkoppeling.

Dat was ik zelf. Ik heb nog geen tijd gehad om met een scope e.e.a. te bekijken. De bewuste auto was afgelopen week op de IAA in Munchen. Ik zal je meetadvies ter harte nemen. Ik denk dat dit een leuke klus is voor mijn batterij gevoede (AC-)voor-versterkertje. Ooit gebouwd om voedingsstoringen te kunnen meten zonder eigen bijdrage van de scope.

Bij een vorig geval (met een display dat niet meer uit zijn woorden kon komen), stuitte ik op een app-note dat suggereerde serieweerstandjes in de SDA en SCL op te nemen. Dat gaf wel wat verbetering. C-tjes op de lijnen werd afgeraden, zoals jij ook opmerkte, vanwege slechtere stijgtijden.

De data wordt gesampled de SCL flanken. Een 'nette' zender houdt 90 graden faseverschil tussen dada en klok aan, dus wat minder steile flanken of een overshoot hoeven dus niet perse roet in het eten te gooien lijkt me. Ik kan evt. proberen de bussnelheid wat te verlagen.

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

Serieweerstanden in SCL en SDA zijn heel nuttig als de storing ontstaat door overspraak tussen SCL en SDA, of door undershoot op de neergaande flank.

C'tjes op de lijn kunnen in dat geval zelfs averechts werken!

Maar serieweerstanden doen niets teggen externe storingsbronnen.

Inderdaad is meten de beste stap. Overshoot (en overspraak) zou je moeten kunnen zien.

Een C op de lijn is altijd een slecht idee. Immers, dat maakt de flanken nog minder steil dan ze al zijn, zeker als de pullups wat aan de hoge kant zijn.
@TS, die flanken mogen wel "schuin" zijn, maar als de lijn naar '1' getrokken wordt, moet die wel op tijd bij '1' aankomen en niet nog halverwege de voeding zijn bv. Die RC tijd mag echt niet zo lang zijn.

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

@flipflop: Zolang de stijgtijden maar "kort" zijn in vergelijking met de periodetijd werkt het nog. Ik ben nog geen I2C devices tegen gekomen die een minimale rise-time hebben (misschien wel volgens de spec, maar niet in de praktijk).

C'tjes op de lijn hebben me een keer geholpen andermans slecht ontwerp (motordriver en I2C paralel in dezelfde kabel) werkend te krijgen. De extra capaciteit maakte dat de stoorpieken de bus niet meer ver genoeg omhoog kregen om een valse flank te maken....

Goede oplossing was natuurlijk een afgeschermde kabel met RS485 ipv I2C. Maar er was geen budget voor redesign, alleen voor quick-fixes.

Uiteraard is dat allemaal afhankelijk van wat nu eigenlijk je probleemoorzaak is.
Want als het overspraak tussen SDA en SCL is dan kan extra capaciteit het probleem groter maken (doordat de extra capaciteit ontladen moet worden, en dat maakt de stroom groter en geeft dus meer overspraak..