Problem mit SoftWire auf Raspi Pico 2W unter Arduino

[Frank S. (whugnit)]

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?

[Falk B. (falk)]

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.

[Falk B. (falk)]

Liegt bei mir hier

C:\Users\FalkB\AppData\Local\Arduino15\packages\rp2040\hardware\rp2040\2 
.4.0\cores\rp2040

[Rainer W. (rawi)]

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.

[Frank S. (whugnit)]

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.

[Andreas M. (amesser)]

Frank S. schrieb:
> 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 ;-)

Hmm, ich denke Falk wollte Dich auf den USB Port links unter dem Display 
aufmerksam machen.

[Helmut -. (dc3yc)]

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

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

[Norbert (der_norbert)]

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.

[Falk B. (falk)]

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

Du bist ja ein Blitzmerker! Was wäre dieses Forum nur ohne dich?

[Falk B. (falk)]

Helmut -. schrieb:

> Wenn das ein 3.3V-System ist, sind 4k7 schon extrem hoch.

Nö, das ist ein ganz normaler Wert, bei dem man bei halbwegs kurzen 
Leitungen sogar bis 400kbit/s gehen kann.

> Du darfst bis
> auf 1k8 runter gehen.

Ist hier gar nicht das Problem.

[Rainer W. (rawi)]

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?
Die steigenden Flanke sind doch steil genug, d.h. das Signal ist dicke 
schnell genug oberhalb von max V_IH.

[Arduino F. (Firma: Gast) (arduinof)]

Frank S. schrieb:
> Außerdem könnten mehr als die in HW
> vorhandenen I2C Interfaces benötigt werden.

Wieviel hundert I2C Dinger willst du anschließen?
Und I2C Multiplexer sind auch nicht deins?