I2C tussen Raspi, Arduino, ESP32

Heb je al bedacht wat er gebeurd met een unpowered device op een I2C bus?

Redundante RasPi's, het moet niet gekker worden.

Wie heeft gezegd "unpowered"? De inactieve raspi blijft wel degelijk onder power, hij moet immers kunnen overnemen als de actieve eruit gaat.
Wie heeft gezegd "redundant"? Zonder reden zit die daar niet, dat zou inderdaad al te gek zijn. Maar het is dus niet.

Ik zou echter liever niet te ver afdwalen van het aanvankelijke onderwerp.

In ieder geval 1k5 of 2k2 nemen op 400kHz, anders is de communicatie niet betrouwbaar (op 100kHz kan 4k7 ook nog wel)
Bij nog snellere bus wordt de waarde uiteraard nog lager...

En als die actieve RasPi de geest geeft dan?

Tegen welke failure modes wil je beschermen? Je kunt roepen dat dat niet het onderwerp was, maar dat heeft wel degelijk invloed op de keuzes voor die I2C bus.

Hebben ze een eigen voeding? Verschillende software? Hoe detecteer je een failure? Wat als die Arduino faalt? Wat als één van die devices zodanig faalt dat de bus permanent hoog of laag blijft, constant onzin blijft spuwen, of nog erger, een overspanning op de bus veroorzaakt?

Ik heb dat met een slave gehad... (die trok soms de bus naar beneden en wilde 'm niet meer vrijgeven...)

@Arco: de frekwentie kan erg laag blijven, er is maar heel weinig informatie uit te wisselen, en de snelheid is niet superkritisch - het gaat over een soort van domotica-toestand.

@Sparky: failure modes had ik nog niet bekeken, zelfs nog niet aan gedacht. Ik heb zero ervaring met I2C dus er zullen toch enkele versies elkaar moeten opvolgen, telkens ter verwerking van opgedane ervaring.

Voorlopig is mijn vraag beantwoord, dank aan allen!

Ongeacht de snelheid moet de rise/fall time binnen de specs blijven (1000 resp 300ns). Die hangt af van de pull-ups en de busbelasting.
Voor cpu intercommunicatie gebruik ik meestal de uart; makkelijker en er is geen master.

Voor cpu intercommunicatie gebruik ik meestal de uart; makkelijker en er is geen master.

Hm, dat zou wel eens iets kunnen zijn - beetje jammer dat het niet eerder kwam. Mijn allereerste vraag was naar een alternatief voor I2C, maar ik kwam niet verder dan het draadloze gedoe en dat is nog complexer.

Voldoet uart-gebruik aan mijn andere verlangens?
* meerdere deelnemers, minimaal drie
* gemengde voedingsspanningen 5V= / 3,3V=
Heb je daarvan een voorbeeld?

Heb je daarvan een voorbeeld?

Nee,

Ik gebruik (gelukkig... :) ) alleen pic's (en gewone pc's)
Aangezien de rest slaves zijn, kun je die gewoon aan de tx van de master knopen...

Er zijn veel verschillende bussen, voor verschillende toepassingen.

SPI, I2C e.d. zijn niet bedoeld om "van de print af" (of uit de kast) te komen, ze gaan uit van een gezamelijke gnd, weinig capaciteit en interferentie, geen ESD. Interfaces die geschikt zijn om van de print af te komen moeten echter common-mode bestendigheid hebben, overweg kunnen met kabels, robuust zijn tegen ESD, etc.

Voor een bedrade, relatief trage, domotica achtige toepassing met beperkte common mode spanningen (nodes in een huis, verder geisoleerd, gedeelde gnd) en kleine microcontrollers niveau Atmega 328 (met een kristal) zou ik denken aan RS-485 over een UTP pair met een of ander simpel protocol.
Er bestaan zowel 3,3 V als 5 V tranceivers voor, maar dat lijkt niet zo een belangrijk criterium. Levelconverters zijn een normaal verschijnsel. Er zijn nu tranceivers die zelf al een zware ESD beveiliging aan boord hebben, lekker simpel.
Als het handig uit komt in een node met veel i/o aan de netspanning is de tranceiver eenvoudig met een paar optocouplers en een DC/DC convertertje te isoleren.

Voor een Beest van een controller zoals een ESP32 zou ik echter eerder denken aan bedraad ethernet, anders lijkt het wat zonde.
Voordeel van ethernet is dat het met transformatoren galvanisch gescheiden is. Voeding kan dan eventueel POE zijn, waarvan de converter ook gescheiden behoort te zijn.

De ESP32 is een WiFi tranceiver: een beetje krom om die voor bedraad ethernet te 'misbruiken'... :)

Er zijn nauurlijk veel dikke microcontrollers met ethernet. Maar hij is goedkoop, populair, als module verkrijbaar, heeft de hardware aan boord en het werkt prima.

( Ik houd zelf niet van Wifi en niet van domotica :+ maar ik maakte ooit toen hij net nieuw was een boardje met een ESP-32 en ethernet )

[Bericht gewijzigd door Aart op (16%)]

(Ik houd zelf niet van Wifi en niet van domotica :+

Grijns :+ Ik houd ook niet van WiFi maar in dit project zal ik er niet onderuit kunnen, vrees ik; het alternatief is een klein fortuintje aan koperdraad. En nee, domotica is ook mijn ding niet, maar het werd me zo lief gevraagd dat ik toch maar eens bekijk of ik iets zou kunnen. Let wel het gaat NIET om standaard-domotica, dan had ik wel een standaard-antwoord gezocht.

En voor de volledigheid: mijn huidige vraag betreft minstens twee raspi's en minstens een esp32 of nano, allemaal in een enkele kast. Anders had ik ook niet aan I2C gedacht. RS485 lijkt dus overkill.

[Bericht gewijzigd door Paulinha_B op (19%)]

Ik knoop microcontroller, remote-IO modules, motordrives, etc. doorgaans aan elkaar met CAN bus, maar ik ben ook gewend dat te gebruiken vanuit mijn Automotive achtergrond. Groot voordeel is dat je van alles aan elkaar kunt knopen, ook relatief kleine microcontrollers (STM32F0/1/3/4) hebben meestal wel één of meerdere CAN bus controllers. Nadeel is dat USB-CAN converters vaak vrij prijzig zijn, rond de 250 euro is vrij normaal.

[offtopic]

Er is tegenwoordig goedkope niet-koperen (CCS, CCA e.d.) UTP bedrading die hier allicht zou volstaan. Wat kost het als het niet goed werkt?

Als mij zoiets gevraagd werd zou ik het simpelweg weigeren. De kans dat de vraagsteller net niet precies beseft wat voor ellende het is lijkt aanzienlijk.

Op 19 november 2022 12:08:18 schreef Paulinha_B:
..Wie heeft gezegd "redundant"?..Ik zou echter liever niet te ver afdwalen van het aanvankelijke onderwerp.

Door het noemen van je doel ga je juist niet verder van het onderwerp. Dat doel is namelijk heel erg bepalend van de keuze van een bus. Maar ik geloof dat dat inmiddels al duidelijk geworden is :-)

Het UART idee snap ik niet helemaal. Daar zul je toch ook 2 masters hebben in dit geval. Hoe gaan die 2 dan bepalen wie het TX touwtje gaat driven?
De term RS485 kwam voorbij... dat is het nog niet eens zo'n gek idee. Daar kun je immers meerdere masters hebben waarbij alleen de zender de bus drive't (hoe schrijf je dat???). De rest luistert. Wordt misschien wel vervelend met die level shift...

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.