I2C tussen Raspi, Arduino, ESP32

Het UART idee snap ik niet helemaal. Daar zul je toch ook 2 masters hebben in dit geval.

Er is maar 1 master tegelijk, de andere is dan uit...

waarbij alleen de zender de bus drive't (hoe schrijf je dat???)

Wat zou je denken van "de bus aanstuurt" (of ook "controleert" of "bemeestert")? Nederlands is best een mooie practische taal, hoor, als men er een beetje weg mee kan :)

(enkel over het taalaspect - een aloud stokpaardje van me, dat zal intussen wel algemeen geweten zijn, denk ik, en niet tot algemeen genoegen ;) ) Over het basispunt zit ik volop te prakkezeren, ik kom er wel uit. Toch minstens voldoende om te kunnen een "proof of concept" voorstellen, en dat is eigenlijk alles wat er in eerste instantie gevraagd wordt. Ik houd jullie op de hoogte.

Op 19 november 2022 13:03:44 schreef Paulinha_B:
Heb je daarvan een voorbeeld?

Vroeger had je TTL. In die tijd konden ze goed "trekt naar nul" torren in ICs maken, maar nog niet goed de "trekt signaal naar voeding". Dat moest dan een weerstandje worden of zoiets (of misschien een slappe tor). Het is dan gunistig om af te spreken het omslagpunt tussen "moet je zien als een 0" en "moet je zien als een 1" lager in het 0-5V gebied zit. Als je van 5V naar 0V moet, dan kan die "trekt hem naar beneden tor" dat gewoon prima vlot doen, ook al moet ie van ver komen. Andersom, hoeft de "trekt-hem-omhoog" constructie (wat het dan ook was) maar iets te doen en de andere kant ziet het als een 1.

Voor compatibilty met die oude chips heb je "HCT" chips die ook een laag omslag punt hebben maar verder wel modern opgebouwd zijn met CMOS torren (Dus vrijwel even goed naar + als naar - kunnen trekken).

Deze, als je ze voedt met 5V hebben een laag omslagpunt. Gegarandeerd dat een 0 uit een pi (Max 0.4V o.i.d.) als een 0 gezien wordt, en dat een 1 uit een pi (minimaal 2.9V o.i.d) als een 1 gezien wordt. Maar aan de uitgang krijg je prima 5V signaal niveaus.

Ik gebruik dus de 74HCT04 of de 74HCT245 als ik 8 signalen tegelijk heb. Die '04 inverteert het signaal. Ik gebruik er dan 2 achter mekaar als ik maar 1 signaaltje heb, en dan dus de "2G": 2 gates versie. Of ik inverteer het signaal in software aan de zendende kant.

Dat gezegd zijnde.... Is het niet eenvoudiger om een arduino uit te kiezen die op 3.3V draait? Volgens mij zijn die zelfs in AVR varianten te krijgen. Binnen de arduino omgeving merk je er vrijwel niets van als je een andere supported CPU hebt.

Bij nieuwere pic's kun je per i/o pin instellen op pull-up (sommige ook pull-down), OD, TTL of S/T, slew-rate, inverter,...

Op 19 november 2022 16:58:43 schreef Arco:
Er is maar 1 master tegelijk, de andere is dan uit...

Ja ok, dan moet die inactieve master z'n TX naar tristate zetten dus. Het voordeel wat ik zie van i2c of 485 is dat de inactieve gelijk kan meeluisteren wat de andere master aan het doen is. Je kunt die bus dan gelijk gebruiken om het moment van omschakelen (naar de andere master) te communiceren, of af te leiden uit ene inactieve bus oid.

Precies, @FF, in die richting gingen mijn gedachten. Maar de details zijn nog lang niet aan de orde.

Maar de details zijn nog lang niet aan de orde.

Juist wel!

Als je hardware ontwerpt, moet je eerst bepalen wat je ermee kunt en wilt gaan doen, niet achteraf...
(de hardware moet de gewenste functionaliteit wel aan boord hebben)

Als je hardware ontwerpt, moet je eerst bepalen wat je ermee kunt en wilt gaan doen, niet achteraf...

In eerste instantie dacht ik hij heeft helemaal gelijk. Echter is dit meer gewoon wat modules aan elkaar knopen en is de hardware al klaar.

Toch is het beter eerst je even te verdiepen in de voor en nadelen van de verschillende bussen. Zoals Uart(RS232), I2C, SPI, RS485, MODbus, CANbus, enz

Voor zover ik weet is de Uart ontwopren om 1 op 1 te communiceren en is de I2C bus zelf geschikt voor meerdere masters, ook omdat iedere unit zijn eigen adres heeft en het I2C protocol ook spreekt dat het mogelijk is. Het is denk meer de uitdaging om goede software te vinden die ook multi-master ondersteunt. Maar aan de bus zelf ligt het niet.

Met Uart zou multi-master eventueel ook kunnen maart is het ook de software die dan bepalend is.

Meestal voor ik een beslissing neem zoek ik dat soort dingen eerst uit en zoek hoe anderen het hebben gedaan en of ik er een software voorbeeld of bibliotheek kan vinden. IK heb meestal weinig zin om het allemaal zelf uit te gaan vinden.

RS485 lijkt dan wat overdreven maar ik denk dat er meer voor te vinden is en je ook nagenoeg geen kans hebt dat de bus blijft hangen/ bezet blijft.

Op 19 november 2022 19:49:59 schreef Paulinha_B:
Precies, @FF, in die richting gingen mijn gedachten. Maar de details zijn nog lang niet aan de orde.

Even voor de goede orde: Op de I2C bus, als de primaire machine kapot gaat waardoor ie "spanningsloos" wordt, die gaat dan effectief een diode-naar-ground op de i2c pin laten zitten. Jij kan best zeggen: "Maar ik geef de backup gewoon power".... Sure! maar wat nu als de powersupply van de eerste de geest geeft, dan wil ie overnemen, maar de bus wil niet meer boven de 0.6V uitkomen. Jammerdan!

Ook wat Arco (of iemand anders?) beschrijft gebeurt wel eens. Een I1C implmentatie die in een rare state terecht komt. Bijvoorbeeld, de raspberry pi CPU heeft een implementatie van i2c met een bug er in.

Als ie een stukje data verstuurt, dan wacht ie na het 8e bit op een ack. De slave mag als ie langer de tijd nodig heeft om er over na te denken wait cycles introduceren. Dus op het moment dat de normale acktijd op z'n end loopt, kijkt ie of de CLK lijn hoog geworden is want dan was er geen extra waitstate nodig.

Als nu de geadresseerde slave precies na 0.9, 1.9 of 2.9 periodes denkt: ok, genoeg tijd gehad, hij mag weer verder, dan begint het signaal met omhoog gaan, is precies op 1.0, 2.0, of 3.0 dus "hoog" (volgens de pi met 3.3V-gerefereerde spanningsniveaus) en dan gaat ie verder door direct de clk lijn weer laag te trekken. Als het "hoog worden" van de clk lijn instantaan zou zijn (en dat is ie niet) dan is er een clk pulsje van 0.1 clock geweest. Dat is theoretisch te kort om betrouwbaar te werken en werkt soms in de praktijk ook gewoon NIET.

Als dit gebeurt, heeft de slave dus 1 clock pulsje minder gezien op de bus en blijft tot de eerstvolgende clock pulse zijn ACK sturen: Bus data blijft laag. Het systeem hangt. In dit geval is het de slave die de databus laag blijft houden, terwijl de pi eigenlijk de schuldige is.