Wie bringe ich OLED 1306 mit AVR/C ingang ?

Bitte um Hilfe. Das Ansprechen von OLED 1306 (SSD1306) funktioniert bei mir nicht.

Was ist geschehen
a) Zwei OLED 1306 gekauft (hier)
...... Bild hier  

b) Stromaufnahme nahe Null.
Erstmal Saft dran (dummerweise 5V vom 5V-Ausgang des nanoclones). Hatte nix geleuchtet, Stromaufnahme blieb unerheblich. Auch spätere Stromversorgung 3,3V direkt vom Labornetzteil ans Steckbrett brachte die Stromanzeige nur auf 0,001 A

c) Software - erfolglos
Verschiedene, arduinospezifische Software durchgegangen, um mir eine Vorlage für Ingangsetzten vom AVR direkt zu erarbeiten. Erfolglos. Auch die Suche nach einem *.hex-file für den verbreiteten mega328 war ohne Erfolg.

d) USB-I²C-Adapter von ELV (den) als Testgerät
......Bild hier  
hergenommen und ans Steckbrett (mit Labornetzteilversorgung) angeschlossen: GND, SCL, SDA.

e) I2C antwortet nicht.
Ansprechen des OLED mit Adresse 0x78 geprobt. Not-Acknowledge ist die einzige Antwort.

d) Leichte Verweiflung insbesondere deswegen, weil keinerlei Reaktion und keine Stromaufnahme erkennbar ist.

Nun bitte ich darum, dass mir jemand über die ersten Schritte hilft. Oder der mir versichert, dass ich die Dinge mit den 5V schon geschossen hätte.
Was könnte ich tun, um wenigstens einen Hauch Leben in das (aus dem) Display zu bringen. Leider spricht das Teilchen nur I²C - eine Fremdsprache die ich mit Mühe und nur teilweise kann/kenne. Anfangs reicht mir Textdarstellung konstanter Größe aber variabel hoher Text und Grafik wäre natürlich gigantisch.

Danke im Voraus und schöne Feiertage.

Nachtrag: I²C mit Takt 400 kHz und 100 kHz

Nachtrag am 23. Apr. 2017, 17h26: Abschließende Zusammenfassung zu meiner knappen Erfahrung mit OLED1306

Sieht nach einem grösseren Problem aus. Das Ding verträgt nur 3,3V als Stromversorgung und Eingänge. Könnte ein Totalschaden sein.
Wenn es gar nicht geht könnte ich dir mein Programm schicken. Ist allerdings nicht mit I2C Bus. Dürfte aber kein Problem sein, da ich viel mache mit I2C Bus
achim

Hallo,
in den Rezensionen steht etwas von einer anderen I2C-Adresse (0x3C) und es werden viele Beispiele verlinkt. In den schlechten Bewertungen ist auch die Rede von falsch gelieferten Displays usw.
Sind auch Pullup-Widerstände verbaut?
Braucht das Display noch Abblockkondensatoren?
Grüße, Bernhard

Erstmal vielen Dank für Eure Antworten.

Zitat:

---

.. Das Ding verträgt nur 3,3V als Stromversorgung und Eingänge. Könnte ein Totalschaden sein ..

---

Sieht leider ganz so aus. Hmmm, bei 1.7 V Überspannung ein Totalschaden - hmmm. Das is ja nix für mich!

Zitat:

---

Zitat von BMS

.. anderen I2C-Adresse (0x3C) .. Pullup-Widerstände verbaut? .. Abblockkondensatoren? ..

---

Danke. 0x3C hatte ich auch schon getestet (gehabt), Pullups sind dran - 4k7 und zwischen GND und Vcc hängt ein 10 µF/100V.

Tja, die werde ich wohl abschreiben müssen. Schade.

Hast du nen Arduino zur Hand?
Dann teste das Ding doch einfach mal- am besten mit der Lib. von Adafruit.

Die, die ich davon so im Umlauf hab, vertragen sämtlich auch 5V und können per I2C problemlos angesprochen werden.
Dann weisst du jedenfalls ob das Ding läuft.
Und auch die Adresse kannst du so easy rausfinden: es gibt ein Progrämmchen namens I2C-Scanner. Das liefert brav alle, am Bus gefundenen, Adressen in die Konsole.

Habe mal versucht die Daten zu finden. Gibt ja kaum ein anständiges Datenblatt dazu. Scheinbar verträgt das Oled 3,3V und 5V. Die Stromaufnahme sollte bei max. 10mA liegen. Es bestehen moch Chansen das geht. Mit dem USB / I2C von ELV habe ich leider keine guten Erfahrungen gemacht. Ist sehr eigenwillig und kompliziert. Bevorzuge was anderes. Versuche es zu testen, dann kann ich mehr sagen
achim

Danke Rabenauge, danke Achim.S.

Zitat:

---

.. teste das Ding .. mit der Lib. von Adafruit .. Und auch die Adresse kannst du so easy rausfinden: .. I2C-Scanner ..

---

Libs für Arduino - na ja, ich kann KEIN "arduinolanguage", kenne auch nicht die arduino-IDE und hab sie nicht installiert. Danke für den Tip mit dem Scanner - den habe ich in (fast) allen meinen I²C-Masterplatinen. Beim Archie z.B. sucht der Zentralrechner nach seiner Peripherie (nur die I²C-Slaves) und meldet die auf die Startseite (und reagiert auch intern drauf). Also - Adressbereich softwaremässig umgestellt

Code:

---

// ============================================================================= =
 void i2clook (void)            // Welche I²C-Devices existieren? Liste ?
 {                              //                              Aufruf    main =>
// Teste I²C-Schreibadressen von 0x70hex bis 0xAC, 112 - 254 (früher bis 0xFC)
//  ##>> Testbereich evtl. neu definieren
//      Erfolgsmeldung(en) ausgeben mit Adresse dez und hex, Fehlsuche mit "-"
  uint8_t jaflag = 0;          // Ja-Flag
  u8    aktptr  =      0;      // Aktuelle I²C-Adresse
// - - - - - - - - - - - - - - -

---

und siehe da, der Test bringt ein glaubhaftes Ergebnis (copy&past vom Terminal) :

Cxxx arno_x00 328/20 16 Apr 2017 09:28
UART0_64 110 k
Suche I²C-Devices im Bereich 0x00/_0dez - 0xFC/252dez
Jedes '-' bedeutet: Slave/s nicht vorhanden oder defekt
------------------------------------------------------------
Slave addr 120 dez = 0x78
------------------------------------------------------------------
I²C-Slaves gesucht bis (dez) 252

Zitat:

---

.. Gibt ja kaum ein anständiges Datenblatt dazu. Scheinbar verträgt das Oled 3,3V und 5V ..

---

Meins verträgt wohl die 5V - denn der Scan läuft mit 3,3 V und 5V - jeweils als Versorgung und Signalpegel.

Ok, der erste Schritt ist also getan: das Ding reagiert auf Zuruf. Sozusagen noch immer. Jetzt kommt der schwierige(re) Teil, die softwareseitige Implementierung des Dings. Da hoffe ich, dass das nicht sooo lange dauert :-/ -- leider habe ich KEIN einziges einfaches, kurzes, verständliches Beispiel in AVR8/C gefunden :-/

Danke allen Helfern für Ihre Mitarbeit!



@Achim.S: das ELV Ding ist recht schick, wenn man sich mal dran gewöhnt hat. Beispiel (zufällig):

Code:

---

- - - - - - - - - - - - - - - - - - - - - - - - - - - -
Fahre Servo 1 auf PWM 400 - und lies sofort Daten zurück
v----- Dies ist der Befehl zum Adressieren des Targets
v    v--- Stopbefehl
v    v    v-- Dies ist die Adresse, ab der geschrieben wird
s 84 p w 64  01  01  90  01  00  00  00  00  00  01  p s8460p r10p  <  <  Nur EIN Befehlsstring :-)
hex-Adresse  64  65  66  67  68  69  6A  6B  6C  6D
dez-Adresse 100 101 102 103 104 105 106 107 108 109
=======================================================

---

Läuft aber leider nur über das (eher gewöhnungsbedürftige HTerm)

HTerm - ist leider "sehr" alt und seit gefühlten 10 Jahren nicht gepflegt. Besser gesagt, vergessen worden (kein Intresse mehr dran).
Mache alles mit dem "normalen C" und bin sehr zufrieden damit. Das einzigste was fehlt ist ein gute Anbindung an den PC. Suche noch nach einer guten Lösung.
Kennst du was dazu? oder Nachfolger von HTerm? So was vielleicht wie WLAN mit I2C Bus?
An einem Beispiel der Einbindung vom Oled an den Bus bin ich auch interessiert. Falls du was findest.
achim

So, die chose ist geritzt. Einfach das Atmel Studio 7.? am Desktop installiert (gabs bisher nur am Notebook) und das verdaut auch die Beispiele im Netz mit den *.cpp´s. Und das Terminal zeigt schon die ersten, selbst kreierten Bitfelder (8.x.8 ) bzw. Buchstaben - mal sehen was draus wird und was man mit den selbst verwalteten 128x64 Bitfeldern anfangen kann. Seltsam sind die zwei Farben bei meinem Displays: oben ein Streifen weiß, die Hautpsache aber blau.

@achim:

Zitat:

---

HTerm - ist leider "sehr" alt .. Mache alles mit dem "normalen C" .. was fehlt ist ein gute Anbindung an den PC. Suche .. Lösung ..

---

Alt ist ja nun kein Synonym für schlecht. Na ja, mit fast 5 MB ist es etwas sehr groß, aber zusammen mit dem ELV-USB-I²C ist es bei mir ein sehr praktisches Werkzeug. Terminal geht zum Beispiel bei br@ys Terminal auch mit knapp 300 k, für mich die beste Lösung. Ich benutze das Terminal von br@y (das 2004er) seit "Jahren" für "alles" was über UART reinkommt oder reinkommen soll. Als Adapter dazu den schicken AVR-USB von pololu (item#: 1300) - der hat auch gleich noch ein minimalistisches 5V-DSOszilloskop.

- - - Aktualisiert - - -

Ein Problemchen bleibt, eine Frage.

Beim Compilieren (des past´n´copy Codes) bekomme ich Warnungen - alledings wird (wie gewohnt bei NUR Warnung) ein lauffähiger code erstellt. Die Warnung ist wech, wenn ich den Codeteil "int i = 0" ändere gegen "unsigned int i ..".

Fehlerbeschreibung:
Warning comparison between signed and unsigned integer expressions [-Wsign-compare]

bei Code:
for (int i = 0; i < sizeof(bitmap2); ++i) {
mit "sizeof" = highligthed

Frage: Klar, "int" ist vorzeichenbehaftet. Aber wo(her) bekomme ich das Vorzeichen von sizeof ? Das sollte ja sinnvollerweise ein vorzeichenloser Wert sein ! ?

Ich habe Hinweise gefunden, dass "sizeof" in der stddef.h des WinAVR-20100110 liegt, dort finde ich aber nur den Kommentar /* Unsigned type of `sizeof' something. */

Danke für die Hilfe

- - - Aktualisiert - - -

Nachtrag: das "Problemchen" mit dem sign von "sizeof"

hi,
schön dass es noch funktioniert, wie es sich anhört.
einen 3EUR Arduino würde ich mir zwar an deiner Stelle auch mal anschaffen (ist praktisch zum schnell mal austesten), aber Libs für "richtiges C" habe ich hier auch, ebenfalls auf der Basis für Adafruit Libs, aber für gcc/Linux. Vlt hilft es ja trotzdem!

http://www.mindstormsforum.de/viewto...p=69371#p69370

sizeof ist egal ob Datentyp Vorzeichenbehaftet ist oder nicht, es ist immer eine Ganzzahl >= +1:
sizeof(unsigned char) == sizeof(signed char) == 1
sizeof(unsigned int) == sizeof(signed int) == 2 (bei 8bit-AVRs)

Kleine Ergänzung zum Projektchen hier; Thema "Flanken bei 400kHz bzw. 200 kHz" beim Oled1306.

Beziehst du dich mit deinen "Flanken" auf meinen verlinkten Post zum OLED am Raspi, wo ich schreibe, dass das OLED bei 100-400kHz läuft? Hast du ein grundsätzliches 400 KHz Problem bei deinen AVRs?
Bei meinen Raspis hatte ich noch keine Probleme bei FAST I2C beobachtet (400 kHz, 3.3V), darauf bezog sich ja mein Hinweis, und nicht auf AVRs. Weiterhin laufen weitere Geräte ebenfalls störungsfrei bei 400kHz auf demselben Bus (ein 3x3D-IMU und 2 MCP23017).
Bei 100kHz jedenfalls läuft es ziemlich quälend langsam und bremst die Programme unglaublich aus, wenn man die OLED-Anzeige-Routinen nicht in eigenen threads laufen lässt, und auch die restlichen i2c Geräte auf demselben Bus werden dann bei 100kHz ebenso erheblich ausgebremst.

Zitat:

---

Beziehst du dich mit deinen "Flanken" auf meinen verlinkten Post zum OLED ..

---

Nein......

Zusammenfassung zu meiner knappen Erfahrung mit OLED1306

Ich habe zwei mal je zwei Stück gekauft.
Die erste Lieferung war/ist defekt, ich habe schon reklamiert und bekomme das hoffentlich erstattet. Statt weißem Text auf schwarzem Grund gibts gelb oder blau auf schwarz, getrennt von zwei "toten" Pixelreihen. Anm.: ich kann den Hexfile für dieses Beispiel - für nanoclone/mega328/20 MHz .. 16 Mhz geht natürlich auch - bei Wunsch gerne hier hochladen.

......Bild hier  

Die zweite Lieferung ist ok.

Die beiden Muster sind deutlich unterschiedlich (Ansicht des jeweils gleichen Teils übereinander).

......Bild hier  

Zu allem Überfluss ist das Pinout der Versorgung bei meiner zweiten Sendung genau umgekehrt wie beim ersten Teil. Witzig: die Backplane enthält die Möglichkeit GND und Vcc mittels zweier 0Ω-Brücken zu tauschen *ggg*, siehe Bild.

Noch Fragen ?

Wichtig(er)es: Sowohl Versorgung (Vcc) als auch der I²C-Bus läuft bei mir seit ?Stunden? mit 5V (Versorgung vom 5V-Pin des nanoclones); Verbrauch etwa 10 mA bei der dargestellten geringen Pixelaktivierung. Ebenso ist eine klaglose Funktion bei 3,3V gegeben (Versorgung vom 3,3V-Pin des nanoclones). Mit meiner I²C-Leitung, 20 cm Flachbandkabel vom nanoclone/mega328/20 MHz, läuft das Teilchen mit 400 kHz I²C-Takt einwandfrei, dazu ein kleiner Test mit I²C-PullUp 4,7 (dürftige Signalspitzen) und mit dem "richtigeren" Pullup 1k6 Ω, der eine gute High-Flanke auch beim hohen Takt bringt.

Ein (nicht wirklich repräsentativer) Test des sowieso defekten Teils: trotz minutenlanger Bestromung mit verdrehter Polarität funktioniert das Teil nach diesem Akt ebenso wie vorher - aber eben noch fehlerhaft wie zuvor. Keine zusätzlichen Schäden - aber egal: NICHT nachmachen, keine falsche Polarität am Eingang!

@oberallgeier

Noch eine Anmerkung zu deinen Bildern: man kann schön sehen, welches auch für 5V ausgelegt ist. Das Linke hat zusätzlich zu den Rs und Cs noch einen Dreibeinregler drauf, mit Q1 beschriftet. Der sorgt für den Betrieb bei 5V, das Oled selbst ist immer für 3,3V. Den gleichen Aufbau hab ich auch auf dem etwas größeren Bruder mit 1,3" gefunden. Da kann man übrigens ebenfalls Vcc und GND tauschen. So hab ich beide gleich gejumpert und kann auf meinem Testboard 0,96" und 1,3" einfach hin- und hertauschen. Wenn man das Layout einer Hauptplatine so macht, wie beim rechten Modul (Vcc außen), kann man verschiedene Displays so jumpern, daß sie alle passen.

Zitat:

---

Die erste Lieferung war/ist defekt, ich habe schon reklamiert und bekomme das hoffentlich erstattet. Statt weißem Text auf schwarzem Grund gibts gelb oder blau auf schwarz, getrennt von zwei "toten" Pixelreihen

---

Ich denke nicht, daß die kaputt sind, die sollen so sein. Sie sind ja für irgendein Produkt gebaut worden, werden jetzt aber für Bastler verkauft:

Anhang 32562

Bild von Aliexpress

MfG Klebwax

Zitat:

---

Zitat von Klebwax

.. man kann schön sehen, welches auch für 5V ausgelegt ist. Das Linke hat .. noch einen Dreibeinregler drauf, mit Q1 beschriftet ..

---

Danke für diese Erläuterungen, die mir leider nicht auffallen. Dazu verstehe ich zu wenig von Elektronik. Da sind natürlich solche Hinweise goldwert!

Es waren also die "ersten" beiden Displays, die mit der simplen Unterseite, die doch über den Jordan gegangen sind. Zu lange Betrieb an 5V konnten sie wohl nicht ab. Der große A hatte mir inzwischen, völlig unkompliziert, die Rücküberweisung des Kaufpreises zugesagt, weil die ja in falscher Farbe und mit diesen toten Zwischenzeilen geliefert wurden.

Die Teile mit der komplexen Unterseite laufen und laufen und ... Und das ist dann (m)ein vierfacher Anfang:
OLED, Pixeldarstellung, C++ und Studio7. Dumm, dass der drehende Sekundenzeiger im Achsbereich des Zifferblattes noch Fehlstellen hinterlässt - da muss noch ne kleine Reparatursequenz her. Auf die Pixelkonstruktion des Ziffernblattes bin ich schon stolz: das erledigen ganze drei Pattern, Bitmaps mit 29x8, 11x8 und 3x8 Bits, also schlanke 43 Bytes, die in unterschiedlichen (90°-) Stellungen - zum Uhrkreis zusammengeheftet werden. Ansonsten ist die Programmierung noch recht aufwendig - mir fehlt ne passende Grundprogrammierung mit der ich dann z.B. Text ähnlich wie im LCD-Modus ausgeben kann mit Funktionen wie

Code:

---

SetCursor (2, 10) => SetCursor (x,y), x=zeile {0,63}, y=Pos {0, 127}

---

und einer Textausgabe ähnlich

Code:

---

oled_string("    online    ")

---

- also noch viel zu tun.

Nur - C++, Sprache und Syntax, ist noch recht nebulös, aber da habe ich ja eine schier unendliche Auswahl an Tutorials. Ich ver-/suche zwei, drei für mich passende, eher mikrocontrollerlastige Tutorials zu finden :-/ . Vermutlich ists nicht besonders sinnvoll, C++ für den Atmel-Crosscompiler, bzw. der entsprechenden IDE, auf nem PC-Compiler zu lernen und dessen Betriebssystem/-anbindungen verstehen bzw. benutzen zu lernen.

Mal als kleine Selbstdarstellung der aktuelle Stand des Projektchens.

......Bild hier  

Nachtrag:
In meiner tonnenschweren Buchsammlung habe ich vier Bände "Turbo C++" von Borland gefunden: Einführung, Programmierhandbuch, Benutzerhandbuch, Referenzhandbuch. Etwas betagt: 1990. Ist es sinnvoll, diese Dinge als Nachschlagwerk zu benutzen? Immerhin sind inzwischen neue Standards erschienen!?!

Zitat:

---

Zitat von oberallgeier

Etwas betagt: 1990. Ist es sinnvoll, diese Dinge als Nachschlagwerk zu benutzen? Immerhin sind inzwischen neue Standards erschienen!?!

---

Naja, das ist immerhin sieben Jahre vor dem ersten Standard. Damals war C++ höchstens im Rohbau fertig.