Problem mit SoftWire auf Raspi Pico 2W unter Arduino

OP #8043870
Lesenswert?

Ich würde gerne die SoftWire Library auf einem Raspi Pico 2W unter Arduino verwenden um einen SHT45 Temperatur- und Feuchtesensor auszulesen. Die SoftWire weil ich HW-unabhängig sein möchte und die Pins flexibel zuzuordnen sein sollen. Außerdem könnten mehr als die in HW vorhandenen I2C Interfaces benötigt werden.

Dabei kommt es immer wieder zu fehlenden Acknowledges. Wenn ich mir die Signale mit dem Oszi anschaue sehe ich immer wieder Phasen in denen SCL oder auch SDA auf Low sind und dann offensichtlich für 400ns getristated werden bevor sie wieder auf Low geschaltet werden. Der 4k7 Pullup zieht die Pegel dann bis auf ca. 2,2V hoch was natürlich Probleme verursachen kann

In der SoftWire sind solche kurzen Intervalle nicht vorhanden da bei meinen Einstellungen nach jedem Pinwechsel 10us gewartet wird was ich zusätzlich durch Traces in der Lib überprüft habe.

Die SoftWire verwendet digitalWrite, digitalRead und pinMode. Wenn ich die GPIO-Zugriffe durch eigene Funktionen ersetze die gpio_set_dir, gpio_get und gpio_put verwenden funktioniert alles.

pinMode scheint etwas unsauber implementiert zu sein, da zuerst der GPIO zurückgesetzt wird (und damit auch auf Input gestellt wird) und erst danach die Richtung eingestellt wird. Allerdings erklärt das nicht das Problem, da pinMode nur dann aufgerufen wird wenn ohnehin eine Änderung der Richtung erforderlich ist. Das beschriebene unsaubere Verhalten würde aber nur Probleme verursachen wenn man mehrmals hintereinander auf Output konfiguriert.

Kennt jemand solche oder ähnliche Probleme mit den Pico 2 GPIOs?

Angehängte Dateien:
#8043876
Lesenswert?

Das mit dem Screenshot auf einem Digitaloszi üben wir dann besser noch mal . . .

Die Quelltexte der Methoden für digitalWrite etc. liegen in einem Ordner in der Arduino-Installation, dort kannst du nachsehen, was da verzapft wird. Und ja, die ist teilweise sehr akademisch und sicher nicht für sauberes Umschalten für I2C gedacht.

: Bearbeitet durch User
OP #8043884
Lesenswert?

Falk B. schrieb:

Das mit dem Screenshot auf einem Digitaloszi üben wir dann besser noch mal . . . [...]

Ich wollte das Bild halt nicht abmalen und werde mir das nächste Mal mehr Mühe geben weniger zu verwackeln und besser zu fokussieren und statt dem Mobiltelefon die Spiegelreflexkamera verwenden ;-)

Rainer W. schrieb:

Frank S. schrieb:

Der 4k7 Pullup zieht die Pegel dann bis auf ca. 2,2V hoch was natürlich Probleme verursachen kann

Wieso soll das Probleme machen können? Im entscheidenden Zeitfenster ist SDA doch stabil. Guck dir die I2C-Spezifikation noch einmal an.

Das passiert nicht nur beim SDA sondern auch beim SCL und sieht dort genau so aus.

#8043910
Lesenswert?

Frank S. schrieb:

Die SoftWire weil ich HW-unabhängig sein möchte und die Pins flexibel zuzuordnen sein sollen. Außerdem könnten mehr als die in HW vorhandenen I2C Interfaces benötigt werden.

Das ist mit großem Abstand der schlechteste Grund für irgend etwas ›Soft‹ Wenn du deine Software auf einem µC laufen lässt welcher dir mit vollen Händen Hardware Schnittstellen zur Verfügung stellt, dann nimm sie.

Schlechter machen für andere µC kannst du die Software immer noch (mit erschreckend wenig Aufwand).

Die Picos stellen zwei fertige I2C zur Verfügung (auf GPIO 0…27), brauchst du mehr, dann mittels PIOs. Acht bis zwölf weitere sollten wohl gehen. Und zwar ebenfalls auf allen dir zur Verfügung stehenden GPIO.

Frank S. schrieb:

Kennt jemand solche oder ähnliche Probleme mit den Pico 2 GPIOs?

Nein! Diese üblen Spikes, das sieht nach einer schlampig programmierten Library aus. Als wenn bei jedem Bit die IOs umkonfiguriert werden.

#8044098
Lesenswert?

Falk B. schrieb:

Ich hab dich inclusive deinem Zitat zitiert!

Es ging um die Größe der Pull-Ups und damit um die steigenden Flanken.

Falk B. schrieb:

Rainer W. schrieb:

Helmut -. schrieb:

Wenn das ein 3.3V-System ist, sind 4k7 schon extrem hoch. Du darfst bis auf 1k8 runter gehen.

Was gefällt dir an den Signalen nicht?

Es dürfen keine Spikes auf der Taktleitung erscheinen. Siehe Anhang.

Außerdem warst DU gar nicht gefragt.

Das Thema Spike auf SCL war schon längst erledigt.

: Bearbeitet durch User
OP #8044255
Lesenswert?

Ich muss wohl die Library und das SDK nochmal genauer durchsuchen. Ich würde sagen da muss irgendwo ein Bug sein.

Zum Thema SoftWire: einer meiner Lieblingssprüche ist: "Premature optimization is the root of all evil.". Ich will die Software-Architektur möglichst klar und übersichtlich halten, daher (weil nicht erforderlich) kaum Multitasking und die Bedienung der Schnittstellen erfolgt synchron. Da ist dann zwischen Soft- und Harware kein bedeutender Vorteil wenn im Hintergrund nichts sinnvolles stattfinden kann.

Das ganze ist gedacht um auf mehreren Devices einen MQTT Client zu betreiben, aber mit unterschiedlichen Aufgaben. Alle verwenden die selbe Software und holen sich automatisch die gesamte Konfiguration übers Netz, inklusive der angeschlossenen Sensore und Aktoren und inklusive der Pins. Natürlich könnte man Multiplexer einsetzen, aber wozu, um welche Anforderung besser zu erfüllen? In Summe hat der Raspi ja genug Pins und mit der Flexibilität hat man keine Einschränkungen. Sonst müsste ich später für unterschiedli he Devices unterschiedliche Prüfregeln implementieren und auch bei der Konfiguration berücksichtigen. Und um 1-10 devices 2x pro Minute abzufragen spielt die Performance überhaupt keine Rolle.

Wenn es zeitkritischer wäre würde ich nicht Arduino verwenden sondern gleich ein kleines RTOS das mir die Taskverwaltung abnimmt um eine übersichtliche paralleliaierung zu realisieren. Und ich würde Devicetreiber für die Schnittstellen benutzen die das asynchron erledigen. Bei 1-2 fixen Devices wäre der HW-HW-Controller ja kein Problem, ich versuche aber normalerweise für die Gesamtproblemstellung zu betrachten.

: Bearbeitet durch User

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren