Ich habe mir aus Bequemlichkeit das im Betreff genannte Displaymodul mit ein paar Tasten um ein OLED herum besorgt und auf I2C gejumpert. Steht default auf 4-wire SPI und ist eigentlich für Raspi u.ä. gedacht. Dafür gibts auch Treiber. Will das aber mit einem uC ansteuern. Leider bekomme ich auf keiner Device-Adresse ein ack. Da im verfügbaren Schaltplan schon die Verbindungen der Tasten zum Steckverbinder nicht korrekt sind: einfach eine Frage hier ins Forum, ob jemand schon das Display unter I2C erfolgreich in Betrieb nehmen konnte? Über einen Tipp welche Bugs noch in der Doku stecken wäre ich dankbar!
Angehängte Dateien:
-
IMG_1337.jpeg
210 KB -
IMG_1336.jpeg
130 KB
Wulf D. schrieb: > Leider bekomme ich auf keiner Device-Adresse ein ack. Wie hast du das festgestellt? Messung der Signale auf dem Bus? Wie groß sind deine Pull-Ups und auf welcher Adresse erwartest du das Modul? > IMG_1337.jpeg So ist das Modul nicht auf I2C gejumpert (s. Anleitung)
:
Bearbeitet durch User
Wulf D. schrieb: > Leider bekomme ich auf keiner Device-Adresse ein ack. Mit welchem Controller und welchem Programm?
Ich habe SCL und SDA auf dem Oszi, ist ja bei neuen I²C-Devices fast unumgänglich. Ich nutze die OLED Library von Michael Köhler, wurde hier auch schon vorgestellt. Kann mit ssd1306/ssd1309/sh1106 Displaychips umgehen. Läuft auf einem AVR Tiny 2-Series unter Nutzung des HW-TWI. Von Microchip gibt es ein Tutorial und Beispielcode im Github, der ist aber bezüglich der Ack-Abfrage nicht sauber. Funktioniert mit gemäßigtem Timing trotzdem, aber da hätte ich mehr Sorgfalt erwartet. Habe noch ein Dokument "1.3inch OLED HAT User Manual" ein paar HW-Hinweise gefunden, zusammen mit dem Schematics kann man die Pins für die Tasten dann richtig zuordnen. In dem Dokument ist auch eine Tabelle wo ein RESET gelistet ist. Hatte ich bei andereren OLEDs noch nicht. Nach dem Reset-Anschluß funktionierte das Display auf Adresse 0x78, wie all die anderen kleinen OLEDs von 0,96"-1,3". In der Doku stand Adresse 0x3C, aber das ist das gleiche wenn man den Shift für das R/W Bit berücksichtigt. Danke für die Rückmeldungen. Der Punkt ist erledigt, Display funktioniert nun sehr gut.
Wulf D. schrieb: > Nach dem Reset-Anschluß funktionierte das Display auf Adresse 0x78, wie > all die anderen kleinen OLEDs von 0,96"-1,3". 0x78 kann nicht die Adresse lt. I2C-Spezifikation sein, weil für die Adresse nur 7 Bit zur Verfügung stehen.
https://www.waveshare.com/wiki/1.3inch_OLED_HAT#Software Die Software image2lcd gibt es anscheinend nur in Chinesisch. Hier ein Teil des CHM-Hilfefiles. Die "Democodes" sind wohl für den Raspi gedacht.
> 0x78 kann nicht die Adresse lt. I2C-Spezifikation sein, weil für die > Adresse nur 7 Bit zur Verfügung stehen. Das wissen aber nur Leute die irgendeine beliebige eine Doku ueber I2C gelesen haben. Mittlerweile besteht die Kompetenz aber ausschliesslich im googlen und kopieren. Man darf da nicht mehr soviel erwarten! Vanye
Also bei mir ist bei 7 Bit die höchste Adresse 127 oder 0x7F. Und das ist größer als 0x78, oder? Bei diesem Display ist die Adresse aber 0x3C und das I2C Adressbyte dann 0x78.
muss mich (leider) Vanye R. (vanye_rijan) 09.12.2024 10:57 anschließen... Laut waveshare ist das ein SH1106. Wenn du wirklich nur das Display, also ohne Buttons, nutzen willst, gibts viele funktionierende Treiber auf Github. Ich bin mit dem glücklich geworden: // ss_oled (Small, Simple OLED library) // Copyright (c) 2017-2019 BitBank Software, Inc. // Written by Larry Bank (bitbank@pobox.com) Etwas verschlankt (Soft-I2C rausgeschmissen), Target ist Raspi-Pi Pico mit SDK 2.0 PS: noch simplere 1,3"-OLEDs gibts bei AZDelivery. (wenn man das hier so sagen darf, wenn nicht @admin Hinweis löschen)
:
Bearbeitet durch User
> noch simplere 1,3"-OLEDs gibts bei AZDelivery. (wenn man das hier so > sagen darf, wenn nicht @admin Hinweis löschen) Alle China-Oleds die ich bisher gesehen habe (eine Menge) hatten alle sehr aehnliche, aber nicht immer identische Driver-ICs. Die sind also letztlich alle gleich simple und unterscheiden sich nur mal in einem Register oder etwas anderem Init. AUsserdem haben die Entwickler dieser Adapterboards manchmal auch so ihre Probleme mit DAtenblatt lesen. Die verwechseln dann schon mal I2C mit SPI und verwenden die falschen Bezeichnungen. SO hier und da war da bei mir kreatives Raten notwendig. Vanye
J. S. schrieb: > Also bei mir ist bei 7 Bit die höchste Adresse 127 oder 0x7F. Und das > ist größer als 0x78, Touché
> Laut waveshare ist das ein SH1106 https://cdn.velleman.eu/downloads/29/infosheets/sh1106_datasheet.pdf Hatschi! Demnach heißt der Hersteller Sino Wealth, (chinesische "Gesundheit"?). Ich verstehe trotzdem nicht, wieso 0x7F kleiner als 0x78 sein sollte.
Christoph db1uq K. schrieb: > Demnach heißt der Hersteller Sino Wealth, (chinesische "Gesundheit"?). Wealth .... Gesundheit ..... aha ..... Du verwechselst das mit "Health".
Jaja Wohlergehen oder sowas. Die Abba-Frauen suchten in Money-money-money einen wealthy man. Gutsituiert.
:
Bearbeitet durch User
Christoph db1uq K. schrieb: > Jaja Wohlergehen oder sowas. Wohl eher: Wohlstand
:
Bearbeitet durch User
Christoph db1uq K. schrieb: > Jaja Wohlergehen oder sowas. > Die Abba-Frauen suchten in Money-money-money einen wealthy man. Ja, ja, einen "Wohlergehen Mann". Ei sink ju can good inglisch.
JAA ich habe health und wealth durcheinandergebracht. Zufrieden? https://dict.leo.org/englisch-deutsch/wealth Wohlergehen ist laut leo eher welfare oder well-being > Also bei mir ist bei 7 Bit die höchste Adresse 127 oder 0x7F. > Und das ist größer als 0x78, oder? tät ich auch sagen, J.S. auch und Rainer hat es eingesehen.
Angehängte Dateien:
sind wir mal wieder leicht abgedriftet... :-) Wenn das Thema schon mal hoch gekocht ist: Ich würde gern diesem Treiber "https://github.com/bitbank2/ss_oled"; die deutschen Umlaute beibringen. Es gibt dieses Font-array "const uint8_t ucFont[]" Mir ist noch nicht ganz klar, wie es strukturiert ist und ob man einfach äöüß usw. hintendran pappen könnte. Mit welchem Generator bastelt man sich die dt. Umlaut? Viele Grüße runout Ach ja, der SH1106-Display-Controller taucht als "0x3C" am Bus auf.
:
Bearbeitet durch User
> Bei diesem Display ist die Adresse aber 0x3C > und das I2C Adressbyte dann 0x78. passt ja. Das sind die drei Pixeltabellen der Schriftzeichen uCFont, uCBigFont, uCSmallFont: https://github.com/bitbank2/ss_oled/blob/master/src/ss_oled.cpp Ich hab jetzt nicht nachgezählt, wie viele Zeichen es pro Tabelle sind, aber da müssten die Umlaute für ASCII jeweils irgendwo am Ende eingefügt werden.
ja, ja soweit klar. Ich nutze den "normalen" font: uCFont Irgendwie wird im Quellcode vom ASCII-Wert (0x30 = "0") der Offset 0x30 abgezogen und dann pointed der in das Array. Es könnten 8x8 Pixel sein(?) Trotzdem für mich noch kryptisch. Wie schon angefragt: Mit welchem Generator bastelt man sich die dt. Umlaute? Werde wohl im Datenblatt mal tieftauchen müssen. runout
> Mit welchem Generator bastelt man sich die dt. Umlaute?
Also ich wuerde ja einfach die Pixel des "a" kopieren und dann noch zwei
Punkte drauf machen, einfach so binaer. So schwer ist das doch wohl
nicht oder?
Viel interessanter ist das schon die Frage wo im Zeichensatz sollen
deine deutschen Sonderzeichen liegen damit sie korrekt wiedergeben
werden wenn du dieses Sonderzeichen in deinem Sourcecode nutzt.
Vanye
Der von mir genutzte OLED Treiber von Michael Köhler hat alle deutschen Umlaute und noch einiges mehr: vielleicht kannst du dir in der Font-Tabelle etwas abschauen.
Mein "Apple]["-Nachbau hatte ein Zeichensatz-Eprom das daraus "AppleÜÄ" machte, vermutlich nach der Norm https://de.wikipedia.org/wiki/DIN_66003 Das meinte ich mit "irgendwo am Ende". Die machte aus dem amerikanischen 7bit-ASCII ein deutsches.
Hallo Zusammen, danke erstmal für die Hinweise bzw. den Quellcode. Ich habe hier noch eine Implementierung gefunden: https://forum.g-heinrichs.de/viewtopic.php?t=125 Naja, in BASCOM aber immerhin. Die dt. Umlaute sind einfach hintendran gepappt und jeder einzelne Umlaut wird "gecastet" und gezielt in das Fontende reingegriffen. Nicht so schön aber scheint zu funktionieren.
:
Bearbeitet durch User
> Mein "Apple]["-Nachbau hatte ein Zeichensatz-Eprom das daraus "AppleÜÄ" > machte, vermutlich nach der Norm Klar, und meiner einen SChalter um da wieder KLammern hin zu machen. :-D Aber solche Wege muss man ja heute nicht mehr gehen. Jeder COntroller wird die paar BYtes im Flash uebrig haben im die BItmaps irgendwo dranzuhaengen und muss man sich nur einen Code ausdenken wo man sie liegen haben will und referenzieren. VAnye
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.