Posts by WillyR_aus_C

Guten Morgen

Quote from DeaD_EyE

Bare-Metal auf dem RPi0

Ich verstehe die Aussage als technischer Hintergrundinformation, aber mehr auch nicht.
Entschuldige, ich kann in den Beiträger den TO nicht erlesen das er einen PI-Type hat, welche für diese Auskopplung von CircuitPython verwendet werden kann. Wenn du meine Ausführungen bis zum Ende durchgelesen, und vor allem verstanden hättest hatte ich hier zu ein ganz klare Aussage gemacht.
Wer auf Adafruit Treiber, wie für diese I/O Platinen auch angeboten werden, und im eigentlichen Sinne noch Python nutzt, nur diese Adafruit CircuitPython Treiber, wird wenn er nicht selber die Treiberbibliothek für den MCP23X17 programmieren will, immer der langsamere sein. Wenn dann solche Python Module wie BOARDIO dazukommen, wieder wie schon geschrieben mit Python als Interpreter, wird immer im Timing den kürzeren ziehen. Und dann ist es noch eine Auswertungssache, bzw auch ein Kompatibilitätssache, die hier eine Rolle spielt. Zudem welchen Aufwand der TO betreiben möchte. Schneller als ein reines C-Programm kann er nicht werden. Außer er proggt das PI in Assembler. Und trotzdem wirst du auf einen zusätzlichen I2C Bus der via /boot/config.txt bereitgestellt werden kann niemals die maximal mögliche Übertragungsrate hinbekommen, wie sie über den Standard I2C Bus an GPIO02/03 möglich ist, schon gar nicht mit einer tatsächlichen Clock-Rate über 400 kHz. Hier hilft ein Oszilloskop bei der Überprüfung der realen Werte.

Ich gebe dir dahingehend recht, wenn du einen Mikrocontroller ins Spiel bringst, und sagst du steuerst diese vielen MCP's alle mit einem PICO oder ESP, und leitetes die Daten für eine Ausgabe / Anzeige über einen weiteren Kanal zu einem PI oder weiteren Mikrocontroller weiter welcher nur die Visualisierung / Interaktionsfähigkeit via Touchdisplay ermöglicht. Denn auch in den Mikrocontrollern ist bei dieser Menge an externen I/O GPIOs nur noch sehr wenig Platz ( RAM ) um hier aufwendige Inaktionsmodelle abzulegen, aber rein von der Abfrage der Portregister haben diese Mikrocontroller noch sehr viel Luft nach oben. Bei einem RasPi Pico kann man hier volle Kanne auch über 2 Bus-Hosts die Clack-Rate sogar bis weit über 1,2 MHz hochtreiben, ohne das dieser in Schleudern kommt. Das macht dann natürlich einen Unterschieden in der Abfrage, und der benötigten Durchlaufzeit wenn ich aus dem Rückmeldung(en) auswertenden MCP23017(s) diese mit 1,2 MHz auslesen kann, und somit ein einem Dritte der Zeit an die Info komme, welchen MCP23S17 auf welches Portregister ich dann mit über 3 MHz Clock Rate abfragen kann. Und da spielt auch der langsamere PCF8574 wenn diese Ausbaustufe erreicht werden sollte kein Rolle, oder dann doch der GPIO.Falling Event - denn für diese IRQ Event Detektierung benötige ich nur ca. 50ns auf einem 133 MHz getakteten PICO. Damit hat man das sehr viel Luft, oder Zeit das entsprechende Portregister auszulesen. Selbst wenn man auf einen MCP23017 als Rückmeldungssammler angewiesen ist. Denn der MCP23x17 reagiert innerhalb von 52 ns auf diesen Input Event, mit einer Signalausgabe über die INT Ausgänge.

Es nützt auch keinem etwas, wenn man von der Grundkonfiguration des normalen RasPi mit RaspbianOS ausgeht, hier superschnelle Bibliotheken zu nutzen, die selber ohne Anpassung der Bus-Geschwindigkeit nicht wirklich zum tragen kommen. Du kannst es gerne probieren, nimm ein 4er PI, einen MCP23017 und einen MCP23S17 und versuche diese in der Grundeinstellung des OS mit der maximalen Clock-Rate zu betreiben. Selbst mit C++ Programmen wirst du ohne einen tieferen Eingriff in das System diese Chips niemals bis zu ihrer Geschwindigkeitsgrenze ausreizen können.

Damit ist die Diskussion für mich ohnehin obsolet, wenn der TO nicht gewillt ist, oder in der Lage ist sich anhand der Datenblätter egal für welches Programmiersystem er sich entscheidet, hier mit irgendwelchen CircuitPython Ablegern zu kommen, wenn ihm die Programmierkenntnisse fehlen. Da die meisten User ohnehin auf Fertigbibliotheken oder -treiber zurückgreifen, die ihnen eine maximale Flexibilität bieten, und somit auch recht einfach zu handhaben sind, steht hier der Grundsatz einer Anwendungs- und Geschwindigkeitsoptimierten Single Lösung wohl auch gar nicht zur Debatte.

Jedoch auf Grund seiner Fragen und Nachfragen, sowie der Eingangsfrage gehe ich davon aus, das der TO nicht über solche umfassenden Programmierkenntnisse verfügt, wenn er schon mit den Dingen Probleme hat, wie erweitert man ein solches Array aus 8 x MCP23017 um noch einmal die gleiche Anzahl MCP23017. Wobei dann hier auch die Frage ist und bleibt, wie bekommt man ohne extremen RasPi GPIO Belegungsaufwand eine solche Interrupt Rückmeldung gehändelt. Denn egal was man macht oder treibt, man hat nur die (langen) 20ms Zeit auf den gemeldeten Event über INT_A oder INT_B, oder eine Vielzahl dieser zu reagieren, sonst ist auch abhängig / ggf einer kürzeren To-Low Schaltphase der Portregistereintrag wieder in dem Status den der Eingang nun real hat. Ja, 20 ms sind verdammt viel Zeit. Aber hier muss der Prozessor oder Mikrocontroller auch reagieren können. Und bei der Vielzahl an möglichen Rückmeldern 2 x 2 x 8 = 32 GPIOs wird es beim PI verdammt eng
Ebenso schafft man es mit Polling nicht, über einen nur mit 100 kHz laufenden I2C Bus inkl. der Umschaltzeiten 32 einzelne Portregisterabfragen durchzuführen und auszuwerten, wenn man auf die Interpretersprache Python setzt, um innerhalb dieser 20 ms pro Portregister zu bleiben -> hier jetzt nur die reine fortlaufende Abfrage aller möglichen 32 Portregister ohne die Nutzung der Rückmelder INT_A und INT_B.

Da wir aber alle kein haben, und nicht vorhersagen können wir der TO diese seine Steuerung programmiert hat, und welche Programmiersprache er verwendet, können wir uns hier noch Stunden in spekulativen Diskussionen üben, es wird den TO nicht wirklich weiter helfen.

Guten Tag,

Quote from DeaD_EyE

Eine weitere Möglichkeit wäre die Verwendung von CircuitPython (bare metal) auf dem RPi Zero (W2).

eine sehr langsame API.
Im Vergleich mit Python und SMBus sind diese Adafruit Treiber im Verhältnis zur direkten Nutzung von SMBus, SPIDEV bis zu 8 mal langsamer.

Quote from DeaD_EyE

Ein Mikrocontroller wäre da flexibler.

Gebe ich dir dahingehend recht, nur ist der

Quote from DeaD_EyE

RPi Zero (W2)

kein Mikrocontroller !
Auf einem Raspi Pico mit einem RP2040, der über zwei I2C Hardware Hosts verfügt, oder in der Erweiterung SPI, auch hier wieder mit zwei Hosts daher kommt, kann man das natürlich viel schneller abwickeln als mit einem PI. Das Pi mit einem Linux-Kernel, als Unterbau, schafft im SPI Mode auch nur knappe 3,5 MHz Clock-Rate. Der nicht übertaktete RP2040 spielt hier noch bis 8 MHz mit, was aber immer noch nicht dem entspricht, mit was ein MCP23S17 betreiben werden könnte ! -> Clock-Rate-Limit 10 MHz !

Da hier aber vom TO Crys die Auswertbarkeit der INT_A und INT_B Event-Rückmelder angesprochen wurde, brauchst du mit dem langsameren Code von CircuitPython gar nicht anfangen, wenn du mehrere dieser Portexpander auf solche Events triggern willst. Das habe ich schon ausprobiert. Der dazugehörige Adafruit Code ist einfach zu langsam, da können einem einzelne INPUT Events, besonders wenn diese von elektronischen, nicht prellenden Schaltquellen stammen, durch die Lappen gehen, sowie eine Mehrfach-Eingabe (das zeitgleiche betätigen mehrerer Taster an verschiedenen Stellen über mehrere MCP23017 verteilt) bekommt man gar nicht ausgewertet.

Oder man ist so Krank, entschuldige bitte das Wort, dass man auf dem BUS herumpollt. Nur dann bleibt nur sehr wenig CPU-Zeit über, um andere Dinge auszuführen, z.B. eine grafische Display-Ausgabe zu gestalten. -> Die Betonung liegt bei dieser, deiner Aussage in der Verwendung von CircuitPython auf einem RasPi mit einem Linux Kernel Unterbau, und der Nutzung der dazugehörigen ADAFRUIT Treiber. Unter / mit C/C++ ist das ein ganz andere Sache.

Guten Tag

Quote from Crys

Im jetzigen Ausbauschritt benötigen wir 52 Ausgänge. Hierfür benötigen wir ja keine "Kontrolle" per INT!?
Also sollten diese 4x MCP23017 I2C Boards funktionieren.

Als reine Output Einheiten , absolut kein Thema.

Quote from Crys

Des Weiteren werden aber im jetzigen Ausbauschritt auch 48 Eingänge benötigt. Also 3x MCP23017 die zusätzlich 6x GPIO Pins für die INT auf dem Raspberry benötigen.
Ist das soweit korrekt?

Theoretisch soweit richtig.
Ja, man kann es mit 6 GPIOs lösen, aber man muss sich in dem Falle auch klar sein, was das für mögliche Konsequenzen mit sich bringen kann. Hier spielt die Programmiersprache eine entscheidende Rolle. Wenn du das relativ langsame Python verwendest, sind 6 IRQ Events schon eine gewaltige Herausforderung. Da bist du selbst über den Zwischenschritt eines reinen als INPUT arbeitenden Expanders wie dem gleichschnellen MCP23x08 ( nur 8 Ports ) unter dem Strich nur auf ein Event / INT GPIO zu reagieren, -> diesen Zwischen-Expander als INT Auswerter auszulesen, und dann gezielt den Port des betreffenden großen Expanders sogar schneller, und du hast eine minimal größere Latenz, als wenn du nur einen Expander direkt über die GPIOs abfragst. Hier entstehen minimale Zeitbereichsüberschneidungen die man sich zu Nutze machen kann. Aber wieder das Problem bei I2C, wenn du den Adressraum der MCP230yy am Standard I2C Bus ( verbunden mit den PIns 3 + 5/ GPIO 02/03 ) ausgereizt hast, und auf einen zweiten I2C Bus ausweichen musst, bringt dieser nicht die volle Geschwindigkeit in der Datenübertragungsrate. Je nach PI Modell ist dieser bis zu 70 % langsamer !
Und damit rückt diese 20ms Zeitfenster in eine fast nicht zu erreichende Entfernung. Hier spielt auch die Programmiersprache nur eine untergeordnete Rolle.

Da deine Anfrage in der Überschrift gezielt die Aussage "16 x MCP23017 am I2C" enthielt, muss man sich auch im klaren sein, der Hardware unterstütze I2C Bus an den GPIOs 02/03 läuft standardmäßig nicht mit der maximal möglichen Übertragungsrate mit der ein MCP23017 betreiben werden könnte. Diese müsste man dann in der /boot/config.txt entsprechend Anpassen, oder Erhöhen.
Jedoch dann ist der Bus auf diese Geschwindigkeit festgenagelt und es kann Probleme mit weiteren I2C Komponenten wie Display, ADCs usw. geben, die nicht für diese Geschwindigkeit ausgelegt sind.

Quote from Crys

Dies sollte also mit einer I2C Daisy Chain möglich sein?
(Zwei, wenn man "der Ordnung halber" I/O trennt.)

Wie schon gesagt, an einen I2C Bus - egal ob über die GPIOs 02/03 und dann weitere GPIO Paare kannst du nur 8mal den MCP23017 hängen, denn mehr Adressen sind über A0-A2 nicht direkt ansprechbar ! Selbstverständlich kann man auch einen Multiplexer dazwischen schalten, um pro Multiplexer- Ausgang weitere 8er Paarungen dieser MCP23017 anzuhängen. Es ist eine Möglichkeit den grundsätzlich schnelleren I2C Bus zu erweitern, du verlierst aber trotzdem Zeit. Zudem, diese Multiplexer sind mit max. 400 kHz Clock-Rate auch keine Rennwagen Der MCP23017 schafft bis 1,7 MHz, was über den Multiplexer betrieben nur ein Bruchteil der möglichen Datenübertragungsrate darstellt.
Du könntest die reinen OUTPUT MCP23017s auf den zweiten langsameren I2C Bus hängen, was keine Auswirkungen auf die INPUT MCP23017s hätte. Aber irgendwie komme ich mit deinen Zahlen 16 x 16 I/O GPIOs ( 256 GPIO Ports in der Summe ) und den genannten "52 Ausgänge" und "48 Eingänge benötigt" nicht ins Geschicke -> Das sind bei mir nur sieben (7) MCP23017s !?
Alternativ kannst auch den Weg gehen, was aber einen Totalumbau erfordern würde, wenn du unbedingt bei diesen Portexpandern bleiben möchtest.
Du nimmst einen PCF8574, den du mit 400 kHz betreiben kannst, NXP Modelle (nicht die alten noch mit Philips-Logo, oder die von Texas Instruments -> die schaffen nur 100 kHz) und schaltest damit via I2C die CS Signale für den SPI-Bus. Pro CS Kreis kannst du 8 dieser MCP23S17 anschließen -> also kommst du auf maximal 8 x 8 x 16 GPIOs = 1024 I/O Ports. Und kannst diese wiederum vermindert auf die Anzahl der mit Eingängen belegten einzelnen MCP23S17 zur INT Auswertung auf die MCP23017 legen, wo du pro MCP23017 immerhin 8 dieser MCP23S17 auf einen INT Event -> Weiterleitung zu den GPIOs des RasPi abfragen könntest. Der PCF8574 verursacht keinen Adressenkonflikt mit den anderen I2C Portexpandern, und zum Schalten und halten des CS Signals ist dieser ausreichend schnell.

Guten Tag,

du @Crys hattest mich zum MCP23017 schon in einem anderen Thread angesprochen.
Sorry wenn ich das so sagen muss, mit der I2C Variante hast du auf das falsche Pferd gesetzt.

Du kannst mit einem I2C Bus nur 8 dieser MCP23017 betreiben, dann musst du entweder auf einen weiteren via /boot/config.txt hinzugefügten I2C Busse ausweichen, aber bekommst dann ein weiteres Problem, und das ergibt sich offensichtlich aus der anderen Nachfrage. Wie willst du dann für bis zu 16 dieser MCP23017 = 32 mögliche GPIOs bereitstellen, wenn du schon 4 GPIOs nur für die I2C Anschlüsse SDA + SCL benötigst ? Oder du weichst auf einen Multiplxer aus / um. Aber alle diese Lösungen kosten Zeit.

Um z.B. 2 x 8 MCP23S17 (SPI) Portexpander zu steuern, benötigst du nur einmal den MOSI, den MISO und den SCLK, aber zweimal den CS. So nun kommt aber wieder das Problem zu tragen, wie willst du resultierend daraus, die möglichen 2 x 2 x 8 INT_A und INT_B Rückmelder abfragen ? Dir läuft irgendwann die Zeit davon, zumal der SoftI2C für die nächste 8er Gruppierung an MCP23017 ohnehin viel zu langsam ist, um hier noch auf irgendwelche Taster-Events an den als Eingänge genutzten Port-Pins zu reagieren. Wenn das Eingangssignal "Taster gedrückt" nicht länger als 20 ms Bestand hat setzt der MCP23x17 diesen INT Ausgang wie auch das abzufragende Portregister automatisch wieder auf den Ausgangszustand, bei einem Input = Pegel HIGH = kein Taster gedrückt.

Bei der SPI Variane 2 x 8 MCP23S17 mit zwei direkt über die GPIO-Leiste geschalteten CS Pins, aber mit 2 x MCP23017 am Master I2C des PI ( Pin 3+ 5) und wieder nur 2 GPIOs zur INT Detektierung als Weiter- oder Durchleitung durch die MCP23017 hättest du noch zeitliche eine reelle Chance auf diese INTs der SPI MCP23S17 zu reagieren. Natürlich wird das ein recht aufwendiges Programmkonstrukt. Aber du musst wissen, die SPI Varianten sind schneller in der Datenübertragung als die langsameren I2C Varianten.

Guten Tag,

in dem Sinne gibt es eine Beschaltungsdarstellung im Datenblatt zum MCP23x17 ("0" für die I2C Variante / "S" für die SPI Variante).

Da hier immer noch keine Angaben gemacht werden, welche Programmiersprache primär für diese Anwendung genutzt werden sollen, bleibe ich mal bei der typischen die von vielen genutzt wird -Python.

Wenn man den I2C / SPI Bus selber nicht durch permanente Abfragen blockieren will, und die CPU damit nicht "Dauerbeschäftigen" möchte, kann man diese beiden INT_A und INT_B Ausgänge oder nur einen davon mit einem freien GPIO am Raspberry Pi verbinden. Je nach dem an welchem Register A oder / und B irgendwelche schaltenden Elemente angeschlossen sind.

Standardmäßig geben diese beiden Ausgänge eine Spannung gleich der V_C des MCP23x17 aus. Hier mußt du, wie schon erwähnt darauf achten, keine höhere Spannung vom MCP23x17 zum Raspberry PI-GPIO zu führen. Das kann man mit einen Pegelwandler oder einen Spannungsteiler machen, falls die Betriebsspannung des MCP23x17 höher ist als die zulässige Eingangsspannung an einem GPIO.

Das bedeutet, wenn kein Usereingabe über einen Taster am MCP23x17 erfolgt - ist der Pegel somit immer HIGH.

def <Funktionsname>(inter):
    global Value_A
    # Code zum auslesen des Port-Registers
    Value_A = value
    

GPIO.setup(<GPIO-Nummer>, GPIO.IN, pull_up_down = GPIO.PUD_UP)
GPIO.add_event_detect(<GPIO-Nummer>, GPIO.FALLING, callback = <Funktionsname>, bouncetime = <Wert für Entprellzeit in ms>)  

Da dieser Funktionsaufruf selber keinen Rückgabewert verarbeiten kann, also ein return unbeachtet bleiben würde, musst du das Ergebnis des unmittelbar auf die Erfassung eines LOW Pegels an diesem GPIO (Interruptauslösung) und dem darauf folgenden Auslesen des Portregisters diesen Rückgabewert der Port-Registerabfrage irgendwie aus dieser Funktion herausschleusen. Entweder mit dem unschönen global, oder du schreibst dir eine Objektklasse, so das du diesen Rückgabewert in einer der self. Variablen des Objektes zwischenspeichern und abfragen kannst. Die bouncetime kannst du hier auf 1 setzen, oder solange wie dein mechanischer Schalter / Taster noch prellen könnte. Aber niemals länger als 20 ms, denn nach diesen 20ms setzt der MCP20x17 diesen Ausgang, falls der Taster nicht absichtlich länger gedrückt wird automatisch wieder auf High.

Wenn du beide INT_A und INT_B verwenden willst musst du natürlich zwei GPIOs belegen, und zwei solcher Abruffunktionen schreiben, immer eine jeweils für Register von welchem eine Änderung gemeldet wurde.

Über einen separaten Timer kannst du nun in regelmäßigen Abständen prüfen, ob sich einer der beiden self.Variablen (Port A oder Port B) geändert hat, und dann die entsprechende Reaktion auslösen.
Oder wenn es sich nur um OUT-Events handelt, also eine Schaltfunktion als Auslöser auf einen Tastendruck herbeigeführt werden soll, kannst du so einfache, im Programmlauf kurze Sachen, auch direkt in diese Abfragefunktion, wieder mit einer IF-Bedingung ausführen.

Du kannst falls, der mech. Taster wirklich länger prellen sollte, weil er mechanisch verschlissen ist, auch eine wiederholte Mehrfachabfrage des Portregisters machen um einen einzelnen Störimpuls auszuschließen. Hier kann man zum Beispiel sagen, nachdem der MCP23x17 einen Taster-Event gemeldet hat, mache hintereinander 10 Abfragen und werte dieser Abfragen gezielt nach einer Häufigkeit aus. Wenn z.B. innerhalb dieser 10 Abfragerunden ( die nur wenige 10-100 ns dauern ) mehrmals eine LOW Pegel vom betreffenden Pin des Registers ermittelt wurde, kann man davon ausgehen das es ich um keine Störung, sondern um einen gewollt herbei geführten Event handelt. Oder man ergänzt diese Merhfachabfrage noch um die Auswertung, das der letze Einleseversuch einen LOW Pegel hatte (Das kann auch nicht immer gut sein, oder zu eine Fehlerhaften Auswertung führen). Vieles hängt hierbei von der Materialqualität der Taster ab, so das man keine allgemein gültige Empfehlung aussprechen kann, ob man die "bouncetime" bei der Interrupt Definition höher ansetzt, oder ob es zur Betriebssicherheit besser ist, schon unmittelbar auf das erste LOW Signal am INPUT GPIO zu reagieren, und dafür eine vergleichende Mehrfachabfrage über den I2C / SPI Bus durchzuführen.
Hier kann man sich nur durch ausprobieren einer zu dem Anwendungsfall passenden Lösung annähern.

Nur als letzter Hinweis - keine aufwendigen und Laufzeit verschlingenden Ausführungscodes in dieser Abfragefunktionen integrieren, denn wenn diese Funktion ausgeführt wird, wird für diesen Moment die Ausführung des Hauptprogramms welches normal weiter läuft unterbrochen.

Ich hoffe ich habe das konzeptionell vollständig und ausreichend detailliert beschrieben. Auf den Abfragecode des MCP23x17 habe ich hier mal bewusst verzichtet, denn es gibt verschiedene und unterschiedliche Treiber-Library auch wieder anhängig ob es sich um die I²C oder die SPI Variante handelt.

Guten Abend,

Quote from Jenny218

dass Leute, die mich ansonsten überhaupt nicht kennen, in meinem Privatleben herumschnüffeln?

Nur das das mal klar ist, hier hat keiner herumgeschnüffelt. Das ist der Momentauszug aus deinem selbst ausgefüllten, und für jedes Forenmitglied einsehbares Profil. Die Daten entstammen somit aus deiner Feder und sich von dir so für alle Mitglieder freigegeben worden.
Also mal einen Schritt kürzer treten, bevor du hier mit den nächsten Unterstellungen und Behauptungen um die Ecke kommst.

Guten Abend,

Quote from Jenny218

Und wenn ich hier sage, ich habe an meinem Raspi im lfd. Betrieb am 5-Volt-Pin eine Spannung von 5.18 Volt gemessen, und zwar mit einem Profi-Messgerät, während die Warnmeldung erscheint, warum wird das hier einfach in Frage gestellt, als wäre ich zu blöd dazu?

Ja, da beginnt schon der kleine Unterschied. Dazu hatte auch jar schon eine Ausführung gemacht.
Wenn du ein solches Profimeßgerät hast, wobei diese Definition auch subjektiv sein kann, dann schalte es mal falls es dazu in Lage ist auf Frequenzmessung. Dann wirst du oh je Erschrecken, und möglicher Weise feststellen, das du die Netzfrequenz oder eine andere Wandlerfrequenz ( wieder in Abhängigkeit vom Netzteil ) angezeigt bekommst. In diesem Fall kommst du um einen Oszilloskop nicht herum. Damit kommt der Faktor Gleichspannungsglättung , mögliche defekte Kondensatoren oder andere Auslöser in Frage.
Denn es werden auf einer solchen Platine die Spannungen in einer Kaskade nacheinander erzeugt. Deswegen muss man nicht nur die Versorgungsspannung messen, um eine Aussage treffen zu können dann muss man sich wirklich die Mühe machen, alle Prüfpunkte durchzugehen, und zu schauen, wo klemmt der Schuh.
Wenn du aber der Meinung bist, weil du einen Doktoranbschluß in Naturwissenschaften hast, dich nicht auf das grundlegende Niveau eines Zitat "Systemelektroniker" herab begeben zu müssen, dann stochere weiter an der GPIO Liste mit deinem Profimeßgerät herum.

Guten Abend @Jenny218,

Wer die möglichen Ursachen dieser Meldung nicht kennt, sollte doch versuchen trotz des hohen Alters kleinere Brötchen backen.
Das Ras Pi hat mehrere Spannungen nicht nur die 5,0 Volt. Aber egal.
Zudem hatte man dich auch auf den Umstand der Glättung der Gleichspannung hingewiesen. Wenn also einer der vielen Kondensatoren nicht mehr seinen Wert bringt, schwankt die Spannung. Dieser Schwankung wird auf deutsch mit Restwelligkeit angegeben. Wenn diese Restwelligkeiten einen gewissen Wert als Differenz aus der Periode zwischen der kleinsten und größten Spannung überschreitet, obwohl die Durchschnittsspannung trotzdem im Toleranzbereich liegt, wird ebenfalls diese Meldung ausgegeben.

Aber egal, als Doktor der Naturwissenschaften und Biologe, muss man sich nicht automatisch mit dem elektrischen Strom auskennen. Deswegen, miss was du willst, ich hatte dir extra einen Schaltplan verlinkt, wo man an verschiedenen Punkten die unterschiedlichen Spannungen auf der Ras Pi Platine mit geeigneten Meßmitteln nachprüfen kann.
Jedoch die 5 Volt an den Pins 2 und 4 die als 5 Volt Pins in der GPIO Leiste gekennzeichnet sind, geben keinen Rückschluß auf die restlichen Spannungen, auch die des Prozessors.

In diesem Sinn, wenn man diesen Hinweisen nicht nachgehen möchte, weil man sich für etwas Besseres hält, dann mach was du willst, und was du für richtig hältst.

D.f.t.T

Guten Abend,

Quote from Jenny218

Ich habe geschrieben, dass das Original 5 Volt Netzteil, das ich bisher verwendet habe, ständig diese Warnung produziert.

Bevor du hier anderen Leuten unterstellst, sie könnten nicht lesen, dann versuche es mal selber mit deiner Kommunikation. Denn schon hyle verlinkte eine Netzteil, welches mit einer Ausgangsspannung von 5,1 Volt nicht wie von dir behauptet, oder nur aus Unwissenheit !? gepostet 5,0 Volt, oder einfach nur 5 Volt.
Entschuldige, aber bei solchen kleinen Dingen beginnen schon die Unterschiede.

Weiterhin, wenn du um Hilfe bittest, dann achte bitte auch deine Aussagen, besonders was die Details betreffen.
Wenn die Frage gestellt wird, was du alles an dieses Ras Pi angeschlossen hast, oder einmal hattest, dann stellen dir hier die Mitglieder die du um Hilfe gebeten hast, diese Fragen nicht umsonst.
Man kann auch durch USB Komponenten die für einen gewissen Zeitraum damit betrieben wurden, diese jedoch einen sehr hohen Strom benötigt haben, eine Schaden im Bereich der Stromversorgung, bzw. eine Auswirkung / vorzeitige Alterung des Netzteils hervorrufen.
Du bist aber nicht über die Vergangenheit auskunftswillig, also löse doch deine Problem alleine, wenn du jede Antwort , oder Nachfrage negierst.

Statt einmal auch nur ansatzweise auf die antwortenden Mitglieder zu hören, oder auch mal ein Meßgerät in die Hand zu nehmen, um einfach nur an den Prüfpunkten ->

https://datasheets.raspberrypi…us-reduced-schematics.pdf
gekennzeichnet alle mit PP nachzumessen, beharrst du auf deinen Aussagen.
Dann soll es so sein. Hier wird dir keiner weiter helfen können, wenn du weiterhin so mauerst, oder Anfragen in den Wind schlägst.
In diesem Sinne, werde glücklich, drehe den Spannungsregler noch weiter nach oben, und beginne schon einmal zu beten damit dir dieses schöne 3B+ Board nicht um die Ohren fliegt.
Von meiner Seite war es das mit diesem Thema. Fall Hoffnungslos.

Guten Abend,

wenn ich schon lese bis 6 Volt, dann stellt sich für mich die Frage, ob du des Lesens der Spezifikation mächtig bist.
Warum kann der Mensch sich nicht einfach auf der Herstellerseite informieren, und dann auch das Zubehör nutzen was dazu angeboten wird ?
Entschuldige, ich habe keine Verständnis für eine solche Handlung, zumal auch mit einer höheren Spannung das Schadenspotential steigt. Diese Meldung "low voltage warning" kommt nicht nur oder ausschließlich von einer zu geringen Eingangsspannung, es kann auch von einer unzureichenden Gleichspannungsglättung kommen.
Benutze die originalen spezifizierten Netzteile, und die Fehlermeldung wird wie von alleine verschwinden. Vorausgesetzt du hast durch deine Überspannnungsexperimente nicht schon einen nachhaltigen Schaden an diesen Computerplatinen angerichtet.
Mein Mitleid hält sich in Grenzen.

Guten Tag,

Es ist nicht relevant wie dein Aufbau der Verbindungen zum Controller ist, sondern rein wie die Beschaltung ist, und somit wie oder was an welchem Port an den PCF8574 angeschlossen ist.
Es wurde schon mehrfach und wiederholt ausgesprochen.
Egal welchen Ausgangszustand eine Port hat, oder er als Input auf High gesetzt wird, um auf einen LOW Event zu triggern, oder ob du selber im Mischbetrieb Input + Output einen solchen Port in der Funktion aus Output auf Low setzt, um damit z.B. eine LED wieder abzuschalten, der INT selber reagiert immer, mit einem für ca. 20 ms anliegenden LOW Event / Impuls, und geht dann wieder in den High zustand. Also mit jeder Pegeländerungen an einem Port auf LOW, gibt der INT einen Impuls ebenfalls als LOW Signal aus.
Welchen Pin du an deinen µController dem Pico dafür benutzt ist vollkommen egal.

def PCF_Abfrage():
    bla bla bla bla 

INT_Pin = Pin(<Pin-Nummer>, Pin.IN, Pin.PULL_UP)
INT_Pin.IRQ(trigger = Pin.FALLING, handler = PCF_Abfrage)

Wenn du jetzt einen Output-Port aktiv auf Low setzt, dann musst du mit

INT_Pin.IRQ(handler = None) 

zuvor diese INT-Überwachung abstellen, und nach dem Senden des neuen Registerstaatus dieses wieder wie oben drüber gezeigt ( letzte Zeile ) aktivieren. Was in in "bla bla bla bla" wie machst, das ist deinem Einfallsreichtum überlassen, nur darf dieser Teil keinen Verweilzeit im Sinne eines sleep(), sleep_ms() oder sleep_us() enthalten. Du musst also alles mit ticks_ms() oder ticks_us() machen, um eine zeitlich begrenzte wiederholte Anfrage der Portregister auszuführen.
Und dieser Abfrageintervall darf ebenso diese schon genannten 20 ms nicht überschreiten. Also wenn du für kein elektromechanisches Entprellen sorgen kannst, geht das nur auf der Software Ebene. Dazu hatte ich schon ein umfangreiche Ausführung gemacht. Beschäftige dich mit dem I²C Protokoll des PCF8574, dazu gibt es ausreichend Material im Internet, wie auch von den Herstellern selber.

Guten Abend liebe Freunde

Was macht ihr hier bloß ?
Das Grundverständnis wie jar schon sagte liegt darin, das jedes auch befohlene "to LOW" vom INT quittiert wird !
achim 9876 nochmals gesagt: Wenn einer der GPIO's des PCF8574 auf Low wechselt löst automatisch der INT des Portexpanders aus. Jetzt muss man wissen, oder in seinem Programm des steuernden Controllers beachten, was ist der Auslöser !
Wenn du für einen als Output angedachten Pin des PCF8574 eine Port-Register-Setting Befehl sendest, der als Output gedacht ist, also eine LED aktiv ansteuert deswegen kommt deswegen trotzdem ein "aktives" Return über den INT.
Jetzt kannst du aktiv in der CPU damit Zeit verschwenden um für 20 ms alle Port-Register in der Summe, jedoch als Einzelauswertung abzufragen, oder du bist indem Ablaufthema und der Programmiersprache deiner Wahl so weit fit, das du das Interrupr- Händling im Falle eines aktiven, vom Programmierer gewollten Umschalten des Pegels eines von dir als Ausgang beabsichtigten Ports des PCF8574 unterbindet.
Das geht mit für den INT überwachenden GPIO via PIN_name.IRQ(handler = None) .
Damit kannst du euch einen Ausgang auf Low schalten, also eine angeschlossene LED abschalten, der INT-Out des PCF8574 kann reagieren, aber die Auswertung über den GPIO des PICOs welcher zuvor auf "Überwache den Pegelwechsel auf LOW" aktiviert wurde wieder außer Kraft setzt,
Wenn du einen Output Pin des PCF8574 aktiv beschreibst, also eine Zustands- oder Pegeländerung an einem dieser Ports die aus Ausgang vorgesehen sind benutzt, oder via Programmlauf anweist, dann musst du diesen INT- Interrupt für diese Zeit oder den Moment abschalte, jedoch anschließend gleich wieder aktivieren.

jar hat schon recht, wenn er sagt der Mischbetrieb ist mit dieser Programmiersprache nicht einfach.
Das reine Software Entprellen ist nicht das wirkliche Problem, nur das jeder "to Low" Schaltbefehl auf einen Output Port auch zu einer Auslösung des INT führt, der eigentlich dafür gedacht ist, das ein Input- Event einen Pegelwechsel "to Low" auch sofort eine Reaktion des INT Kanals nach sich zieht.

Guten Tag,

Quote from WillyR_aus_C

Wenn dann nach der Zeit 20 ms ( INT Release ) eine Überzahl an 0 in der Liste des jeweiligen Posts findet,

Weiter unten hatte ich dann schon indirekt die Auflösung, ohne jedoch in die Sprachdetails von µPython einzugehen genannt

Guten Tag

Quote from jar

dann sehe mein Posting als Ergänzung!

Ist der Begriff "Polling" für diese kurze ticks_ms() Schleife etwa unangebracht ?

Oder sollte man hier lieber einen neuen Kunstbegriff einführen: "Zeitgesteuerte Durchlaufschleife zur Erfassung von Störimpulsen und Kontaktprellungen " ?

Guten Tag jar

so meinte ich das nicht.
Wenn der INT auf Falling geht, springt man in eine Handler Routine. Diese enthält natürlich keine Sleep Anweisung. Damit kann man mit ticks_ms() eine Startzeit bestimmen, an dem der INT ausgelöst wurde und legt die Verarbeitungs- oder Durchlaufzeit mit:
while start + 20 > ticks_ms(): fest. Nun kann man die Port Register Summe abfragen. Diesen Wert speichert man in einer Variablen zwischen, und beginnt dann mit Bit-Verschiebung die jeweiligen END-Bits in einer Liste ( LIST ) nacheinander abzuspeichern, je nach dem wie viele Ports als Input genutzt werden sollen, und kehr zum Anfang der While Schleife zurück. Wenn die Zeit aufgelaufen ist hat man entsprechend so viele Listen die Listenlänge ist bekannt, also bildet man die Summe und wertet diese aus.
Result = (0 if sum(LISTE) / len(LESTE) < 0.5 else 1)
Wenn nun der Anteil der 0 Bits über 50 % beträgt ( oder jeden anderen Faktor ) wird 0 als gedrückt ausgegeben, ansonsten eine 1, oder jeden anderen Sache die man haben möchte. True und False ist ebenfalls möglich.
Ich hatte mir das schon einmal statisch zurecht gebastelt, das ließe sich sicherlich auch dynamisch mit einer variablen Anzahl der Input Ports umsetzen.

Guten Tag,

Wenn man auf das INT Signal reagiert, also eine I/O Interrupt-Handler aufruft, kann man kurz in der Schleife Pollen, alle betreffenden Ports abfragen, und die 0 oder 1 Werte in einer Tabelle / Liste pro Register erfassen. Das geht sehr bequem, wenn man den PCF8574 nicht über diese Fertig-Bibliothek anspricht, sondern nur die Port Register Zahl ausliest, des jeweilige Port BIT dann durch Bit-Verschiebung zwischen speichert. Damit kann man mit einem Auslesevorgang über den Wert Registerinhalt.copy() nacheinander auf alle möglichen und beliebig belegten Ports zugreifen. Wenn dann nach der Zeit 20 ms ( INT Release ) eine Überzahl an 0 in der Liste des jeweiligen Posts findet, kann man davon zu 99,98 % Wahrscheinlichkeit ausgehen, der Taster an Port XYZ wurde betätigt. Das kann man dann zusammengefasst, als Return zurückgeben.
Eigentlich überhaupt kein Problem mit der Portvermischung. Man muss halt nur aufpassen, das man keinen Output Port erwischt. Jedoch sollte das mit der Aufgabenstellung Port x bis y für den Input klar definiert sein. Und natürlich darf man nicht diese Input Ports mit einem aktiven LOW überschreiben sonst werden diese zu Output-Ports.

Guten Tag,

jar
-> RE: Abfrage eines PCF8574 ob Taste gedrückt oder nicht

Guten Tag,

das kann so nicht funktionieren.
Du setzt im ersten Schritt alle Port auf LOW, und fragst dann einen Taster ab, der den Stromkreis auf Null ziehen soll.
Für den PCF8574 der sowohl LEDs wie auch Taster angeschlossen hat musst du dazu entweder über BIT-Verschiebung die Ports auf LOW schalten, an denen eine LED angeschlossen ist, oder du schaltest jeden LED Port einzeln auf LOW.
Mit der Definition als Input hat der Pegel an diesen Taster-Pins High zu sein. Dazu muss man eine externen Pull-Up schalten. In diesem Fall reagiert auch der INT Pin des PCF8574 mit einem to Loow Wechseln, diesen kann man über einen weiteren GPIO mit Pin.IRQ_FALLING() abfragen und den Ausleseprozess der mit den Taster beschalteten Ports starten.
Mit Polling und der Gewalthammer-Methode alle Port Registereinträge auf LOW zu setzen wird das nie funktionieren. Ich glaube mich erinnern zu können, dass es zu diesem Thema der Nutzung des INT Ports an diesen Portexpandern schon eine sehr umfangreiche Abhandlung u.a. jar gegeben hat.

Guten Tag,

Das nennt man einfach Parallelschaltung
Wenn du ermitteln kannst wie viel Strom durch einen Relais Eingang über / aus dem GPIO gezogen wird, und dieser Strom nicht übermächtig groß ist, also sich im 1-2 mA Bereich bewegt, dann kann man auch mit einem GPIO mehrere Relais schalten.

Guten Tag fred0815

Quote from Folllast

Lt einer Messung benötigen die Sensoren 0,005mA Strom im "Leerlauf", 0,2mA beim "Senden", aber bis zu 10mA beim "Starten".

Wer vom Wort "Senden" Gebrauch macht, sollte deren Deutung kennen
Andernfalls hätte man wohl auch das Wort Übertragung wählen können.
Falls dann doch schon eine Drahtübertragung genutzt werden sollte, kommt hier

Quote from Folllast

Ich habe mir überlegt die Sensoren mit Klingeldraht zu verbinden und Zentral mit Energie zu versorgen.

für meine Begriffe fast unlogische Aussage zustande. Wenn man schon einmal Kabel von den Sensoren zu diesem zentralisierten Raspberry gezogen hat oder möchte, warum dann nicht gleich mit einem Draht mehr für die Stromversorgung. Denn egal welche drahtgebundene Übertragung hierfür genutzt werden könnte, muss es schließlich auch eine Masseverbindung geben. Denn ohne gemeinsame Masse mit einem Batteriebetriebenen Endgerät kommt keine wirklich zuverlässige Übertragung "OneWire ohne Masse" zustande.

Quote from Folllast

mein Haus mit einer Reihe Fenstersensoren etc. auszustatten.

Das schließt jedoch aus, das eine Vorinstallation vorhanden ist. Somit muss man bei einer Drahtübertragung, ohnehin Kabel ziehen, falls man das möchte, und muss zudem auf die Spannungen achten. Nur macht dann wiederum das Wort "Senden" keinen wirklichen Sinn. Und das Thema Versorgungsspannung dieser Sensoren etc. ist damit auch noch vollkommen ergebnisoffen.
Aber wenn du der Meinung bist, dass geht zu 100% ohne zu wissen mit welcher Spannung diese Sensoren betrieben werden, dann wünsche ich dem Fragesteller viel und maximales Grück bei dieser eher waghalsigen Bastelei.