Hallo zusammen,
Frage 1: ich habe ein System mit Mega328 was einige I2C Slaves (2
Displays, EEPROM, Sensor) abfragt/mit Daten versorgt und auch 1A
funktioniert. Jetzt sind nicht immer alle da oder auch "plötzlich" weg -
das fangen die normalen libs nicht ab oder? Wie macht man das am
sinnvollsten?
Frage2: das System sollte Stromausfälle überleben, dann jedoch stellt
sich wieder das Problem aus 1, denn ich will die I2Cs nicht weiter
versorgen, nach dem Stromausfall aber wieder "hochfahren"?
Danke, euer Gunther.
Gunther schrieb:> Jetzt sind nicht immer alle da oder auch "plötzlich" weg -> das fangen die normalen libs nicht ab oder? Wie macht man das am> sinnvollsten?
Nimm eine Lib, die zurück meldet, wenn niemand antwortet.
Bei Stromausfall eines Slaves musst du sicher stellen, dass des der Bus
nicht durch einen dominanten Pegel blockiert.
Gunther schrieb:> Wie macht man das am> sinnvollsten?
Man setzt I2C nicht in Umgebungen ein, in denen Master und Slaves
verschiedene Versorgungen haben. Dafür war das Protokoll nie gedacht
(und ist de facto aus physikalischen Gründen auch nicht dafür geeignet).
> Frage2: das System sollte Stromausfälle überleben
Tut es. Sofern alle Devices halt gleichzeitig ableben und gleichzeitig
wieder neu erweckt werden.
...sry, war ggf nicht präzise genug: Der M328 soll weiter laufen, die
I2C Slaves aber nicht. Mal abgesehen davon, ob es nicht dafür gedacht
ist (was ich weiß) - geht es?
Man bräcuhte also libs die nicht mit "while" arbeiten und muss dort
einen "Notfall timer" haben. Ggf muss man die retrys pro Slave zählen
und diesen komplett im Ablauf deaktivieren, wenn er sich nicht meldet.
Und falls man einen Stromausfall erkennt (2s kann ich die Slaves auch so
puffern) - dann schnell alle COM beenden und das "COM_enable" flag auf
FALSE setzen, bis wieder Strom da und dann die "inits" neu aufrufen,
danach "COM_enable" auf TRUE und weiter gehts...oder?
Richtig spannend wäre "pseudo hotplug" des E² :) (Ggf mit Menüoption "E²
wechseln, was dann COM stoppt)
Gunther.
...hmpf, OK. Danke! Ich puffer erstmal mit LiPo, das System braucht nur
50mA da hält ne 18650 ne Weile. Ist halt schon fertig (natürlich "non
commercial") , da strickt man ungern um - und soooo wichtig ist mir die
Robsutheit auch nicht gewesen :)
Gunther.
Gunther schrieb:> ...sry, war ggf nicht präzise genug: Der M328 soll weiter laufen, die> I2C Slaves aber nicht. Mal abgesehen davon, ob es nicht dafür gedacht> ist (was ich weiß) - geht es?
Ganz sicher nicht zuverlässig. Ein Slave ohne Versorgung wird nämlich
typisch über seine Schutzdioden aus den I2C-Pullups gespeist. Das ist
nicht gut für den Slave und auch nicht gut für die Funktionsfähigkeit
des Busses, denn es besteht natürlich die sehr reale Möglichkeit, dass
der/die toten Slaves den Bus völlig funktionsunfähig machen...
Das hat noch nichtmal was mit irgendwelchen Libs zu tun...
Wie gesagt - ich kann ja 2s puffern (über Elko), dann merke ich dass
extern keine Spg mehr da ist und fahr den GESAMTEN I2C geordnet runter
(siehe flags) und initialisiere dann wieder, wenn alles wieder iO ist.
Aber die Faulbärlösung ist gerade die 18650er, die ich dauerhaft mit
~3,5V Systemsg beaufschlage. Mal sehen, wann sie mir das übel
nimmt...dann kann ich erstmal in Ruhe prüfen, wie robust das ganze wird.
Gunther.
Gunther schrieb:> Wie gesagt - ich kann ja 2s puffern (über Elko), dann merke ich dass> extern keine Spg mehr da ist und fahr den GESAMTEN I2C geordnet runter
Was soll das bringen? Deine Situation ist doch, dass der Master versorgt
ist, aber einige oder alle Slaves nicht, wodurch zumindest einige
Slaves, recht wahrscheinlich aber auch der gesamte Bus funktionsunfähig
werden.
Wenn irgendwas sinnvoll ist (wirklich sinnvoll wäre natürlich nur ein
geeignetes Bussystem) dann wäre es einzig die Überwachung der
Versorgung(en) der Slaves. Da braucht dann aber nix gepuffert zu werden,
das ist eine triviale Messung, z.B. mittels ADC.
Blöd ist halt nur: man braucht dann eine Strippe zu jeder
Slave-Versorgung...
>Blöd ist halt nur: man braucht dann eine Strippe zu jeder>Slave-Versorgung...
Damit könnte man dann die Slaves auch gleich versorgen.
Problem gelöst. Alles andere ist Quatsch. I2C unterstüzt kein
Hotplug. Jeder Slave ohne Stromversorgung wird wie schon gesagt
im besten Fall den Bus massiv stören oder komplett totlegen. Da hilft
nix.
holger schrieb:> I2C unterstüzt kein> Hotplug.
Doch, natürlich geht das.
Ich muss ja jedesmal wenn ich einen I2C-Slave anspreche erstmal seine
Adresse senden. Und da bekomme ich ein Ackn. Bekomme ich kein Ackn, ist
der Slave nicht da.
Im µC mache ich mir ein Flag. Ist das Flag false, spreche ich alle paar
Sekunden die Adresse an. Antwortet der Slave, initialisiere ich ihn und
setze das Flag true. Dann frage ich ihn ganz normal ab. Bekomme ich bei
einer der Abfragen kein Ackn, ist der Slave weg. Dann setze ich das Flag
false und beende die Übertragung bis zur nächsten Abfrage.
Natürlich kann ein Slave beim Anstecken eine gerade laufende Übertragung
eines anderen Slaves kurzzeitig stören. Da muss man entscheiden ob das
kritisch ist.
Zur Akkuschonung Slaves abschalten würde ich so machen: Vcc aller Slaves
und die Pull-Ups über einen Portpin + Transistor abschalten. I2C-Pins
auf Eingang und tristate.
Ja, natürlich betrifft das IMMER ALLE Slaves an einem Bus. Aber das ist
auch Sinn der Sache. Will man Slaves nicht abschalten, zum Beispiel eine
RTC, bekommt die einen zweiten Bus.
Klaus schrieb:> Und da bekomme ich ein Ackn. Bekomme ich kein Ackn, ist> der Slave nicht da.
LOL, so weit kommst Du nicht wenn der Slave keinen Strom hat.
Denn praktisch alle Slaves (wenn sie nicht von NXP sind) ziehen ohne
Stromversorgung die Busleitungen auf Masse. Dann kannste nicht mal das
Start Signal senden, geschweige denn Adresse o.ä.
Die meisten I²C Master implementierungen hängen sich dann einfach auf.
Falls das ein Erwachsener implementiert hat, gibt es u.U. ein Timeout
oder ein "Arbitration lost" Signal.
Gunther schrieb:> Man bräcuhte also libs die nicht mit "while" arbeiten ...
Libs sind Software und I2C ist nun wahrlich nicht so kompliziert, dass
man soetwas nicht selber entsprechend den eigenen Anforderungen
schreiben kann.
> ... und muss dort einen "Notfall timer" haben.
Wie lange willst du denn auf das Ack warten?
Jim M. schrieb:> Denn praktisch alle Slaves (wenn sie nicht von NXP sind) ziehen ohne> Stromversorgung die Busleitungen auf Masse. Dann kannste nicht mal das> Start Signal senden, geschweige denn Adresse o.ä.
Genau, deshalb gibt es die Möglichkeit z.B. per zusätzlichem
Pegelshifter den Slave vom Bus zu entkoppeln. Das funktioniert auch bei
Stromausfall des Slaves - ohne das SDL/SCL gleich auf Masse gezogen
werden.
https://www.mikrocontroller.net/articles/I2C_als_Hausbus
c-hater schrieb:> Gunther schrieb:>>> ...sry, war ggf nicht präzise genug: Der M328 soll weiter laufen, die>> I2C Slaves aber nicht. Mal abgesehen davon, ob es nicht dafür gedacht>> ist (was ich weiß) - geht es?>> Ganz sicher nicht zuverlässig. Ein Slave ohne Versorgung wird nämlich> typisch über seine Schutzdioden aus den I2C-Pullups gespeist. Das ist> nicht gut für den Slave und auch nicht gut für die Funktionsfähigkeit> des Busses, denn es besteht natürlich die sehr reale Möglichkeit, dass> der/die toten Slaves den Bus völlig funktionsunfähig machen...>> Das hat noch nichtmal was mit irgendwelchen Libs zu tun...
So allgemein formuliert, stimmt die Aussage nicht. Slaves welche sich an
die Spezifikation halten, dürfen auch ohne Versorgung den Bus nicht
beleidigen. Aber ja, es gibt viele, die sich nicht an die I²C Spec
halten. Also wenn man g'scheite, spec-konforme Slaves hat, geht das sehr
wohl. Muss man im Einzelfall testen.
