I2C tussen Raspi, Arduino, ESP32

Er zijn I2C lever converter printje te koop, maar het zijn dacht ik 4 weerstanden en 2 fets.
IK die zelf ook toegepast om een 5V Display te laten werken op een Arduino due die op 3,3V werkt.

De standaard weerstanden zijn vaak net iets te groot zeker voor hoge snelhden mogen die een stuk kleiner. Ik heb 3k3 genomen.
I2C is niet voor lange afstanden maar voor printplaatjes in een kleine behuizing werkt dat prima. Afhankelijk van de snelheid is het maximaal 50cm maar ik zou het zo kort mogelijk houden.
De FET is ook niet kritisch. IK had eerst een fetje genomen die 68mA aankon omdat ik die nog had liggen maar dat bleekt tocht te weinig te zijn. IK heb nu een beest die ruim 4A aankan en dat in die kleine sot23 behuizing. Die had ik ook nog liggen haha.

[Bericht gewijzigd door benleentje op vrijdag 18 november 2022 23:43:40 (18%)]

Je kunt ook simpelweg de interne pull-ups van de Arduino niet aanzetten, of de Arduino ook op 3v3 laten lopen, maar dan zou je wel even op moeten zoeken of hij de dan op 16MHz mag lopen.

De oplossing met BSS138 is duplex verkeer. In de meeste gevallen werkt het wel. Enkele dagen geleden toch serieus aan het zoeken geweest. Een ESP32 kreeg geen gegevens van een 433MHz ontvangertje. Volgens de scoop werden de waardes nochtans goed doorgegeven. BSS en weerstanden er tussenuit en 433MHz ontvanger rechtstreeks aangesloten. Het werkte. Uiteindelijk het werkende gekregen door aan ESP zijde de weerstand weg te laten en de interne pullup hoog te maken.

Bij uitsluitend uitgaande verkeer gebruik ik meestal een 74HCT1G126 met de nadruk op de T van TTL compatibel.

Uitsluitend inkomend kan je een 74LVC1G32DBVR gebruiken.

Duplex is TXB0101 ook een mogelijkheid.

Hier de officiële documentatie, werkt fantastisch!

[Bericht gewijzigd door Vonkenpromotor op zaterdag 19 november 2022 08:29:21 (25%)]

Op 19 november 2022 05:35:35 schreef SparkyGSX:
Je kunt ook simpelweg de interne pull-ups van de Arduino niet aanzetten, of de Arduino ook op 3v3 laten lopen, maar dan zou je wel even op moeten zoeken of hij de dan op 16MHz mag lopen.

Interne pull-ups zijn veel te zwak, voor standaard 400kHz zou ik 2k2 nemen...
Die arduino's zullen toch ook wel op 3.3v werken? (5v is niet echt meer van deze tijd...)

De oudste arduino types werken met een AVR. Voor compatiblity met NOG oudere AVRs werken die met een 16Mhz kristal. En die AVRs die er nu in zitten mogen maar 11.6 MHz bij 3.0V (het officiele minimum van 3.3V Nominaal).

Je kan ook gewoon een pullup naar 5V doen. Maar dan een scottky diode naar de 3.3V. De spanning wordt dan iets hoger dan 3.3V, maar niet genoeg om de protectie diodes in de pi aan te spreken.

Level converteren kan met I2C prima met dat circuitje hierboven. Je zou het ook kunnen doen met SPI, dat converteert wat logischer aangezien je geen bidirectionele bus hebt. Naar beneden kan gewoon met een R-deler, omhoog met een fetje of zo.

PS, je (TS) hebt het over "met elkaar communiceren". Zowel bij i2c als spi heb je 1 master en de ander is slave. Dwz, de een communiceert met de ander, die bepaald wanneer er data heen en weer gaat. Is dat de bedoeling?

[Bericht gewijzigd door flipflop op zaterdag 19 november 2022 09:56:02 (32%)]

@Vonkenpromotor: dank voor dat officiele document, het dateert weliswaar van 2007... Het schema dat daar wordt voorgesteld gelijkt verdacht veel op wat @Benleentje postte

@rew: dank voor de achtergrondinfo!

@flipflop: (beetje van het onderwerp weg...)
Ja, het basisconcept is dat er twee raspi's zijn in een failover-configuratie, eentje actief, de ander standby. De actieve Raspi wordt master op de I2C-bus, de Arduino's en/of ESP32's worden slave.

@allen: ik speel het maar veilig en "standaard" en bestel me van die level-shifter printjes.

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 zaterdag 19 november 2022 14:30:37 (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 zaterdag 19 november 2022 14:32:34 (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...