probleem met I2C

Op 26 mei 2019 15:57:30 schreef blackdog:
Gebruik de Logicanalyzer waar het zinnig is, dat is het hier zeker niet,
je gaat de bus nog meer belasten bij een bus die er toch al niet optimaal uit ziet.

Nochtans 'ziet' een Logicanalyzer de signalen zoals de MCU ze ziet en kun je ook een heleboel data loggen. Dus wel een handig ding

Arco

Special Member

Nochtans 'ziet' een Logicanalyzer de signalen zoals de MCU ze ziet

Da's niet altijd waar. De CPU inputs hebben hi/lo levels van 70%/30% terwijl een LA vaak TTL is. (ziet dus heel wat anders)
Een LA is wel ideaal om SPI en I2C messages 'uit te vlooien'. Voor het signaal zelf is een scoop beter (of een LA met analoge inputs)

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

Tja, de MCU heeft toch ook TTL level inputs, of bestaan er verschillende definities voor TTL?

Arco

Special Member

Een i2c i/o heeft gespecificeerde 70/30% levels, geen TTL. (dus ook de peripheral in de MCU)

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

ok, maar de I2C slave IO expander MCP23017 werkt dan toch met TTL inputs.
die ziet de data dan toch zoals een LA ze ziet?

Arco

Special Member

De enige inputs die TTL zijn, zijn de adres inputs (A0, A1, A2). De rest is CMOS/ST. (in dit geval 80/20%)

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

Ik ga er verder mijn hoofd niet meer over breken hoe het komt dat na (een) dag(en) de zaak vastloopt want dat kan eindeloos duren.
Ik heb er een mooie workarround voor gevonden en voor mij is de zaak opgelost.
Ook de errata over de MSSP van de 18F258 (eigenlijk dezelde architectuur als een 18F2580 maar met minder ram) heeft mij die richting ingestuurd.
Allemaal bedankt voor het meedenken

Arco

Special Member

Je kunt een errata van een compleet andere processor niet betrekken op deze, heeft er niets me te doen...

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

Zoals ik al zei: probleem opgelost!

Arco

Special Member

Jouw 'kludge' heeft niets met die errata te maken.
De i2c uit en aanzetten lost ogenschijnlijk het probleem op omdat de hele zaak opnieuw opstart. Met echt probleemoplossen heeft het niets te maken...

(als je tv een paar keer per dag raar doet, en je moet hem uit en aan zetten, accepteer je dat toch ook niet als 'oplossing'?)
Ik heb met i2c (op heel veel verschillende MCU's) nog nooit problemen gehad. Als je de datasheet maar goed volgt...

[Bericht gewijzigd door Arco op zondag 26 mei 2019 22:07:33 (15%)

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

Golden Member

Hi,

Hoe je er ook tegenaan kijkt, de pulssignalen moeten er als je er naar kijkt met een 1:10 probe op de scoop goed uit zien.
Is dit niet zo, dan heb je kans dat het op termijn toch mis gaat, pulsen die maar ter nauwer nood het vereisde 70% voedings niveau halen kan ik niet goed vinden.
De 30% voor het laag niveau van de gebruikte voedingspanning is meestal geen probleem als je de massa aansluitng goed geregeld hebt.

Wat ik hier zag aan signaal kwaliteit van het scoop plaatje kan ik niet goed noemen.
Er van uit gaan dat de robuustheid van het i2c protocol het wel oplost vind ik een verkeert uitgangs punt.

Mijn uitgangspunt is dat het i2C signaal er goed moet uit zien, bij 100KHz kan het zelfs met korte draden met 10K Pull-ups die vaak op een sensor aanwezig zijn.
Maar dat is voor een normale situaties voor storingsvrij gebruik gewoon niet voldoende.
Sommige van jullie willen de Pull-Ups zo hoog mogelijk hebben, wat begrijpelijk is vanwege het stroomverbruikt.
Zoals altijd gaat bij mij de stabiliteit voor, voor jullie? mogen jullie zelf beslissen :-)

rew
Wat je allemaal met Google vind wat gemeten signalen betreft, zegt mij heel veel over de gene die deze metingen gedaan heeft.
In principie vertrouw ik maar een paar mensen wat foto's van metingen betreft, waarvan Jim Williams er één van is.
Als het goed is begrijp je wat ik bedoel. :-)

Voor de gene die het niet weten, hele dikke traces omdat er gemeten is met max bandbreedte en metingen aan blok signalen met grote over en ondershoot zijn de norm op het Internet, zo hoort het dus niet in mijn ogen.

De opmerking over de Logic-analyzer geeft mooi aan dat het waarschijnlijk niet goed begrepen is.
Dit instrument geeft je mooie blokgolven op je apparaat maar wat je het op ziet ziet,
maar dat is niet het signaal, het is een geperfectioneerde weergave.
Ik heb niets tegen Logic-Analyzers, zoals met alle meetinstrumenten denk na als je ze aansluit, ze belasten het circuit. :-)

Door het aansluiten van de Logic analyzer kan het b.v. ook net weer goed gaan of net niet...
Dus zorg er eerst voor, dat je digitale signalen er goed uitzien, zodat ze ook later er geen problemen optreden door b.v. temperatuur wisselingen en dat de Logic-analyzer niet tegen je liegt omdat er voldoende stroom is om de ingangsimpedantie van de Logic-analyzer aan te sturen.

Oja, de drie standen van de bus wat snelheid betreft, geven de stroom aan wat je als basis kan zien dat nodig is voor de bus bij die snelheid bij een bepaalde bus capaciteit en je natuurlijk de weerstandswaarden die uit deze stroom volgen.
In principe bepaald zover ik weet, de Pull-up weerstand de stroom en niet de snelheid van het protocol.
De snelheid verlang een minimale stroom om met max. paracitaire capaciteit(400pF schijnt de norm te zijn) goed te werken.

De transistor in het i2c device (SDA en SCL aansluiting) is meestal een MOSfet die hard geschakeld wordt, zover ik weet is dit geen stroombron.

Ik ben op het ogenblik niet bij machte om nette scoop metingen te laten zien van het project waar ik op het ogenblik mee bezig ben.
Dat is een Adafruit Feather M0 met wat i2c sensoren en scherm, ik ben namelijk vergeten een scoop probe vergeten mee te nemen...
Anders had ik hier wat plaatjes van mijn i2c bus laten zien.

Zoals altijd is er altijd een "Error Budget"
Hoeveel devices gaan er op de bus
Welke snelheid gaat er gebruikt worden
Hoeveel parasitaire capaciteiten spelen er mee
Hoeveel energie mag ik verbruiken
Is er een device op de bus die misschien maar weinig stroom kan syncen
Zijn alle devices 3.3v of 5V geshikt?
Vullen jullie het zelf verder aan :-)

En hier een plaatje uit een Philips/NXP document dat een deel van de specificaties weergeeft wat stromen en snelheid betreft.

Gegroet,
Bram

You have your way. I have my way. As for the right way, the correct way, and the only way, it does not exist.

daar staat dus dat tot fastmodeplus de sink stroom 3mA moet/mag bedragen. 1500 ohm bij 5V is dus een te lage weerstand. 1800 is als de voeding toevallig rond de max van de range zit ook net te veel (te lage weerstand, te veel stroom).

Met een bus capaciteit van 400pF en een 2k pullup krijg je een RC van 800ns. het klok signaal is bij fastmode 2.5 µs voor een cyclus. De hoogperiode is dus 1.25 microseconde, slechts anderhalf tau.

[Bericht gewijzigd door rew op maandag 27 mei 2019 09:16:25 (15%)

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
blackdog

Golden Member

Hi rew, :-)

Ik zie het op deze manier, er is minimaal 3mA stroom nodig en gebruik je geen stroombegrensings weerstanden dan is dit 6mA.
Ik zie trouwens maar weinig mensen die stroombegrensweerstanden aan de slave units toepassen of natuurlijk de master.

Die 6mA kan je dus gewoon toepassen zonder deze begrensings weerstanden om te voldoen aan het minimale "laag niveau" Vol van 0,6V.
De stromen die vermeld staan zijn de minimale stromen.
De opmerking van jou dat 1K5 een te lage waarde zou zijn klopt volgens mij dus niet, die zit dan bij 5V mooi onder de minimale waarde die nodig is.

Mijn voorlopige conclusie is dat er over het algemeen te "hoge" Pull-Up weerstandswaarde gebruikt worden bij i2c.
Ik ben nog niet helemaal klaar met mijn onderzoek over het i2c protocol, ik vind de hysteresis van de Schmitt tigger ingang wel wat laag gekozen.
Dit is gespecificeert op 0,05Vdd dat is 250mV bij 5V en en 165mV bij 3.3V.
Dit is misschien de rede van de soms vreemde effecten die ik heb met het i2c protocol, misschien ten gevolgen van opgepikte stoorsignalen...
Ik kan dit Schmitt tigger niveau, nog niet goed rijmen met de logische niveaus van 30 en 70%
Ik zal de logische niveaus eens uittekenen op een stukje papier om te kijken of dit mij meer inzicht gaat opleveren.

Verder heb ik een aantal i2c devices bekeken wat betreft de max. stroom die de open Collector of Drain mag trekken,
dat is meestal nogal onduidelijk, meestal is het zoiets als "volgt de i2c specificaties" voor die en die snelheden.
Hoe zie jij dat?

Groet,
Bram

You have your way. I have my way. As for the right way, the correct way, and the only way, it does not exist.
Arco

Special Member

Het is inderdaad een beetje vreemd omschreven.
Ik denk dat de drempels bij 30/70% liggen, en het actuele schakelpunt daar ergens tussen.
Als bij 50% de pin hoog wordt, dan wordt 'ie bij 50%-0.05Vdd weer laag. Heeft dus niets met de eigenlijke drempels te maken.

De busbelasting wordt op 400pF max. per deelnemer gegeven, in dit geval (4 ic's) dus 1600pF.
(als je het scoopplaatje bekijkt is de belasting in werkelijkheid veel lager...)

Bij de fast-mode staat dat een 'hoog' puls minimaal 0.6uS boven de 70% moet zitten.

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

Op 27 mei 2019 16:27:14 schreef blackdog:
Ik zie het op deze manier, er is minimaal 3mA stroom nodig en gebruik je geen stroombegrensings weerstanden dan is dit 6mA.

De spec is dat iedere slave het LOW niveau van 0.4V moet kunnen halen als er 3mA loopt. Als jij een 1500 Ohm pullup naar 5V monteert, dan loopt daar 3.07 mA en zegt de spec helemaal NIETS over wat de slave wel en niet moet doen. ("rook" behoort tot de geldige opties).

De spec zegt een output level van 0.4V en een input level van 0.6V. Dit geeft 0.2V "noise margin" om evt. groundbounce of andere stoorbronnen te kunnen tolereren.

Natuurlijk zijn moderne outputs in staat om makkelijk 20mA te sinken en is het geen probleem om een wat heftigere pullup te monteren. Maar volgens de regels zou het met een "max 3mA" chip ook moeten werken.

Op 27 mei 2019 17:04:05 schreef Arco:
De busbelasting wordt op 400pF max. per deelnemer gegeven, in dit geval (4 ic's) dus 1600pF.

Dat lijkt me stug. Volgens mij gaat het met dat soort getallen dan heel snel fout. Mijn PC (PCs staan niet bekend om "veel I2C peripherals" toch?) heef tien i2C targets. Zou er dan 10*400pF = 4nF aan capaciteit op 1 bus zitten, dan zit je met een 2k pullup aan een RC van 8 microseconden. Dan werkt niets meer.

Ik denk dat het echt 400pF per hele-bus is. Zie:
https://www.allaboutcircuits.com/technical-articles/i2c-design-mathema… onder het kopje Capacitance

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/