Announcement: there is an English version of this forum on Der neue Prozessor RP2350 im Pico2 hat einen Fehler (RP2350-E9 im Datenblatt) https://hackaday.com/2024/08/28/hardware-bug-in-raspberry-pis-rp2350-causes-faulty-pull-down-behavior/ The newly released RP2350 microcontroller has a confirmed new bug in the current A2 stepping, affecting GPIO pull-down behavior. Listed in the Raspberry Pi RP2350 datasheet as errata RP2350-E9, it involves a situation where a GPIO pin is configured as a pull-down with input buffer enabled. After this pin is then driven to Vdd (e.g. 3.3V) and then disconnected, it will stay at around 2.1 – 2.2 V for a Vdd of 3.3V. This issue was discovered by [Ian Lesnet] of [Dangerous Prototypes] while working on an early hardware design using this MCU Laut Fehlerbeschreibung sind Eingänge mit Pull-Down betroffen. Ich habs ausprobieert und bei mir tritt der Fehler auch auf wenn kein Pull-Down aktiviert ist. Wenn man das angehängte Programm laufen lässt und dann den Pin kurz mit Plus verbindet bleibt der Eingang, wie bei der Fehlerbeschreibung gesagt, bei ca. 2.2V hängen. Verbindet man den Eingang dann niederohmig (kleiner 1k) mit GND kann man den Eingang zurückholen. Kann jemand das mal nachprüfen und überprüfen ob ich irrtümlich doch einen Pull-Down aktiviert habe?
Martin O. schrieb: > und bei mir tritt der Fehler auch auf wenn kein Pull-Down > aktiviert ist. Isso! E9 ist diesbezüglich unklar. Kleiner 1kΩ wäre aber nochmals deutlich schlimmer als befürchtet.
:
Bearbeitet durch User
Das scheint leider wirklich so übel zu sein. Ich habe es gerade mal mit ein paar Zeilen Micropython getestet: einmal einen Eingang mit dem internen pull-up aktiviert bekomme ich ihn mit dem pull-down nicht wieder auf 0, auch nicht wenn ich länger warte.
1 | from machine import Pin |
2 | |
3 | p3 = Pin(3, Pin.IN, Pin.PULL_DOWN) |
4 | print(p3, p3.value()) |
5 | p3 = Pin(3, Pin.IN, Pin.PULL_UP) |
6 | print(p3, p3.value()) |
7 | p3 = Pin(3, Pin.IN, Pin.PULL_DOWN) |
8 | print(p3, p3.value()) |
9 | |
10 | p3 = Pin(3, Pin.OUT, value=0) |
11 | print(p3, p3.value()) |
12 | p3 = Pin(3, Pin.IN, Pin.PULL_DOWN) |
13 | print(p3, p3.value()) |
Ausgabe des Scripts:
1 | Pin(GPIO3, mode=IN, pull=PULL_DOWN) 0 |
2 | Pin(GPIO3, mode=IN, pull=PULL_UP) 1 |
3 | Pin(GPIO3, mode=IN, pull=PULL_DOWN) 1 |
4 | Pin(GPIO3, mode=OUT) 0 |
5 | Pin(GPIO3, mode=IN, pull=PULL_DOWN) 0 |
Martin O. schrieb: > Verbindet man den > Eingang dann niederohmig (kleiner 1k) mit GND kann man den Eingang > zurückholen. Bei meinem Pico2 muss ich nicht so niederohmig ran. Mit einem 10k Widerstand zwischen einem Aus-und einem Eingang erhalte ich am Eingang immer den erwarteten Wert, auch dann, wenn ich den Eingang zwischenduch hart auf 3,3V lege.
Danke an msx, das klärt die Sache: https://www.eevblog.com/forum/microcontrollers/possible-click-bait-title-the-raspberry-pi-pico-2-now-has-extra-risc-v-cores/msg5622547/#msg5622547
Gibt es angesichts dieser nicht gerade unerheblichen Bugs (wurde der ADC des RP2040 verbessert?) eigentlich überhaupt einen objektiven Grund, sich privat mit diesen RP-MCUs auseinanderzusetzen, anstatt z.B. mit STM32? Also wenn der Preisunterschied nicht die große Rolle spielt.
Ich habe es einmal mit einem 30k Widerstand zwischen GPIO 0 als Ausgang und GPIO 3 als Eingang getestet und einmal mit einem 10k Widerstand und die Spannung an GPIO 3 mit einem Einfachstoszilloskop aufgezeichnet.
1 | from machine import Pin |
2 | from time import sleep_us |
3 | |
4 | po = Pin(0, Pin.OUT, value=0) |
5 | pi = Pin(3, Pin.IN, pull=None) |
6 | |
7 | po.on() |
8 | sleep_us(20) |
9 | po.off() |
10 | sleep_us(100) |
11 | |
12 | Pin(3, Pin.OUT, value=0) |
Mit dem 30k Widerstand bleibt GPIO 3 nach dem Herunterschalten des Ausgangs bei gut 2V hängen bis ich GPIO 3 als Ausgang auf 0 schalte. Mit dem 10k Widerstand sieht alle normal aus. Die fallende Flanke will ich mir noch mit einem besseren Oszilloskop ansehen. Für die Bilder hatte ich des Owon ohne Tastkopf mit etwas Zwillingslitze an den Pico2 angeschlossen, das reicht nicht für schnelle Signale.
Johannes Fe schrieb: > Gibt es angesichts dieser nicht gerade unerheblichen Bugs Also aus sicht eines Hardware-Entwicklers betrifft das Erata ein "Luxus-feature" wie interne PullUps. problematisch ist hier eher eine Software, die dies Luxus-Feature default aktiviert und/oder einen Firmware-Entwickler mindestens mit eine Warnung auf mögliches Probleme bei Nutzung dieses Features hinweist. Wenn man den pico auf einem Steckbrett einsetzt steckt man einen Widerstand dazu und gut ist, baut man ein PCB um den SMD Chip sieht man pads für den Pull vor und gut ist.
Bradward B. schrieb: > Also aus sicht eines Hardware-Entwicklers betrifft das Erata ein > "Luxus-feature" wie interne PullUps. > problematisch ist hier eher eine Software, die dies Luxus-Feature > default aktiviert und/oder einen Firmware-Entwickler mindestens mit eine > Warnung auf mögliches Probleme bei Nutzung dieses Features hinweist. Das Problem tritt auch ohne aktivierte interne Pullups oder Pulldowns auf! Hochohmige Eingänge sind so ohne weiters kompiziert oder ohne Zusatzbeschaltung unmöglich. Ich sehe noch keinen Weg wie man sinnvoll direkt mit einem hochohmigen Signal, das normalerweise high ist und aktiv low, umgehen soll.
> sich privat mit diesen RP-MCUs auseinanderzusetzen, anstatt z.B. mit STM32?
Die integrierte PIO ist ein sehr guter Grund.
Vanye
Bradward B. schrieb: > Also aus sicht eines Hardware-Entwicklers betrifft das Erata ein > "Luxus-feature" wie interne PullUps. Eben nicht und Luxus ist das auch nicht. Probleme gibt es auch ohne 'pullies' und wer weiß, was noch hinzukommt. Selber werde ich um die RP2350 einen Bogen machen. Johannes Fe schrieb: > Gibt es angesichts dieser nicht gerade unerheblichen Bugs (wurde der ADC > des RP2040 verbessert?) eigentlich überhaupt einen objektiven Grund, > sich privat mit diesen RP-MCUs auseinanderzusetzen, anstatt z.B. mit > STM32? Also wenn der Preisunterschied nicht die große Rolle spielt. Etwas hinzuzulernen schadet nie! Selber haben mir die Teile einen TFT-Controller ermöglicht, während andere Chip-Hersteller nicht liefern konnten. Die PIOs sind nett, wenn man sie braucht. Restliche IO-Geschichten sind schlicht und überschaubar. Brauchbare Timer mit capture-Funktion sind nicht vorhanden. Es gibt viel RAM auf dem Chip und viel Flash-ROM, indem das Programm aber völlig ungeschützt liegt, was sehr negativ sein kann. Da sind Programme in einem STM32 (o.ä.) oder ATtiny besser vor Fremdkopieren geschützt und ein AVR hat bezüglich der Genauigkeit einen besseren ADC als ein RP2040, geringere Stromaufnahme, +++ Ansonsten wird jeder seine eigenen objektiven Gründe haben ;-)
Bradward B. schrieb: > Also aus sicht eines Hardware-Entwicklers betrifft das Erata ein > "Luxus-feature" wie interne PullUps. So wie ich diesen Thread verstehe, ist ja das Problem nicht, dass dieses "Luxus-Feature" nicht funktioniere wenn aktiviert, sondern dass es Probleme mache, auch wenn nicht aktiviert. Somit wäre es kein Luxusproblem, dass man so einfach mit externem Widerstand umgehen könnte, zumindest nicht bei hochimpedanten Eingangssignalen.
Mi N. schrieb: > Etwas hinzuzulernen schadet nie! Ja, das stimmt schon, aber die Frage wäre für mich, ob ich meine Zeit, die ich zum Lernen ja brauche, dann nicht sinnvoller in STM32 investiere, statt mich mit den Hardware Bugs der RP-MCUs herumärgern zu müssen – was den Spaß am Lernen für mich persönlich mindern würde. Da werde ich lieber ein paar Euros mehr für einige (originale) STM32-Exemplare ausgeben, die dann aber zuverlässig und genau (ADC) funktionieren. Aber das kann natürlich jeder für sich selbst entscheiden.
>> Also aus sicht eines Hardware-Entwicklers betrifft das Erata ein >> "Luxus-feature" wie interne PullUps. >> problematisch ist hier eher eine Software, die dies Luxus-Feature >> default aktiviert und/oder einen Firmware-Entwickler mindestens mit eine >> Warnung auf mögliches Probleme bei Nutzung dieses Features hinweist. > > Das Problem tritt auch ohne aktivierte interne Pullups oder Pulldowns > auf! Das kannst du sicher mit einem link auf das entspreche3nde Erata belegen. Die ich so weit kenne, beschreiben immer eine Situation bei der die internen Pulls zumindest in der Historie schon mal enabled waren. > Hochohmige Eingänge sind so ohne weiters kompiziert oder ohne > Zusatzbeschaltung unmöglich. ??? die Inputs sind ohnehin hochohmig, Was du meinst ist tristate-Stufe und das sind sinnvollerweise Outputs. Wenn einem der widerstand am Input zu gering ist dann erhöht man den ohnehin nicht über einen Pull sondern über einen serien- (auch Brems-widerstand genannt) Widerstand. > Ich sehe noch keinen Weg wie man sinnvoll > direkt mit einem hochohmigen Signal, das normalerweise high ist und > aktiv low, umgehen soll. Indem man einen externen Pull einbaut. Und das der Pico ublicherweise auf Steckbretter aufsteckbar ist, ist das auch kein problem. Und dann wäre noch die Frage, ob man diese auch hochohmigen Signale überhaupt im Design hat und ob man diese mit einem GPIO und nicht mit einem dediziert dafür entworfenen Peripheral (bspw. integrierten I²C-Slave) bedient.
:
Bearbeitet durch User
> So wie ich diesen Thread verstehe, ist ja das Problem nicht, dass dieses > "Luxus-Feature" nicht funktioniere wenn aktiviert, sondern dass es > Probleme mache, auch wenn nicht aktiviert. Nun ich habe die Erfahrung gemacht, das die threads in diesem Forum zu einem nicht unerheblichen Teil subjektive und falsche Informationen enthalten. Die Darstellung des problems im Erata nennt jedenfalls für die Reproduktion des Fehlers zumindest historisch aktive Pulls an einem als Input betriebenen GPIO.
Bradward B. schrieb: > Die Darstellung des problems im Erata nennt jedenfalls für die > Reproduktion des Fehlers zumindest historisch aktive Pulls an einem als > Input betriebenen GPIO. Schlaf weiter, die Erde dreht sich auch ohne Dich. Johannes Fe schrieb: > statt mich mit den Hardware Bugs der RP-MCUs herumärgern zu > müssen – was den Spaß am Lernen für mich persönlich mindern würde. Dann nimm doch einfach den RP2040 und wenn Du Anregungen brauchst: http://mino-elektronik.de/fmeter/fm_software.htm#bsp_RP2040 http://mino-elektronik.de/TFT-direct-drive/TFT-direct-drive.htm#tft-6 http://mino-elektronik.de/mt12_iic/mt12_iic.htm#qcnt_pico ;-)
Bradward B. schrieb: > Die Darstellung des problems im Erata nennt jedenfalls für die > Reproduktion des Fehlers zumindest historisch aktive Pulls an einem als > Input betriebenen GPIO. Bei so einem frischen Chip muss man allerdings erwägen, dass das Errata noch unvollständig sein könnte.
Bradward B. schrieb: >> Das Problem tritt auch ohne aktivierte interne Pullups oder Pulldowns >> auf! > > Das kannst du sicher mit einem link auf das entspreche3nde Erata > belegen. Noch nicht. Allein in diesem Thread gibt es aber schon drei Pico2 Besitzer die dieses Verhalten beobachtet haben und keinen bei den der Controller sich so verhält wie in Fehler E9 beschrieben. In einer zukünftigen Version des Datenblattes wird die Fehlerbeschreibung sicherlich an das reale Verhalten des Controllers angepasst und dann hoffentlich möglichst bald der Fehler in einer neuen Chiprevision beseitigt. Bradward B. schrieb: >> Hochohmige Eingänge sind so ohne weiters kompiziert oder ohne >> Zusatzbeschaltung unmöglich. > > ??? die Inputs sind ohnehin hochohmig, . Ein Input den ich mit einem 30k Widerstand nicht auf low ziehen kann wenn er einmal auf high war ist wohl kaum hochohmig, da fließt schon ein nennenswerter Strom. > Was du meinst ist tristate-Stufe > und das sind sinnvollerweise Outputs. Nein und nein! > Wenn einem der widerstand am Input > zu gering ist dann erhöht man den ohnehin nicht über einen Pull sondern > über einen serien- (auch Brems-widerstand genannt) Widerstand Ein Serienwiderstand wäre hier kontraproduktiv. Bradward B. schrieb: >> Ich sehe noch keinen Weg wie man sinnvoll >> direkt mit einem hochohmigen Signal, das normalerweise high ist und >> aktiv low, umgehen soll. > > Indem man einen externen Pull einbaut. Und das der Pico ublicherweise > auf Steckbretter aufsteckbar ist, ist das auch kein problem. Bei einem Signal das möglichst gering belasten werden darf vergrößert ein externer Pull-Widerstand den Eingangswiderstand - erstaunlich. Bradward B. schrieb: > Nun ich habe die Erfahrung gemacht, das die threads in diesem Forum zu > einem nicht unerheblichen Teil subjektive und falsche Informationen > enthalten. Oh, wie recht Du hast.
Ich habe folgendes Experiment mit einem RP2350 Eingang gemacht. Ich habe ein 1 k Poti an GND und 3V3 angesschlossen, so dass ich mit dem Mittelabgriff eine Spannung von Null bis 3V3 einstellen kann. Den Mittelabgriff des Poti verbinde ich über einen 100k Widerstand mit einem GPIO Pin des RP2350. Den GPIO Pin stelle ich auf Eingang, keine Pull-Ups, ein. Dann erhöhe ich die Spannung des Eingangs von Null beginnend. Dabei messe ich die Spannung am GPIO-Pin. Erst folgt die GPIO-Pin Spannung der eingestellten Spannung, das heisst der Eingang verhält sich hochohmig. Bei 1.37 Volt springt die Spannung am GPIO Pin auf 2.26 Volt und der Eingang "hängt" auf dieser Spannung. Wenn man den 100k Widerstand weglässt verhält der Eingang sich "normal", d.h. man merkt nichts vom klemmen auf 2.26V.
Bradward B. schrieb: > Die Darstellung des problems im Erata nennt jedenfalls für die > Reproduktion des Fehlers zumindest historisch aktive Pulls an einem als > Input betriebenen GPIO Wie kann man "historisch aktiv" vermeiden wenn der Reset-Zustand aller normalen GPIOs laut Datenblatt "Pull-Down" ist?
:
Bearbeitet durch User
Beim nächsten Experiment habe ich den 100k Widerstand zwischen Poti Mittelabgriff und GPIOpin durch einen 4k7 Widerstand ersetzt und ich starte mit 3V3 und erniedrige langsam die Spannung. Bis 1.37V folgt die GPIO Spannung dem Poti und der Pin "hängt" soweit, dann springt die GPIO Spannung auf 0.8V und der GPIO Pin hängt nicht mehr. stk: Wie kann man "historisch aktiv" vermeiden wen der Reset-Zustand aller normalen GPIOs laut Datenblatt "Pull-Down" ist? Antwort: Gar Nicht (Meiner Meinung Nach) Bei meinem Experiment habe ich den PULL-DOWN ausgeschaltet. Bei dem Experiment mit 100k in Reihe zum Pin merkt man dass kein Pull-Up oder Pull-Down aktiv ist.
Martin O. schrieb: > Bis 1.37V folgt die > GPIO Spannung dem Poti und der Pin "hängt" soweit, dann springt die GPIO > Spannung auf 0.8V und der GPIO Pin hängt nicht mehr. Das bedeutet wohl, daß die ADC-Eingänge ohne niedrige Quellimpedanz nicht brauchbar sind.
Angehängte Dateien:
-
Picobutton.png
13 KB
Also das Erata bedeutet, das eine simple Pushbutton-Auswertung wie im Anhang (aus https://projects.raspberrypi.org/en/projects/introduction-to-the-pico/10) nicht möglich ist ? Kann das mal am Pico2 geprüft werden ?
Ich habe jetzt einen ADC-Eingang getestet. Quelle ist wie oben das 1k Poti zwischen GND und 3V3 mit 100k in Serie zwischen Mittelabgriff und GPIOpin 26 = ADC0. Laut gpio_is_pulled_down(ADCpin) ist der Pull-Down enabled. Aber ich merke keine Wirkung. Der ADC Eingang ist hochohmig und der GPIO-Fehler tritt nicht auf. Den ADC kann man anscheinend ohne Fehler benutzen.
Ich hab mal nen Push-Button Test gemacht (angehängtes Programm). GPIO Pin auf Input und Pull-Up enabled, Pull-Down disabled. Dann einfach Pin-Zustand mit gpio_get() lesen. Funktioniert einwandfrei. Der Kontakt nach Masse ist ja auch niederohmig genug um den GPIO-pin aus dem "Hängen" Zustand zu holen.
Martin O. schrieb: > Laut gpio_is_pulled_down(ADCpin) ist der Pull-Down enabled. > Aber ich merke keine Wirkung. Der ADC Eingang ist hochohmig und > der GPIO-Fehler tritt nicht auf. Den ADC kann man anscheinend ohne > Fehler benutzen. Weil an dem Pin alle digitalen Funktionen abgeschaltet sind. Das wird deine lib schon richtig erledigen. gpio_is_pulled_down() kann ja einen internen Zustand liefern, evt. sogar intern in der lib. Anscheinend kann man "historisch aktiv" doch vermeiden. Wenigstens, solange jede Pin-Funktion vom Start weg definiert wird und später nicht geändert wird. Martin O. schrieb: > Wie kann man "historisch aktiv" vermeiden wen der Reset-Zustand aller > normalen GPIOs laut Datenblatt "Pull-Down" ist? > Antwort: Gar Nicht (Meiner Meinung Nach)
Da ich jetzt eine ganze Weile gebraucht habe, um den Mikropython-Link für den PiPico zu finden: https://micropython.org/download/RPI_PICO2/ und hier noch die Dokumentation: https://docs.micropython.org/en/latest/rp2/quickref.html
:
Bearbeitet durch User
> Ich hab mal nen Push-Button Test gemacht (angehängtes Programm). > GPIO Pin auf Input und Pull-Up enabled, Pull-Down disabled. Dann einfach > Pin-Zustand mit gpio_get() lesen. Funktioniert einwandfrei. Ok, danke für den Test. Also kann man die bisherige dünne Datenlage so zusammenfassen, das der "Bug" unter Laborbedingungen reproduzierbar ist, aber bisher keine praktische Relevanz ("Exploit") hat? Also alle bisher untersuchten "real-world" Anwendung verhalten sich gleich, egal ob Pico 1 oder Pico 2 ? (Nochmals, nach der sehr dünnen aktuellen Datenlage) ?
:
Bearbeitet durch User
> Bei so einem frischen Chip muss man allerdings erwägen, dass das Errata > noch unvollständig sein könnte. Klar, aber das gilt fuer jeden Mikrocontroller da draussen und da gibt es sicher noch welche mit schraegeren Bugs. Vanye
Bauform B. schrieb: > Weil an dem Pin alle digitalen Funktionen abgeschaltet sind. Da ich ein Labornetzteil schneller gefunden habe als ein Poti habe ich das als einstellbare Spannungsquelle genutzt. Nur als analoger Eingang genutzt liefer der ADC plausible Werte und das Netzteil zeigt im gesamten Spannungsbereich von 0V bis 3,3V praktisch keinen Strom an, die Anzeige wechselt zwischen 0,00mA und 0,01mA. Lustig wird es wenn man den Pin auch als digitalen Eingang definiert, auch ohne Pullup oder Pulldown. Von 0 bis etwa 1,3V ist das Verhalten normal, der ADC liefer plausible Werte, das Netzteil zeigt 0 Strom an und der digitale Eingang liefert 0. Bei Spannungserhöhung über 1,3V wechselt der digitale Eingangswert auf 1 und das Netzteil zeigt -0,11mA an. Bei weiterer Spannungserhöhung fällt die Stromaufnahme durch das Netzteils, erreich bei etwa 2,3V wieder 0 und bleibt auch bei bis zu 3,3V bei 0. Erniedrigt man die Spannung wieder wechselt das Verhalten bei den gleichen Spannungen zurück. Das Ganze wirkt als wäre bei einer Spannung zwischen 1,3V und 2,3V am Pin ein interner Pullup aktiv.
Bradward B. schrieb: > Ok, danke für den Test. > Also kann man die bisherige dünne Datenlage so zusammenfassen, das der > "Bug" unter Laborbedingungen reproduzierbar ist, aber bisher keine > praktische Relevanz ("Exploit") hat? Das sieht sicher nicht nur Ian, der Finder des Fehlers, anders: "I know the dreaded 2.15volts because my logic analyzer has bus hold pins that sit at 2.15volts when connected to the Bus Pirate. It freaks me out every time. Rpi confirmed the issue and added it to the datasheet." https://forum.buspirate.com/t/rp2350-bus-pirate-5xl-and-6/529?ref=buspirate.com Weiter unten auf der Seite ist ein Eintrag von ihm von gesten: "There is a silicon bug that causes the pins to latch up, and the pin pull-downs are defective/insufficient. It was in the errata (I reported it!), but it turns out to be MUCH more extensive than documented. Any open drain type bus mode will not work (1-Wire, I2C, etc). One possible solution I tested is replacing the 100K pull-downs on the GPIO with 4.7K pull-downs. This does get the pins working “correctly”. ... We’re still waiting to hear what the plan is from Raspberry Pi. When there is a fix we’ll send everyone updated hardware. I suspected we might have an issue in the first batch, so replacing hardware is already baked into the price. I just thought it would be a me bug, not a silicon bug."
:
Bearbeitet durch User
> Das sieht sicher nicht nur der Finder des Fehlers anders: > "I know the dreaded 2.15volts because my logic analyzer has bus hold > pins that sit at 2.15volts when connected to the Bus Pirate. It freaks > me out every time. Rpi confirmed the issue and added it to the > datasheet." > https://forum.buspirate.com/t/rp2350-bus-pirate-5xl-and-6/529?ref=buspirate.com Naja, "freaks me out" ist nicht gerade eine klare Beschreibung eines Fehlerbildes. Unklar bleibt ebenfalls, ob jetzt der Logicanalyzer nicht funktioniert, weil da ein Pico 2 tut, oder lediglich das Debuggen am Bus mit diesem speziellen Tool erschwert (?) ist. Und hier "freaken" manche wegen der Zeichensetzung ihrer Zeitgenossen aus. > Any open drain type bus mode will not work (1-Wire, I2C, etc). Gerade diese Vermutung sollte man mal testen, der Push-button sollte nach der Fehlerbeschreibung auch nicht funktionieren - tut aber.
:
Bearbeitet durch User
Angehängte Dateien:
Stefan K. schrieb: > Lustig wird es wenn man den Pin auch als digitalen Eingang definiert, > auch ohne Pullup oder Pulldown. > Das Ganze wirkt als wäre bei einer Spannung zwischen 1,3V und 2,3V am > Pin ein interner Pullup aktiv. Man kann einen Schmitt-Trigger bauen aus einem nicht-invertierendem Gatter und einem Widerstand vom Ausgang zum Eingang. An so einem Eingang würde man ein ähnliches Verhalten sehen. Mach mal den gleichen Versuch, aber schalte den Schmitt-Trigger ab.
Bradward B. schrieb: > Gerade diese Vermutung sollte man mal testen, der Push-button sollte > nach der Fehlerbeschreibung auch nicht funktionieren - tut aber. Du hast es nicht begriffen.
Bradward B. schrieb: > Danke, gleichfalls. Denk nochmal nach. Was niederohmig bedeutet zum Beispiel. Und ob das was mit deinem Push-Button-Beispiel zu tun hat. Vielleicht klickt's ja dann irgendwann und deine Logik bleibt dann auch nicht mehr hängen.
> Vielleicht klickt's ja dann > irgendwann und deine Logik bleibt dann auch nicht mehr hängen. Und, wer zeigt jetzt eine ausgemessene Anwendung, die mit dem Pico 1 tut, aber nicht mit Pico 2 ? Passender Alt-Herren-Spruch dazu: "Kriterium der Wahrheit ist die Praxis." (nicht die logik, oder der Beifall der Mitläufer) ;-)
:
Bearbeitet durch User
Gerade diese Vermutung sollte man mal testen, der Push-button sollte nach der Fehlerbeschreibung auch nicht funktionieren - tut aber. Der Push-Button funktioniert meiner Meinung nach folgendermassen: Wenn der Button nicht gedrückt ist zieht der Pull-Up den Pin nach 3.3V (hab ich gemessen). Dabei durchläuft der Pin den "Hängen" Mechanismus. Wenn man den Button drückt geht der Pin auf 0 und weil das niederohmig ist wird der "Hängen" Mechanismus rückwärts durchlaufen und man liest 0. Lässt man den Button wieder los zieht der Pull-Up den Pin wieder auf 3.3 und man liest wieder 1. Wenn man den Pin niederohmig genug ansteuert funktioniert der Pin als Eingang.
Und, wer zeigt jetzt eine ausgemessene Anwendung, die mit dem Pico 1 tut, aber nicht mit Pico 2 ? Siehe oben: Eingang über 100k mit variabler Spannung ansteuern. Wenn man die Eingangsspannung einmal über 1.4V erhöht hat bleibt der Pico2 auf 2.2V hängen, der Pico1 nicht.
> Siehe oben: Eingang über 100k mit variabler Spannung ansteuern. Wenn man > die Eingangsspannung einmal über 1.4V erhöht hat bleibt der Pico2 auf > 2.2V hängen, der Pico1 nicht. Das ist keine Anwendung, das ist eine "Labormessung" wie ein Pin auf Signale im verbotenen Logigpegelbereich regiert. https://de.wikipedia.org/wiki/Logikpegel Ein Serienwiderstand von 100k ist auch nicht sonderlich realistisch für eine elektrische Verbindung zwischen einer (digitalen) Quelle und Senke.
:
Bearbeitet durch User
Stell Dir vor Du steuerst den GPIO-Pin über einen Transistor als Emitterfolger an mit 100k Emitterwiderstand weil Du low-Power Ekektronik machst. Dann wird aus meiner Messung eine Anwendung.
Angehängte Dateien:
-
cmos-stufe.png
13 KB
Martin O. schrieb: > Stell Dir vor Du steuerst den GPIO-Pin über einen Transistor als > Emitterfolger an mit 100k Emitterwiderstand weil Du low-Power Ekektronik > machst. Dann wird aus meiner Messung eine Anwendung. Eine Imagination/Vorstellung ist keine Anwendung )außer vielleicht für Tagträumer ;-) ) Was einen Emitterfolger besonders stromsparend machen soll, erschliesst sich auch nicht, besonders stromsparend wäre eine CMOS-Stufe / FET als Schaltertreiber (siehe Anhang). Aber wir kommen weiter von der ursprünglichen Frage ab, wie verhält sich nun ein I²C Bus an einem Pico 2 (Praktischer Nachweis)? Sind da Anpassungen (Geschwindigkeit, Bauteildimensionierung, ..) notwendig oder sinnvoll ?
:
Bearbeitet durch User
Bradward B. schrieb: > Das ist keine Anwendung, das ist eine "Labormessung" wie ein Pin auf > Signale im verbotenen Logigpegelbereich regiert. Wie soll deiner Meinung nach ein beliebiges Signal, das von low nach high wechselt (und umgekehrt), den "verbotenen Bereich" meiden? Etwa durch Quantensprung, Magie, Telepathie, Gotteskraft etc.?
Bradward B. schrieb: >> Siehe oben: Eingang über 100k mit variabler Spannung ansteuern. Wenn man >> die Eingangsspannung einmal über 1.4V erhöht hat bleibt der Pico2 auf >> 2.2V hängen, der Pico1 nicht. > > Das ist keine Anwendung, das ist eine "Labormessung" wie ein Pin auf > Signale im verbotenen Logigpegelbereich regiert. > https://de.wikipedia.org/wiki/Logikpegel Man muß schon ganz schön krank sein, wenn man auf solch einen an den Haaren herbeigezogenen Stuss kommt ... Bradward B. schrieb: > Aber wir kommen weiter von der ursprünglichen Frage ab, wie verhält sich Ach ...
Jens G. schrieb: > Man [Anm. Bradward B.] muß schon ganz schön krank sein, wenn man auf solch einen an den > Haaren herbeigezogenen Stuss kommt ... Je mehr ich von Bradward B. lese, umso mehr komme ich zu der Überzeugung, dass da viel Wahres dran sein könnte, leider!
Pat A. schrieb: > Je mehr ich von Bradward B. lese, umso mehr komme ich zu der > Überzeugung, Der unter E9 genannte Fehler ging von aktivem pulldown-Widerstand aus. Die Anwendung von Bradward B. ist eine andere. Ist das so schwer zu sehen? Ich habe Anwendungen, wo ich mit pullup-/down Touch-Folien bzw. Taster hochohmig abfrage. Da habe ich keinerlei Bedarf, daß dort durch latchup etwas hängen bleibt. Und ich habe keinen Bedarf an noch nicht entdeckten Seiteneffekten, die daraus entstehen könnten. Sollte ein IIC-Bus hängen bleiben, hört der Spaß auf. Mag sich B.B. seine Welt schön träumen, ich habe keinen Bedarf am RP2350 und gehöre sicherlich auch nicht zur Zielgruppe. Der Rp2040 reicht mit seinen Möglichkeiten und seinen Einschränkungen. Kritikpunkte an den RPxxxx hatte ich ja schon angedeutet.
:
Bearbeitet durch User
Bauform B. schrieb: > Mach mal den gleichen Versuch, aber schalte den Schmitt-Trigger ab. Die Spannungsanzeige des Labornetzteils hat eine zu geringe Auflösung, ich habe jetzt noch ein Multimeter parallel angeschlossen. Bei zurückgesetztem Pad isolation Bit, gesetztem Input enable Bit und mit Schmitt-Trigger liegt die Schwelle bei der der Effekt bei steigender Spannung auftritt bei 1,44V und die bei er bei fallender Spannung verschwindet bei 1,12V. Bei abgeschaltetem Schmitt-Trigger tritt der Effekt ebenfalls auf, die Schwellen liegen mit etwa 1,37V und 1,35V nur deutlich dichter beieinander. Falls jemand das auch mal mit Micropython testen will:
1 | from machine import ADC, mem32, Pin |
2 | from time import sleep_ms |
3 | PADS_BANK0_BASE = 0x40038000 # PADS_BANK0_BASE |
4 | GPIO_REG = PADS_BANK0_BASE + 0x70 # GPIO27 |
5 | |
6 | adc = ADC(Pin(27)) |
7 | print(bin(mem32[GPIO_REG])) |
8 | mem32[GPIO_REG]=0b0001010000 |
9 | print(bin(mem32[GPIO_REG])) |
10 | |
11 | while(True): |
12 | print("%1.2f" % (adc.read_u16()*3.3/66750))
|
13 | sleep_ms(1000) |
Wenn man mit einem kräftigen Signal den Pin aus seinem 'hängen' rausbekommt, legt das allerdings auch die Vermutung nahe, das da deutlicher Strom in den Eingang fliessen muss. Das ist nicht das, was man sich an einem Input wünscht. Der RP2040 spricht von 1µA (leakage Current) am digitalen Eingang und 100kOhm Impedanz am ADC Eingang. Mit 1µA wird man beim RP2350 vermutlich nicht viel reissen - Killerkriterium.
:
Bearbeitet durch User
Matthias S. schrieb: > Wenn man mit einem kräftigen Signal den Pin aus seinem 'hängen' > rausbekommt, legt das allerdings auch die Vermutung nahe, das da > deutlicher Strom in den Eingang fliessen muss. Stefan K. schrieb: > Von 0 bis etwa 1,3V ist das Verhalten normal, der ADC liefer plausible > Werte, das Netzteil zeigt 0 Strom an und der digitale Eingang liefert 0. > Bei Spannungserhöhung über 1,3V wechselt der digitale Eingangswert auf 1 > und das Netzteil zeigt -0,11mA an. Bei weiterer Spannungserhöhung fällt > die Stromaufnahme durch das Netzteils, erreich bei etwa 2,3V wieder 0 > und bleibt auch bei bis zu 3,3V bei 0. Stefan K. schrieb: > Bei abgeschaltetem Schmitt-Trigger tritt der > Effekt ebenfalls auf, die Schwellen liegen mit etwa 1,37V und 1,35V nur > deutlich dichter beieinander. In dem Zustand fließt wahrscheinlich kaum weniger Strom. I2C mit vernünftigen Pull-Up sollte aber immer funktionieren. Und es ist ein ganz anderes Problem als die Pull-Down Geschichte. Ein wirklich "interessanter" Chip, so viel Abenteuer...
Matthias S. schrieb: > Wenn man mit einem kräftigen Signal den Pin aus seinem 'hängen' > rausbekommt, legt das allerdings auch die Vermutung nahe, das da > deutlicher Strom in den Eingang fliessen muss. Bei meinem Pico2 sind es an der Schaltschwelle gut 110µA die aus dem Eingang gezogen werden müssen um von high auf low zu kommen. In Gegenrichtung reicht ein 3M Widerstand nach 3,3V aus. Von 0V bis zur Schaltschwelle und oberhalb von 2,5V bis zur Versorgungsspannung ist der Eingang hochohmig. In den beiden Bereichen zeigt mein Multimeter praktisch keinen Strom an, die Anzeige springt höchstens mal von den 0,01µA die es ohne Strom anzeigt auf 0,02µA. Bauform B. schrieb: > In dem Zustand fließt wahrscheinlich kaum weniger Strom. I2C mit > vernünftigen Pull-Up sollte aber immer funktionieren. Und es ist ein > ganz anderes Problem als die Pull-Down Geschichte. Ein wirklich > "interessanter" Chip, so viel Abenteuer... Der Strom ist gleich, nur die Schaltschwellen sind verschoben. Es ist wahrscheinlich doch genau dieses Verhalten, das zum Erratum RP2350-E9 im Datenblatt geführt hat. Das war ein Schnellschuss nachdem der Fehler gemeldet wurde und weder dem Finder noch RPi ganz klar war was genau da passiert. Es soll wohl in einem sehr späten Entwicklungsschritt Änderungen an den von RPi zugekauften PAD-Macorozellen gegeben haben die sich anders verhalten als die dazu gelieferte Simulation oder die zuvor gefertigten Muster.
Stefan K. schrieb: > gut 110µA die aus dem > Eingang gezogen werden müssen Ja danke, hatte ich zuerst überlesen. So ein Verhalten möchte ich nicht bei einem Standardport wie einem GPIO. Damit ist der erstmal raus.
Angehängte Dateien:
-
GPIO27.png
44 KB
Ich habe mal in einem Diagramm den Strom den GPIO27 bei gesetztem Input enable Bit und eingeschaltetem Schmitt-Trigger liefert über die niederohmig angelegte Spannung aufgetragen: Strom in µA, blau bei steigender Spannung und rot bei fallender. Ein 10k Pulldown reicht knapp um den GPIO von high wieder auf low zu ziehen, mit einem 30k ist bei gut 2V Schluss.
Bei mehreren Eingängen gleichzeitig wird sich das wohl proportional verhalten. Mal sehen, ob ein neueres Datenblatt Informationen dazu liefert und ob es überhaupt eine korrigierte Version geben wird. Andere Mütter ...
Stefan K. schrieb: > Ich habe mal in einem Diagramm den Strom den GPIO27 bei gesetztem Input > enable Bit und eingeschaltetem Schmitt-Trigger liefert über die > niederohmig angelegte Spannung aufgetragen Vielen Dank für deine Mühe - leider haben die Herren aus der Qualitätssicherung sich diese Arbeit erspart. Ich bleibe erstmal beim RP2040.
Im element14-Forum hat jemand ein 0-3,3V Sinussignal über einen 10k Widerstand mit einem GPIO-verbunden. Bei zurückgesetztem IE-Bit sieht das normal aus, bei aktiviertem Eingang stark verzerrt. Dass dabei die fallende Flanke stärker verzerrt ist als die steigende hatte ich so erwartet. https://community.element14.com/products/raspberry-pi/f/forum/55046/rp2350-gpio-pull-down-latching-bug/223658 Bei Ansteuerung mit einem nicht zu schwachen Push-Pull Ausgang sollte es wenig Probleme geben, mit einem beliebig großen Pull-Up und einem nicht zu schwachen OC/OD Ausgang ebenso. Falls man einen Pull-Down Widerstand nutzen will sollte der kleiner als 10k sein. Nicht schön, aber für viele Anwendungen auch nicht ganz schlimm.
Angehängte Dateien:
-
4us_Rechteck_ohne_IE.png
22 KB -
4us_Rechteck_mit_IE-0002.png
22 KB -
4us_Trapez_ohne_IE-0004.png
24 KB -
4us_Trapez_mit_IE-0003.png
24 KB
Ein sinusförmiges Signal an einem Digitaleingang fand ich doch etwas seltsam, ich habe es jetzt selbst mit einem Rechteckpuls und einem trapezförmigen Puls aufgezeichnet. Blau ist jeweils das Ausgangssignal eines Funktionsgenerators und rot die Spannung an einem über einen 10k Widerstand angeschlossenen GPIO. Bei nicht gesetztem Input Enable Bit sieht alles normal aus für einen derartig hochohmig angesteuerten Eingang mit parallel direkt angeschlossenem Oszilloskop. Mit gesetztem IE-Bit sieht man wieder den merkwürdigen Pull-Up Effekt. Beim Rechteckpuls ist die steigende Flanke etwas steiler, sieht sonst aber normal aus. Die fallende Flanke ist stark verformt und so die Zeit die der Controller ein High erkennt deutlich velängert. Mit dem trapezförmigen Signal sieht man auch auf der steigenden Flanke den Pull-Up Effekt und auf der fallenden Flanke mehr Details.
:
Bearbeitet durch User
An Stefan K.: Gute Messungen! Frage: ist der Pull-Down bei den Messungen aktiviert?
Martin O. schrieb: > Frage: ist der Pull-Down bei den Messungen > aktiviert? Die liegen im Bereich zwischen 50…80kΩ. Gefüttert über einen 10kΩ Widerstand dürfte die resultierende Eingangsspannung bestenfalls irgendwo zwischen 2.93…2.75V landen.
Der Pull-Down war abgeschaltet. Der Schmitt-Trigger aber war aktiv was man auch an der Kurve erkennt. Ich werde heute Abend die Kurve mit dem linearen Anstieg und Abfall noch mal deutlich länger machen um die sichtbaren Effekte durch umzuladende Kapazitäten zu verringern und dann auch einmal ohne Schmitt-Trigger am Eingang messen.
:
Bearbeitet durch User
Angehängte Dateien:
Stefan K. schrieb: > Der Schmitt-Trigger aber war aktiv was man auch an der Kurve erkennt. Da wäre ich eher skeptisch. Beim RP2040 sind die Schmitt-Trigger Schwellen bei 1.55V und 1.75V. Und in diesem Bereich sieht das alles noch unverdächtig aus. Interessant ist allerdings, dass beim Anstieg der Flanke eine scheinbare Kapazität von (rundgeschätzen) knapp 30pF erscheint, beim Abfall (durch den Fehler) jedoch wesentlich mehr. Die negative Flanke sieht so aus, als würde bei 15kΩ, vielleicht schon bei 12kΩ, die interne Logik nicht mehr zurück ›schnappen‹ können. Der Eingang sollte dennoch einen Low Zustand melden.
Norbert schrieb: > Interessant ist allerdings, dass beim Anstieg der Flanke eine scheinbare > Kapazität von (rundgeschätzen) knapp 30pF erscheint, beim Abfall (durch > den Fehler) jedoch wesentlich mehr. Bei beiden Flanken kann man wegen des merkwürdigen Pull-Up Effektes auf etwa 2,5V bei gesetztem Input Enable Bit aus der Kurvenform kaum auf die Eingangskapazität schließen. Bei abgeschaltetem IE sieht man wohl eher die tatsächliche Kapazität wenn man das Oszilloskop mit 1MΩ ∥ 13pF Eingang, das ich direkt ohne Tastkopf über 5cm lange Leitungen angeschlossen hatte, berücksichtigt. Norbert schrieb: > Die negative Flanke sieht so aus, als würde bei 15kΩ, vielleicht schon > bei 12kΩ, die interne Logik nicht mehr zurück ›schnappen‹ können. > Der Eingang sollte dennoch einen Low Zustand melden. Exemplarabhängig können auch 10k schon zu viel sein. Und auch bei 10k sieht bei meinem Pico2 eine symmetrisches 20kHz Rechteckwelle am Eingang sehr "interessant" aus. Auf den vom Controller erkannten Zustand hatte ich jetzt nicht geachtet, ich hatte nur die Bits im Pad-Konfigurationsregister gesetzt. Ich meine aber, dass bei vorherigen Tests der Eingang immer High meldete wenn der Eingang "hing".
:
Bearbeitet durch User
Angehängte Dateien:
Bei eingeschaltetem Schmitt-Trigger folgt bei einer langsam steigenden Flanke die Spannung am Eingang hinter dem 10k Widerstand bis ca. 1,45V direkt der Spannung des Funktionsgenerators, "springt" dann auf gut 2V und nähert sich dann wieder an die FG-Spannung an. Bei der fallenden Flanke passiert der "Sprung" nach unten erst ganz kurz vor Ende des Eingangspulses bei ca. 1,15V. 10k scheint schon sehr nahe an der oberen Grenze zu sein bei der der Eingang wieder heruntergezogen werden kann. Bei ausgeschaltetem Schmitt-Trigger erfolgen beide "Sprünge" bei ca. 1,35V, mit dem 10k Widerstand bleiben da etwas größere Reserven. Norbert schrieb: > Da wäre ich eher skeptisch. Beim RP2040 sind die Schmitt-Trigger > Schwellen bei 1.55V und 1.75V. Und in diesem Bereich sieht das alles > noch unverdächtig aus Mit eingeschaltetem Schmitt-Trigger lese bei langsam hochgeregelter Spannung an einem GPIO meines PICO2 bis etwa 1,45V Low ein und darüber High. Zurück auf Low gehr es dann erst wieder bei ca. 1,15V. Die Schmitt-Trigger Schwellen liegen damit deutlich niedriger. Egal ob mit oder ohne Schmitt-Trigger, der merkwürdige Pull-Up Effekt beginnt bzw endet an den Punkten an denen ein Wechsel des logischen Pegels erkannt wird. Der Spannungsrippel der roten Kurve könnte vom Schaltregler auf dem Pico2 kommen.
Scheint meine schlimmsten Vermutungen zu bestätigen. Hysterese breiter, Schwellen deutlich niedriger, heftige Rückfütterung in die ansteuernde Schaltung. Entweder prügelt man verdammt niederohmig in die Eingänge hinein, oder man nutzt das Ding nur für Ausgaben an den GPIOs. Bin gespannt ob's eine vernünftig arbeitende nächste Revision geben wird, oder sie das Ding komplett abgeschrieben haben. Vier Kerne für die Katz'.
Norbert schrieb: > Bin gespannt ob's eine > vernünftig arbeitende nächste Revision geben wird, oder sie das Ding > komplett abgeschrieben haben. So, wie ich das verstanden habe, wollen sie am Chip erstmal nichts machen, sondern nur die Dokumentation/Errata ergänzen :-O Das wäre natürlich nur kurieren am Symptom. Ist schon schade, wäre sicher ein interessanter MC geworden. Aber so...
Stefan K. schrieb: > Egal ob mit oder ohne Schmitt-Trigger, der merkwürdige Pull-Up Effekt > beginnt bzw endet an den Punkten an denen ein Wechsel des logischen > Pegels erkannt wird. Klingt irgendwie nach aktiver bus-keeper Schaltung. https://en.wikipedia.org/wiki/Bus-holder
Matthias S. schrieb: > So, wie ich das verstanden habe, wollen sie am Chip erstmal nichts > machen, sondern nur die Dokumentation/Errata ergänzen :-O > Das wäre natürlich nur kurieren am Symptom. > Ist schon schade, wäre sicher ein interessanter MC geworden. Aber so... Es gibt Hardware Probleme die man zwar dokumentieren, jedoch nicht per Software lösen kann. Dies ist eines. Mal schauen ob das noch zu denen durchdringt. Falls nicht… Tja, dann isser wohl für Ernsthaftes gestorben. Andererseits, eine LED blinken lassen kann man ja damit. Und für Knöppsche sind die ›I‹ der GPIOs ja auch zu gebrauchen. Also kommen die Dinger auf Arduino Boards und gut iss. Da sehe ich schon bald die Beiträge eintrudeln: Mein Taster geht nicht, was soll ich tun? Edit: Die Modifikation der PADS sollte ja wohl der Stromersparnis dienen. Dieses Ziel ist nahezu perfekt erreicht … wenn die Dinger in den Regalen herum schimmeln.
:
Bearbeitet durch User
Norbert schrieb: > Entweder prügelt man verdammt niederohmig in die Eingänge hinein, oder > man nutzt das Ding nur für Ausgaben an den GPIOs. Bei schnellen und damit steilen Signalen sind die sehr kurzen maximal etwa 0,1mA gegenüber den Strömen zum Umladen der Eingangskapazität und der diversen zusätzlichen Kapazitäten in der Schaltung darumherum wohl meist zu vernachlässigen. Matthias S. schrieb: > So, wie ich das verstanden habe, wollen sie am Chip erstmal nichts > machen, sondern nur die Dokumentation/Errata ergänzen :-O So, wie ich das verstanden habe, konnten sie bisher nicht einmal das von inzwischen vielen geschilderte Verhalten reproduzieren. Peter D. schrieb: > Klingt irgendwie nach aktiver bus-keeper Schaltung. > https://en.wikipedia.org/wiki/Bus-holder Nicht wirklich, so wie sie jetzt ist hilft die Schaltung zwar ein High am Eingang zu halten nicht aber ein Low. Und auch bei High hält sie ihn selbst unbelastet nur auf 2,5V. Norbert schrieb: > Edit: > Die Modifikation der PADS sollte ja wohl der Stromersparnis dienen. > Dieses Ziel ist nahezu perfekt erreicht … wenn die Dinger in den Regalen > herum schimmeln. Ich meine, es ging um Fehlertoleranz bei 5V Eingangssignalen. Egal was es war, das jetzt beobachte Verhalten hatte man bei RPi sicher nicht gewollt.
:
Bearbeitet durch User
Stefan K. schrieb: > Bei schnellen und damit steilen Signalen sind die sehr kurzen maximal > etwa 0,1mA gegenüber den Strömen zum Umladen der Eingangskapazität und > der diversen zusätzlichen Kapazitäten in der Schaltung darumherum wohl > meist zu vernachlässigen. Ich finde es ja nett, das du probierst, den Bug zu entschuldigen, aber selbst 100µA pro GPIO sind in einer modernen Schaltung einfach nur Verschwendung, um einen GPIO loszutreten. Das läppert sich mal schnell, wenn du mehrere benutzt.
Bei dem RP2350 geht es wohl eher darum, eine Eierlegendewollmilchsau als Ersatz/Ergänzung zu den RPIs anzubieten, auf denen Linux in Größe einer Briefmarke läuft. Dafür werden die großen Speicherbereiche gebraucht. GPIO geht keinen mehr etwas an und wird nur durch fertige LIBs angesprochen. Daß im GPIO-Bereich Knickeier zu finden sind, stört nur die paar Spinner, die TTL-Pegel nicht mehr kennen. Die bringen keinen nennenswerten Umsatz. Wozu RISC-V als 'minderwertiges' Beiwerk gut sein soll, erschließt sich mir nicht. Durch die vorhandnen ARM-Kerne sind Lizenzkosten im Kaufpreis schon enthalten. Durch den günstigen Preis werden aus Gründen des Wettbewerbes vielleicht zum Beispiel STM32 für das normale Volk preiswerter. Positiv denken ;-)
Norbert schrieb: > Tja, dann isser wohl für Ernsthaftes gestorben. OK, Übertreibung macht deutlich. Aber schaut euch mal eure alten Schaltungen an. Wie viele Pins wären tatsächlich betroffen? Ich hab' gerade gesucht und tatsächlich einen gefunden. Das war ein nachträgliches Luxus-Feature mit 39k Längswiderstand zum Eingang. Witzigerweise hat das mit einem STM32L031 dann doch nicht funktioniert... Stefan K. schrieb: > Bei schnellen und damit steilen Signalen sind die sehr kurzen maximal > etwa 0,1mA gegenüber den Strömen zum Umladen der Eingangskapazität und > der diversen zusätzlichen Kapazitäten in der Schaltung darumherum wohl > meist zu vernachlässigen. Eben. Die allermeisten Eingänge gehen entweder auf den ADC oder werden sowieso von Pegelwandlern, EPROMs usw. getrieben. Oder von einem externen Schmitt-Trigger, weil man dem internen noch nie getraut hat. Oder ich spendiere einem Batteriegerät 1xUM-Taster für 0µA Standby. Alles ist niederohmig... Also ja, es ist ein spannender Fehler, aber praktisch kostet der nichts extra.
Matthias S. schrieb: > Ich finde es ja nett, das du probierst, den Bug zu entschuldigen, Ich versuche nicht den Bug zu entschuldigen, würde ich sonst hier mit Messungen zeigen wie sich der Fehler auswirkt? Ganz klar, das Verhalten der GPIOs kann Probleme bereiten und zum nicht funktionieren von Schaltungen führen die eigentlich funktionieren müssten. Vieles wird aber auch einfach funktionieren oder kann zum funktionieren gebracht werden wenn man die Eigenheiten der GPIOs kennt.
Stefan K. schrieb: > So, wie ich das verstanden habe, konnten sie bisher nicht einmal das von > inzwischen vielen geschilderte Verhalten reproduzieren. Iss nicht dein Ernst, oder? ;-) Gut, derartig komplexe Szenarien können auch nur Raketenwissenschaftler angemessen untersuchen…
1 | #!/python
|
2 | # -*- coding: UTF-8 -*-
|
3 | # vim: fileencoding=utf-8: ts=4: sw=4: expandtab:
|
4 | |
5 | #─────[ GPIO ›0‹ and ›1‹ connected with 0Ω and various resistors ]────────────────────
|
6 | |
7 | from machine import Pin, PWM |
8 | |
9 | p_out = Pin(0, mode=Pin.OUT) |
10 | p_in = Pin(1, mode=Pin.IN, pull=None) |
11 | |
12 | pwm = PWM(p_out) |
13 | pwm.duty_u16(1<<15) |
14 | |
15 | signal = p_in.value |
16 | for freq in [value * 10**ex for ex in range(2,8) for value in (1,2,5)]: |
17 | print(f'\n({freq / 1e3:7.1f}kHz)', end=':') |
18 | pwm.freq(freq) |
19 | for _ in range(100): |
20 | print('X' if signal() else '.' , end='') |
Wie man sieht, hat's auch nichts mit Pull-[up|down] zu tun. Edit: Wir schreiben das Jahr 2024. Alles ist gut. Die Erdscheibe dreht sich. Das Board mag kein UTF-8 wenn es Anhänge zeigt.
:
Bearbeitet durch User
Bauform B. schrieb: > Norbert schrieb: >> Tja, dann isser wohl für Ernsthaftes gestorben. > > OK, Übertreibung macht deutlich. Aber schaut euch mal eure alten > Schaltungen an. Wie viele Pins wären tatsächlich betroffen? Alle, welche zB. mittels PIO belastungsarm auf Signalen herum schnuppern. Da funktioniert der vorgeschlagene Würgaround mit ↑IE↑ read ↓IE↓ nicht. Kann man Buffer vorpacken, das ändert die Situation, nun: Alle, welche zB. dynamisch die Richtung ändern müssen. Kann man spezielle Transceiver vorpacken, das ändert die Situation, nun: Zusätzliche Pins für [en|dis]able erforderlich. Evtl. Timing. Wie kann man auf Flanken mit IRQs reagieren, wenn IE immer abgeschaltet bleiben muss? Wie kann DMA read bei jedem Lesevorgang IE bedienen? Wie verhalten sich all die anderen Subsysteme an den Eingängen?
Norbert schrieb: > Iss nicht dein Ernst, oder? ;-) 27.08.2024: "We've known about this for a while, it's not "just been found", hence there being an detailed erratum in the datasheet." https://forums.raspberrypi.com/viewtopic.php?t=375631#p2247957 01.09.2024: "We will continue to investigate as a matter of very high priority, but right now its the weekend, so don't expect any official responses to the issue itself." https://forums.raspberrypi.com/viewtopic.php?t=375954#p2249291 Dann Ende der Diskussion. https://forums.raspberrypi.com/viewtopic.php?t=375954
Wenn ich beim Hersteller arbeiten würde, dann würde ich erst mal versuchen, eine guten Workaround zu finden, der das Problem abstellt, bevor ich mich weiter dazu äußere.
Das aktuelle Datenblatt vom RP2350 vom 06.09.2024 hat nun eine erweiterte Fehlerbeschreibung E9.
Mi N. schrieb: > Das aktuelle Datenblatt vom RP2350 vom 06.09.2024 hat nun eine > erweiterte Fehlerbeschreibung E9. Ja, besser, aber meiner Meinung nach immer noch irreführend. Die Wortwahl suggeriert das der Fehler auftritt, wenn der Eingangspegel … Moment …
1 | Increased leakage current when Bank 0 GPIO pads are configured as inputs and the pad is somewhere between V IL and V IH (the undefined logic region). |
Doch das sogenannte ›Latch-up‹ hatte ich auch beobachtet, wenn mit maximaler Flankensteilheit auf High geschaltet und dann der (offene) Eingang hochohmig/weak gegen Masse gezogen wird. Da bleibt's — im Gegensatz zum RP2040 — einfach High und erst ein <= 8.2kΩ Widerstand gegen Masse lässt das Ding zurück schnappen. Das werde ich aber noch etwas genauer testen.
Es gibt aber auch Positives zu berichten. Der ADC ist massiv verbessert worden. 60k Samples @ 500ksps per DMA. Rohdaten im Anhang, wer mal selbst mit gnuplot reinschauen möchte…
Norbert schrieb: > Ja, besser, aber meiner Meinung nach immer noch irreführend. Ist mir letzlich egal, das Teil werde ich nicht beschaffen und daher nicht verwenden. Als Hersteller würde ich auch keine korrigierte Version ankündigen: (fast) alle würden abwarten und die produzierten Bestände nicht kaufen. Norbert schrieb: > Rohdaten im Anhang, wer mal selbst mit gnuplot reinschauen möchte… Die Abstände der Einzelwerte etwas zu groß und auf die Optik würde ich mich nicht verlassen, obwohl da schon Rauschen zu sehen ist.
1 | 3939
|
2 | 3940
|
3 | 3940
|
4 | 3944
|
5 | 3941
|
6 | 3941
|
7 | 3940
|
8 | 3942
|
9 | 3940
|
10 | 3942
|
11 | 3944
|
12 | 3945
|
13 | 3944
|
14 | 3944
|
15 | 3945
|
16 | 3945
|
Mi N. schrieb: > … Es ging mir im Wesentlichen um die nicht mehr vorhandenen Sprünge bei den 512er Schritten. Und wenn man eine zweite Kurve mit einem 101 breiten Median dazu plottet, sieht's gar nicht mal soooo schlecht aus.
Christoph M. schrieb: > Hast Du den Source-Code dazu? Klar. Der ist aber in Micropython geschrieben und das wird hier im Forum gar nicht gerne gesehen. Vor allem, weil man damit ja so rein gar nichts Richtiges machen kann. ;-) Darum spare ich mir alles, was über kurze Snippets hinaus geht.
Norbert schrieb: > Es ging mir im Wesentlichen um die nicht mehr vorhandenen Sprünge bei > den 512er Schritten. Hast Du Deine Messung auch mal mit einem RP2040 gemacht? Da müßte doch eine Verschlechterung zu sehen sein. Vor längerer Zeit hatte ich mit dem RP2040 einen PT1000 ausgewertet, wobei ich keine Unstetigkeiten gefunden hatte. Da es letztlich nur ein Spannungsteiler mit einem 1 k Festwiderstand war, hätte man auch im betreffenden Bereich mit einm IO-Pin einen Offset (100 k) zuschalten können, um aus dem kritischen Bereich zu kommen. Hatte ich wohl seinerzeit auch gemacht und wieder weggepackt, da kein Bedarf vorhanden war. Mehr gestört hatte mich der Grundoffset von 13. Das Datenblatt macht hierzu keine Angaben.
Mi N. schrieb: > Hast Du Deine Messung auch mal mit einem RP2040 gemacht? Da müßte doch > eine Verschlechterung zu sehen sein. Ja, hatte ich. Übelste Sprünge bei 3×512-1, 5×512-1, 7×512-1 Weniger schlimm bei 2/4/6×512-1 Grafik dazu hatte ich auch mal gepostet. Mit ein wenig adaptiver Magie, ein wenig zusätzlicher Beschaltung und einer automatisch erzeugten Korrekturkurve ging es dann aber. Allerdings lag der Output ›nur‹ bei 100ksps, trotz 500ksps Samplerate.
Norbert schrieb: > Der ist aber in Micropython geschrieben und das wird hier im Forum > gar nicht gerne gesehen. Ich habe schon in ASM, PHP, BASIC, C und Pascal Programme geschrieben und finde Micropython auf dem Pico einfach super. Meine neue Bodendrohne läuft damit und der Entwicklungszyklus ist eben extrem kurz. Also ruhig posten, lass die anderen ruhig meckern.
Norbert (der_norbert) >Klar. Der ist aber in Micropython geschrieben und das wird hier im Forum >gar nicht gerne gesehen. Wenn es passt, nutze ich Micropython auch manchmal. Wäre super, wenn Du den Code posten könntest. Mit maximaler Rate zu sampeln und dann die Daten auf dem PC auszuwerten scheint mir extrem brauchbar.
> Wenn ich beim Hersteller arbeiten würde, dann würde ich erst mal > versuchen, eine guten Workaround zu finden, der das Problem abstellt, > bevor ich mich weiter dazu äußere. Als guter Hersteller würde ich vor der Suche nach einem workaround die praktischen Auswirkungen untersuchen. Also auf den (Referenz)-Applikationen/Boards die Regression-tests laufen lassen. Den Kunden könnte man bitten, das gleiche zu tun, vielleicht schmiert man ihm noch den Honig des "Early Adopters with special customer support" ums Maul. Sollte sich dabei was zeigen, wirds nach Schwere der Auswirkung und Möglichkeit der Mitigation klassifiziert. Aus letzteren kann man dann verschiedene Empfehlungen intern und in Richtung Kunden ableiten, beispielwweise: * Dok anpassen und Reports aus dem Feld beobachten * Bei regulärer Wartung Firmware-Update aufspielen * sofort Firmware-Update aufspielen * Bei Gelegenheit Hardware tauschen * ... * Rückruf-Aktion Normalerweise hat eine (auditierte) Firma eine entsprechende Prozessbeschreibung (life cycle managment, complaints response). https://de.wikipedia.org/wiki/Regressionstest https://em360tech.com/tech-article/understanding-computer-hardware-risk-mitigation-methods > Also ja, es ist ein spannender Fehler, aber praktisch kostet der nichts extra. Eben, wobei "Fehler" dramatischer klingt als dessen Auswirkungen in Echt sind. Man könnte auch "Vernachlässigbarer Fehler" sagen, oder "Schluckauf an einer Stelle wo es keinen stört".
:
Bearbeitet durch User
Bradward B. schrieb: > Sollte sich dabei was zeigen, wirds nach Schwere der Auswirkung und > Möglichkeit der Mitigation klassifiziert. Aus letzteren kann man dann > verschiedene Empfehlungen intern und in Richtung Kunden ableiten, > beispielwweise: > * Dok anpassen und Reports aus dem Feld beobachten > * Bei regulärer Wartung Firmware-Update aufspielen > * sofort Firmware-Update aufspielen > * Bei Gelegenheit Hardware tauschen > * ... > * Rückruf-Aktion Langeweile mit ShitGPT vertrieben?
Norbert schrieb: > Langeweile mit ShitGPT vertrieben? Ich hatte "Geschwurbel" auf den Lippen aber Deine Bezeichnung ist 100 x besser. Sie trifft den Kern und den Pudel ;-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.