Hier meine Fragen , habe ich mal von der KI machen lassen...
Hallo zusammen,
ich habe ein etwas ungewöhnliches Problem mit einem 128x64 OLED mit I²C, Adresse 0x3C und ESP32c3.
Das Display lief mit meinem bisherigen Programm bisher problemlos. Seit einigen Tagen wird die gesamte Darstellung plötzlich um 180° gedreht angezeigt.
Das Interessante dabei:
Hardware wurde nicht verändert.
Das gleiche OLED wird verwendet.
Mein bisheriger Sketch wurde nicht bezüglich der Displaydarstellung geändert.
Ich verwende den OLED-Treiber von Stefan Frings.
Auch eine ältere Version der oled.h / oled.cpp von etwa 2020 wurde getestet.
Mit der alten Version ist die Darstellung ebenfalls um 180° gedreht.
Die Drehung betrifft die komplette Anzeige, also Text und Grafiken.
Die Koordinaten funktionieren grundsätzlich, nur die gesamte Darstellung ist kopfstehend.
Arduino IDE 1.8.13.
Die OLED-Library arbeitet mit Software-I²C.
In der Initialisierung des Treibers stehen beispielsweise:
i2c_send(0xA1); // segment remapping mode
i2c_send(0xC8); // COM output scan direction
Mir ist bewusst, dass diese Befehle die Orientierung bestimmen. Allerdings erklärt das für mich nicht, warum eine alte Version des Treibers, die zuvor funktioniert hat, plötzlich ebenfalls 180° gedreht darstellt.
Hat jemand diesen Effekt mit dem Stefan-Frings-OLED-Treiber schon einmal gehabt?
Besonders interessant wäre für mich, ob es eine bekannte Ursache gibt, bei der sich die Displayorientierung plötzlich ändert, obwohl OLED, Verkabelung und Programm unverändert sind.
Falls Stefan Frings hier mitliest: Vielleicht ist Ihnen dieser Effekt bereits begegnet.
Hier meine Fragen , habe ich mal von der KI machen lassen...
Problem mit einem 128x64 OLED mit I²C, Adresse 0x3C und ESP32c3.
Das Display lief mit meinem bisherigen Programm bisher problemlos. Seit
einigen Tagen wird die gesamte Darstellung plötzlich um 180° gedreht
angezeigt.
Das Interessante dabei:
Hardware wurde nicht verändert.
Das gleiche OLED wird verwendet.
Da stimmt was nicht an den Angaben.
Welches "Das Display" das bisher Problemlos lief ? Datasheet ?
Nachbau ? Display aus gleicher Charge?
Ich sehe da viele delays. Kabellänge geändert oder schon Grenzwertig das Timing ?
In der Initialisierung des Treibers stehen beispielsweise:
i2c_send(0xA1); // segment remapping mode
i2c_send(0xC8); // COM output scan direction
Hi und Hallo
Dann schreib doch da mal 0xA0 und 0xC0 rein. Dann „müsste“ das ja wieder umdrehen. Würde sonst bedeuten, dass dein Soft I2C die Kommandos zum initialisieren garnicht verwendet oder die unteren Bits nicht sauber überträgt und das OLED evtl. „von Hause aus“ seine Vorzugsrichtung verwendet.
Was ich tun würde: einen alten Stand des Arduino-Sketches hochladen und mal kuggen. Man kann auch bei Start hinterm Display init mal 5 Sekunden Pause einbauen und in dieser Zeit mit ner Pinzette scl und sda überbrücken. Oder mal probieren, die Initialisierung testhalberweise wegzulassen. Aber dann wirds wohl garnicht angehen, weil die Ladungspumpen nicht gestartet werden.
Was hängt denn noch am I2C Bus?
Das mitm Oszi auszuzählen, ist mühsam, weil schon recht viele Initialisierungsbefehle gesendet werden. Unser EO213 dürfte das leider NICHT können. Dazu müsste der Befehl ständig wiederholt werden. Und für die Soundkarte isses ein wenig zu schnell. Aber signalintegrität (Flanken usw) ließe sich auch mitm älteren Gerät abschätzen.
Hast du denn Zugriff auf ein (Speicher)Oszi?
Viel Erfolg noch.
(Ich bin mit sicher; am Ende isses wieder was ganz banales und wir konnten alle was lernen)
Also:
Rotation absichtlich provozieren (A0 und C0) und Ergebins berichten.
Firmwarestände, chronologisch sortiert, installieren und schauen, ab welchem Stadium der Änderung der Spaß auftritt. Dann beide Versionen vergleichen.
mitm Oszi draufschauen und den Datenstrom dekodieren (lassen)
Ja klar. So ein Logikanalyser wäre perfekt. Man kann ja n zweiten Arduino hierfür nehmen, wenn man keinen LA besitzt.
Er schrieb ja, dass prinzipiell alles ginge, also wird das I2C Protokoll schon ansatzweise funktionieren, denke ich mal.
Wenn er einen Logikanalysator hat, kann er das verifizieren. Hatta aber sicher nich. Also dann wenigstens mitm Oszi auf Clock triggern und sich die Daten ansehen. Bei fallender Taktflanke müssen die stabil auf „H“ oder „L“ liegen. Das geht zur Not auch mitm D195 und acht LEDs, wenn man garnichts hat.
War ja auch nur n Tipp. Man kann Clock und Daten (100kHz) sicher auch anders visualisieren.
Da wird sein Soft-I2C iwie „ausgebremst“, tippe ich mal.
Ich würde vorher die Qualität der Signale prüfen, ansonsten sind die Erkenntnisse vom Logic Analyzer wertlos. Bei schlechten Signalen kann das Display was ganz anderes verstehen, als der Logic Analyzer.
Das Display lief mit meinem bisherigen Programm bisher problemlos. Seit
einigen Tagen wird die gesamte Darstellung plötzlich um 180° gedreht
angezeigt.
Das Interessante dabei:
Hardware wurde nicht verändert.
Das gleiche OLED wird verwendet.
Mein bisheriger Sketch wurde nicht bezüglich der Displaydarstellung
geändert.
Aber wohl an anderer Stelle. Also: Änderung rückgängig machen. Verschwindet der Effekt dadurch: herausfinden, was genau ihn bewirkt.
Dazu vergleich man die Änderungen und überlegt, inwiefern sie den OLED-Treiber beeinflüssen könnten.
Habe jetzt alle meine OLED Displays getestet, und feststellen müssen das Eins eine 180 Grad Drehung anzeigt.
auf Grund der vielen Tests welche ich gemacht habe kann ich jetzt nicht mehr nachvollziehen das ich dieses gedrehte Display getauscht hatte, beim probieren.
Ich war auch schon soweit, alles so zu lassen wie es ist.
Aber dies ist bestimmt zu 99% das bezeichnete Problem.
Danke für Diejenigen welche eine ehrliche Hilfe Angeboten haben.
Ich war auch schon soweit, alles so zu lassen wie es ist.
Aber dies ist bestimmt zu 99% das bezeichnete Problem.
Danke für Diejenigen welche eine ehrliche Hilfe Angeboten haben.
Man könnte beim Testen natürlich auch einen Stapel machen mit 0°-Drehung und einen mit 180°-Drehung.
Vermutung: Das Display wird nicht vollständig initisialisiert und die verdrehte Darstellung ist schon "werkseitig" gesetzt. (Warum auch immer.)
Aber wie immer sind die wenigen kB Code mal wieder ein Staatsgeheimnis. Der aktuelle Code von Stefan Frings kann es jedenfalls nicht sein, denn der hat einen anderen Konstruktor.
Wie wir jetzt wissen, ist es wohl doch nicht die gleiche Hardware. Dazu bitte bedenken, dass die chinesischen Hersteller häufig kleine Details ändern ohne darauf hinzuweisen. Erschwerend kommt dazu, dass die Produkte meist ohne technische Unterlagen (Schaltplan, Datenblatt) und ohne eindeutigen Namen verkauft werden. Da kann man nie sicher sein, das zu bekommen, was man erwartet hat. Man muss jedes einzelne Teil nach der Lieferung kontrollieren.
Aber wie immer sind die wenigen kB Code mal wieder ein Staatsgeheimnis.
Der aktuelle Code von Stefan Frings kann es jedenfalls nicht sein, denn
der hat einen anderen Konstruktor.
Auf ein ähnliches Problem bin ich auch gestoßen.
Die Lösung war die richtige Initialisierungssequenz.
Zitat:
note: 0x81 and 0xC8, otherwise display mirrored
/Zitat
vorher:
0x81, 0xCF
Das sind "Zweibyte"-Befehle, wobei 0xC8 bzw. 0xCF der Parameter ist.
... auf Grund der vielen Tests welche ich gemacht habe kann ich jetzt nicht
mehr nachvollziehen ...
Da hilft es sich vorher einen kleinen Testplan zu machen und diesen durchzugehen. Da kann man auch gleich die Ergebnisse drauf notieren. Parallel entstehende Fotos, Screenshots, Quelltexte und/oder Messreihen werden ebenfalls gleich dem richtigen Test zugeordnet.
Damit hat man eine Chance hinterher noch nachzuvollziehen, was man da eigentlich gemacht hat.
Und immer nur an einem Parameter drehen, auch wenn die Versuchung groß ist!
Und immer nur an einem Parameter drehen, auch wenn die Versuchung groß
ist!
Da hast du Recht.
Aber bei diesen Problem spielt die Interesse warum?
es so ist am meisten mit.
Wenn ich es nötig hätte drehe ich das Display. Bei einzelnen Projekten kein Problem, ehe man Tagelang sucht.
Die (Doxygen-) Beschreibung findet man in der OLED.h und die Funktionsdefinition in der OLED.cpp.
Wenn man schon die "OLED.h" inkludiert, liegt der Verdacht nahe, dass sie sich darin befindet.
Die entsprechenden Binärcodes für die Display-Konfiguration sollten im Datenblatt des Display-Controllers beschreiben sein. (Wenn nicht, ist der Hersteller dem Untergang geweiht.)
Bau dir doch am ADC einen Spannungsteiler und je nach Typ und Version stellst du dort 1, 2 oder 3Volt ein und kannst anschließend im Code, je nach eingestellter Spannung, dein Display leicht abweichend initialisieren. Bei einem Typ drehst du es um 180Grad, beim anderen nicht. Brauchst auf der Platine blos zwei Widerstände ändern. Je nach dem, welches Display Dir unter die Finger kommt. Oder baust noch n kleinen Taster mit auf die Platine. Klick -> gedreht. Hast du vielleicht ein kleines Menü im Display? Dann bastle dort, zusätzlich zu „Helligkeit und Kontrast“, eben noch die Drehung mit rein. Dann bist du nächstes Mal fein raus.
Kannst ja froh sein, wenn Dir jemand die Initialisierung bereits angenommen hat.
Ich hatte so einen blöden 3D-Druck-Rahmen über dem Display, dass mir nur 122 x 58 Pixel freie Sicht blieben. Der Rest war verdeckt. Da durfte ich die Initialisierung fast komplett allein machen. Dabei half das Datenblatt vom Display-Controller und ein Blick in die ominöse „Oled.h“.
Hier noch eine Initialisierungsroutine für den Controller Type SSD1306 und "kompatible".
Was im File "Code Schnipsel" angegeben ist, sollte auf jeden Fall in die Initialissierungsroutine einfließen.
Der Rest war verdeckt. Da durfte ich die Initialisierung fast komplett
allein machen.
Und warum ausgerechnet das?
Ich hätte den Rahmen einfach vorsichtig weg gemacht oder den Versatz
beim Schreiben berücksichtigt.
Man will ja doch den ganzen Anzeigebereich, gerade bei den kleinen
Displays.
Man hätte dem Konstrukteur den Druck auf den Schreibtisch knallen sollen und ihn das neu machen lassen. Stimmt schon.
War aber in der Zeit nicht angezeigt. (musste halt fertig werden). Ich wollte da auch erst rumfeilen und den Bereich freilegen, aber das Design gab das wegen den Schrägen nicht her.
Nochmal tue ich mir das nicht an. Ging nämlich auch ne Menge Zeit drauf.
War aber in der Zeit nicht angezeigt. (musste halt fertig werden).
Ah, also wie ich bereits dachte.
Ne würde ich mir auch nicht antun, klar ist das eleganter als beim Schreiben die Pixel vom Rand abzuziehen, aber so absolut überflüssig wenn der Konstrukteur einfach sauber gearbeitet hätte.
Seit einigen Tagen wird die gesamte Darstellung plötzlich um 180° gedreht angezeigt.
Bei frühen OLED gabs das Problem der unterschiedlichen Alterung (Reduktion der Leuchtkraft) der Grundfarbpolymere und Ansätze dafür dies wieder auszugleichen, also dafür zu Sorgen das die Grundfarben eines Pixels gleichmäßig "verblassen".
(Software-seitiges Antiwear)
"Auf den Kopf stellen" nach einer gewissen betriebs war ein Ansatz dazu, nicht das das "versehentlich" aktiviert wurde.
(der bei rotierbaren Handhelds halbwegs funktioniert).
Und mit Arduino.
Den ASM-Krempel braucht er dann wohl nicht mehr.
Aber das war ja vorher nicht gesagt worden.
ASM habe ich vor 40 Jahren gemacht, das habe ich nach der wende aufgegeben.
Ach nee, PICs und AVR habe ich später noch mal damit zum leben erweckt.
Tue ich mir aber schon lange nicht mehr an.
