OLED zeigt nur wirre Pixel am I2C

[Manuel Z. (manuel_z)]

Hallo Leute,

mein EA OLEDM128-6 auf einer eigenen Platine zeigt nur wirre Pixel an. 
Egal was ich dem Display zum Anzeigen übertrage. Es kommt immer nur 
dasselbe wirre an Pixeln (siehe Anhang). Angesteuert wird es von einem 
RP2040, auf dem I2C ist noch ein DS3231SN als RTC und im Schaltplan noch 
ein Low Voltage I2C/SMBus
Accelerator der in Wirklichkeit aber nicht aufgelötet ist. Die 
Tracklänge des I2C habe ich auf den Millimeter gleich lang. Nach langer 
Fehlersuche bin ich dann auf Arduino IDE (RPI Pico/RP2040 by Earle F. 
Philhower 2.5.2) mit den passenden Parametern (Bord: Generic RP2040, FS: 
16MB, CPU-S:133Mhz,USB-Stack: Pico-SDK) umgestiegen. Spannungsversorung 
und Pins habe ich schon kontrolliert 12.7V + 3.3V liegen korrekt am 
Display. Auch den Schaltplan habe ich nochmals mit dem des Herstellers 
abgeglichen. Der I2C Scanner gibt mir für das Display die Adresse 0x3C 
und für den RTC die 0x68. Ich habe mehrere Bibliotheken versucht. Bei 
U8g2 (auch verschiedene Contructoren versucht) und Bibliotheken von 
Adafruit für den SSD1306 kommt immer dasselbe. Ich bin mir unsicher, was 
ich falsch gemacht haben könnte. Aktuell habe ich zwei Platinen die 
genau das selbe Fehlerbild haben. Hat jemand von euch einen Ansatz?
Danke im Voraus.

[DerEgon (Gast)]

Manuel Z. schrieb:
> Die
> Tracklänge des I2C habe ich auf den Millimeter gleich lang.

Das ist bei den niedrigen Taktraten von I2C vollkommen irrelevant.

Allerdings: Welchen I2C-Takt verwendest Du?

[DerEgon (Gast)]

Wo sind in Deinen "Schaltplan"-Fitzelchen die I2C-Pullups zu finden?

[Helmut -. (dc3yc)]

Dein OLED hat aber einen SSD1309 als Controller und keinen SSD1306! 
Steht zumindest in meinem Datenblatt. Probiere es doch mal mit diesem 
Treiber!

[Frank K. (fchk)]

Stimmt. Die I2C-Pullups finde ich auch nirgendwo.

Um zu sehen, was tatsächlich abläuft, ist ein Logicanalyzer das Mittel 
der Wahl. Diese 24MHz 8Ch Teile bei Amazon für 10...20€ reichen völlig 
aus. In der Zwischenzeit kannst Du ja verifizieren, dass sowohl SCL als 
auch SDA im Ruhezustand auf High sind. Sind sie das nicht, hast Du 
zumindest ein Problem gefunden.

fchk

[Manuel Z. (manuel_z)]

@DerEgon Danke für die schnelle Antwort.
I2C-Takt sollte bei 100k liegen. Ich bin mir da aber auch nicht sicher 
weil ich bei der Serial Baudrate auch 9600 vorgegeben habe aber trotzdem 
115200 eingestellt wird. Also dann trotzdem nur mit 115200 drauf komme.

Hier mal ein Codebeispiel:

#include <SPI.h>
#include <Wire.h>
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1306.h>

#define SCREEN_WIDTH 128 // OLED display width, in pixels
#define SCREEN_HEIGHT 64 // OLED display height, in pixels


#define OLED_RESET     3 // Reset pin # (or -1 if sharing Arduino reset pin)
#define SCREEN_ADDRESS 0x3C ///< See datasheet for Address; 0x3D for 128x64, 0x3C for 128x32
Adafruit_SSD1306 display(SCREEN_WIDTH, SCREEN_HEIGHT, &Wire, OLED_RESET);

#define NUMFLAKES     10 // Number of snowflakes in the animation example

#define LOGO_HEIGHT   16
#define LOGO_WIDTH    16

void setup() {
  Serial.begin(9600);
  Wire.setClock(100000);

  // SSD1306_SWITCHCAPVCC = generate display voltage from 3.3V internally
  if(!display.begin(SSD1306_SWITCHCAPVCC, SCREEN_ADDRESS)) {
    Serial.println(F("SSD1306 allocation failed"));
    for(;;); // Don't proceed, loop forever
  }

  // Show initial display buffer contents on the screen --
  // the library initializes this with an Adafruit splash screen.
  display.display();
  delay(2000); // Pause for 2 seconds

  // Clear the buffer
  display.clearDisplay();

  // Draw a single pixel in white
  display.drawPixel(10, 10, SSD1306_WHITE);

  // Show the display buffer on the screen. You MUST call display() after
  // drawing commands to make them visible on screen!
  display.display();
  delay(2000);
  // display.display() is NOT necessary after every single drawing command,
  // unless that's what you want...rather, you can batch up a bunch of
  // drawing operations and then update the screen all at once by calling
  // display.display(). These examples demonstrate both approaches...

  // Invert and restore display, pausing in-between
  display.invertDisplay(true);
  delay(1000);
  display.invertDisplay(false);
  delay(1000);
}

void loop() {
}

DerEgon schrieb:
> Wo sind in Deinen "Schaltplan"-Fitzelchen die I2C-Pullups zu
> finden?

Da gebe ich recht, da sind keine! Im RP2040 sollen schlechte verbaut 
sein, stand irgendwo in der Doku vom RP2040 ich hab da jetzt auf die 
schnelle es nicht gefunden. Hm.. ok kann ein Grund sein.

Helmut -. schrieb:
> Dein OLED hat aber einen SSD1309 als Controller und keinen
> SSD1306!
> Steht zumindest in meinem Datenblatt. Probiere es doch mal mit diesem
> Treiber!

Im OLEDL128-6 ist ein SSD1309 verbaut. Im OLEDM128-6 ist ein SSD1306 
verbaut. Aber mit SSD1309 hatte ich es auch schon versucht.

Frank K. schrieb:
> Stimmt. Die I2C-Pullups finde ich auch nirgendwo.
>
> Um zu sehen, was tatsächlich abläuft, ist ein Logicanalyzer das Mittel
> der Wahl. Diese 24MHz 8Ch Teile bei Amazon für 10...20€ reichen völlig
> aus. In der Zwischenzeit kannst Du ja verifizieren, dass sowohl SCL als
> auch SDA im Ruhezustand auf High sind. Sind sie das nicht, hast Du
> zumindest ein Problem gefunden.
>
> fchk

Ach, da fällt mir gerade ein, dass ich vergessen habe mit zu schreiben. 
Im Adafruit Example für den SSD1306 wird das Bild nochmals invertiert 
und ein Laufbild erzeugt. Das Bild mit den Pixeln wird dann auch 
invertiert und auch mit den Pixeln ein Laufbild erzeugt. Aber das 
Problem anhand der fehlenden Pull-up Wiederständen kann ich mir gut 
vorstellen.

[DerEgon (Gast)]

Manuel Z. schrieb:
> Ich bin mir da aber auch nicht sicher
> weil ich bei der Serial Baudrate auch 9600 vorgegeben habe aber trotzdem
> 115200 eingestellt wird. Also dann trotzdem nur mit 115200 drauf komme.

Das klingt irgendwie kaputt.

[Manuel Z. (manuel_z)]

DerEgon schrieb:
> Manuel Z. schrieb:
>> Ich bin mir da aber auch nicht sicher
>> weil ich bei der Serial Baudrate auch 9600 vorgegeben habe aber trotzdem
>> 115200 eingestellt wird. Also dann trotzdem nur mit 115200 drauf komme.
>
> Das klingt irgendwie kaputt.

Ich korrigiere mich. Ich habe gerade nochmals geschaut. Unter mein 
Ubuntu ist es mit CuteCom oder dem SerialMonitor von Arduino IDE egal 
was ich einstelle. Es kommt trotzdem. Cutecom zeigt mir auch, dass es 
eine 9600 @8-N-1 Verbindung ist.

[Manuel Z. (manuel_z)]

Frank K. schrieb:
> Stimmt. Die I2C-Pullups finde ich auch nirgendwo.
>
> Um zu sehen, was tatsächlich abläuft, ist ein Logicanalyzer das Mittel
> der Wahl. Diese 24MHz 8Ch Teile bei Amazon für 10...20€ reichen völlig
> aus. In der Zwischenzeit kannst Du ja verifizieren, dass sowohl SCL als
> auch SDA im Ruhezustand auf High sind. Sind sie das nicht, hast Du
> zumindest ein Problem gefunden.
>
> fchk

Zum verifizieren SDA und SCL ist im Ruhezustand auf High mit 3,299V.
Danke für den Tipp mit dem Logicanalyzer.

[DerEgon (Gast)]

Manuel Z. schrieb:
> Zum verifizieren SDA und SCL ist im Ruhezustand auf High mit 3,299V.

Wenn die Pullups zu schwach (d.h. zu hochohmig) sind, kann dieser Pegel 
zwar problemlos erreicht werden, aber steigende Flanken werden dann sehr 
langsam.

Das kannst Du mit einem Logikanalysator allerdings nicht sehen, dazu 
brauchst Du ein Oszilloskop. Damit solltest Du Dir die Taktleitung (SCL) 
ansehen.

[Manuel Z. (manuel_z)]

DerEgon schrieb:
> Das kannst Du mit einem Logikanalysator allerdings nicht sehen, dazu
> brauchst Du ein Oszilloskop. Damit solltest Du Dir die Taktleitung (SCL)
> ansehen.

Ich habe ein OWON HDS272S wobei ich aber schlecht damit umgehen kann. 
Ich bin damit auf die SCL Leitung am Display selbst gegangen und habe 
Zeit, Spannung und und Co so angepasst, dass man es "sehen" kann. Um 
ehrlich zu sein kann ich jetzt damit noch wenig anfangen.

[DerEgon (Gast)]

Stell das Oszi mal so ein, daß man mehrere Takte nacheinander sieht  Die 
Zeitbasis steht gerade auf 2 µs/div, mach da mal 50 µs/div oder 100 
µs/div draus.

[Stefan K. (stk)]

Zum OWON HDS272S:
Benutz den Tastkopf und nicht das Krokoklemmenkabel.
Stell den Schiebeschalter am Tastkopf auf 10x, das Oszilloskop ist schon 
darauf eingestellt.
Schließ die Masseklemme an einen GND-Anschluss in der Nähe des 
SCL-Anschlusses an.
Pass Triggerlevel und Zeitbasis so an, dass mindesten eine steigende und 
eine fallende Flanke zu sehen sind.
Und: nutz die Screenshot-Funktion des Oszilloskops.

[Schlaumaier (Gast)]

Was soll das Display anzeigen. ???

Wenn es nur Text sein soll, wechsel die Libs.

Ich steuere OLEDS mit Text SO an.

Nur ausschnitte aus den Code !!!!

#include <Wire.h>
#include "SSD1306Ascii.h"
#include "SSD1306AsciiWire.h"
#define oled_adresse 0x3C

SSD1306AsciiWire oled;

void setup() {

  Wire.begin();
  Wire.setClock(400000L);
  oled.begin(&Adafruit128x64, oled_adresse);
  oled.setFont(TimesNewRoman16); // Auswahl der Schriftart
  oled.clear(); //Löschen der aktuellen Displayanzeige

}
Void anzeige {
   oled.clear();
    oled.println("Aktuelle Karte");
}

[Manuel Z. (manuel_z)]

Schlaumaier schrieb:
> Was soll das Display anzeigen. ???
>
> Wenn es nur Text sein soll, wechsel die Libs.

Erstmal egal was es anzeigen soll, hauptsache es zeigt erstmal etwas an 
was auch kommen soll. Probehalber habe ich es mal gerade gemacht. Hier 
den Code, den ich genommen habe. Bibliothek natürlich vorher geladen.

#include <Wire.h>
#include "SSD1306Ascii.h"
#include "SSD1306AsciiWire.h"
#define oled_adresse 0x3C
SSD1306AsciiWire oled;
void setup() {
  Wire.begin();
  Wire.setClock(400000L); //100000L
  oled.begin(&Adafruit128x64, oled_adresse);
  oled.setFont(TimesNewRoman16); // Auswahl der Schriftart
  oled.clear(); //Löschen der aktuellen Displayanzeige
  oled.println("Hello World");
}
void loop(){}

Auch die Taktrate nochmals mit versucht runter zu nehmen. Die Pixel sind 
an genau der gleichen Stelle. Auch wenn ich einen anderen Text eingebe.

[Manuel Z. (manuel_z)]

DerEgon schrieb:
> Stell das Oszi mal so ein, daß man mehrere Takte nacheinander
> sieht  Die
> Zeitbasis steht gerade auf 2 µs/div, mach da mal 50 µs/div oder 100
> µs/div draus.

OK ich habe mal auf 10us gestellt.

Stefan K. schrieb:
> Zum OWON HDS272S:
> Benutz den Tastkopf und nicht das Krokoklemmenkabel.
> Stell den Schiebeschalter am Tastkopf auf 10x, das Oszilloskop ist schon
> darauf eingestellt.

ich habe leider kein Tastknopf, Schieberegler etc. an den Klemmen. Ich 
hoffe es so verstanden zu haben. Daher habe ich die Klemmen genommen.

> Schließ die Masseklemme an einen GND-Anschluss in der Nähe des
> SCL-Anschlusses an.
> Pass Triggerlevel und Zeitbasis so an, dass mindesten eine steigende und
> eine fallende Flanke zu sehen sind.
> Und: nutz die Screenshot-Funktion des Oszilloskops.

Jo, ist in der Nähe des SCL-Anschlusses angeschlossen.
Jedoch springen die Flanken im Bild immer hin und her und wirken 
überlagert. Ich bin mir nicht sicher ob dies normal ist.

PS. ich hab den i2c Scanner genommen und darauf eingestellt, dass er 
alle 10ms scannt.

[Manuel Z. (manuel_z)]

Ich habe gleichzeitig mal den Hersteller angeschrieben. Hier seine 
Antworten:

"Also ein Pull-Up ist in der I²C Spec. vorgeschrieben damit man einen 
ordentlichen H-Pegel bekommt und zugleich ausreichend steile Flanken.

Ein besseres Oszi-Bild wäre gut.

Wie lange warten Sie denn nach dem Power-On bis Sie Daten an das Display 
schicken?"

Meine Vorgehensweise wäre jetzt erst mal es mit dem Oszi oder generell 
ein gutes Oszi-Bild zu bekommen. Ich weiß nur nicht, wie. Dann 
wahrscheinlich probehalber Pull-Up Widerstände einzulöten.

[DerEgon (Gast)]

Manuel Z. schrieb:
> OK ich habe mal auf 10us gestellt.

Ich schrieb 50 oder 100.

Das Signal sollte grob gesehen so aussehen:

-----|  /-|  /-|  /-|  /-|  /-|  /-|  /-|  /-|  /-------------------
     |-/  |-/  |-/  |-/  |-/  |-/  |-/  |-/  |-/

Eine ganze Zeit lang Ruhe, dann neun Impulse auf der Taktleitung, dann 
wieder Ruhe.

Eine steile fallende Flanke, gefolgt von einer langsamer ansteigenden 
steigenden Flanke. Und wenn die zu langsam ist, dann funktioniert der 
I2C-Bus nicht, und sie ist zu langsam, wenn die I2C-Pullups zu hochohmig 
sind.

[Manuel Z. (manuel_z)]

DerEgon schrieb:
> Ich schrieb 50 oder 100.

Ah ich glaub mit diesem Bild wird es deutlich.
50 µs/div sind eingestellt.

[Stefan F. (Gast)]

Manuel Z. schrieb:
> Unter mein Ubuntu ist es mit CuteCom oder dem SerialMonitor
> von Arduino IDE egal was ich einstelle.

Nicht nur bei Ubuntu.

Das ist so bei allen virtuellen COM Ports üblich, die nicht über echte 
UART Leitungen laufen. Wo keine UART Leitungen (RxD und TxD) sind, gibt 
es auch keine Baudrate.

Man beachte den Kommentar in 
https://github.com/earlephilhower/arduino-pico/blob/master/cores/rp2040/SerialUSB.cpp

void SerialUSB::begin(unsigned long baud) {
    (void) baud; //ignored

    if (_running) {
        return;
    }

    _running = true;
}

[Stefan F. (Gast)]

Manuel Z. schrieb:
> IMAGE1.BMP

Manuel Z. schrieb:
> IMAGE4.BMP

Das ist grande merde. Du brauchst viel stärkere Pull-Up Widerstände.

Manuel Z. schrieb:
> Zum verifizieren SDA und SCL ist im Ruhezustand auf High mit 3,299V.

Warum zeigt dein Oszilloskop dann 4,5V an? Welche Vertikale Auflösung 
hast du eingestellt?

[I2C (Gast)]

Bei 3.3 Volt Versorgung würde ich 1k3 Pullups nehmen.

[Alt G. (altgr)]

Das OLED zeigt immer ein abbild deiner verfassung.
Als wenn da nur wirres zeugs ist...

[Manuel Z. (manuel_z)]

Stefan ⛄ F. schrieb:
> Manuel Z. schrieb:
>> IMAGE4.BMP
>
> Das ist grande merde. Du brauchst viel stärkere Pull-Up Widerstände.

Jetzt habe ich es an diesem Bild auch gleich gesehen. Danke nochmals!

> Wolltest du nicht 3,3V Signale haben? Warum ist dein Ruhepegel dann 5V?

Ich messe 3,3V im Ruhepegel. Bei Oszi weis ich nicht ob ich es richtig 
eingestellt habe(oder was auch immer). Wenn ich den I2C (Ruhezustand) 
messe dann habe ich 3,3V.

[J. S. (jojos)]

Das Oszi ist offensichtlich auf 10x Tastkopf eingestellt, aber Manuel 
schreibt ja das er keinen hat. Dann ist die Einstellung 10x verwirrend, 
sollte auf 1x stehen. Dann noch einen Offset einstellen, also die Kurve 
hochschieben, die ist ja nach unten abgeschnitten.

[Schlaumaier (Gast)]

Manuel Z. schrieb:
> Die Pixel sind
> an genau der gleichen Stelle. Auch wenn ich einen anderen Text eingebe.

DIESE Aussage lässt klar NICHT auf eine Frequenzstörung irgend welcher 
Art schließen. Dann wären die Punkt unlogischer verteilt und würden 
"wandern"

Das ist irgendwas LOGISCHES im argen.

Und das der Wechsel von Libs + Co. die selben Punkte anzeigt, beweist 
das ganz klar.

Mir kommt langsam der Verdacht das das Teil ein Schuss weg hat.

[Manuel Z. (manuel_z)]

J. S. schrieb:
> Das Oszi ist offensichtlich auf 10x Tastkopf eingestellt, aber
> Manuel
> schreibt ja das er keinen hat. Dann ist die Einstellung 10x verwirrend,
> sollte auf 1x stehen. Dann noch einen Offset einstellen, also die Kurve
> hochschieben, die ist ja nach unten abgeschnitten.

Sorry, ich kann mit dem Tastkopf wenig anfangen. Ich konnte jetzt kein 
Screenshot machen aber auf dem Foto stand bei Sensor 10x eventuell ist 
dies damit gemeint? Ich habe es jetzt auf 1x gestell. Ja sie war unten 
abgeschnitten und hab sie jetzt hoch gezogen.

[Stefan F. (Gast)]

J. S. schrieb:
> Das Oszi ist offensichtlich auf 10x Tastkopf eingestellt

Glaube ich nicht. Die von beiden Oszilloskopen gezeigten Bilder passen 
nicht zu den üblichen Skalierungs-Stufen 1, 2 und 5.

Bei 1 V/div und einem 1:1 Tastkopf müsste der Ruhepegel 3,3 Kästchen 
hoch sein. Bei 500mV V/div wären es 6,6 Kästchen. Bei 200 mV/div wären 
es 16,5 Kästchen.

Bei 100 mV/div und einem 1:10 Tastkopf müsste der Ruhepegel 3,3 Kästchen 
hoch sein. Bei 50 mV/div wären es 6,6 Kästchen. Bei 20 mV/div wären es 
16,5 Kästchen.

[Manuel Z. (manuel_z)]

Schlaumaier schrieb:

> Mir kommt langsam der Verdacht das das Teil ein Schuss weg hat.

So kam es mir am Anfang auch vor. Ich bekomme die Adresse, Invertieren 
des Bildes geht und ein Lauftext (ohne Text nur wirre Pixel sind zu 
sehen). Aber immer die gleichen Pixel an der gleichen Stelle egal was 
ich mache. Wenn ich nichts schicke kommen keine Pixel. Das gleiche macht 
die andere zweite Platine aber auch.

[J. S. (jojos)]

Manuel Z. schrieb:
> Ich konnte jetzt kein
> Screenshot machen aber auf dem Foto stand bei Sensor 10x eventuell ist
> dies damit gemeint?

ja, so ist es jetzt richtig. Man nimmt Tastköpfe mit Teiler um das 
Signal geringer zu belasten. Damit wird in der Anzeige die Skalierung 
umgeschaltet, jetzt kannst du die Vertikalen Kisten zählen und kommst 
auch auf die 3,3 V.

Jetzt noch die Zeitbasis auf 25 µs oder kleiner stellen, dann kommt das 
Signal auch evtl. höher auf die 3,3 V. Wenn das Scope zu langsam 
abtastet sieht man hier evtl. gemittelte Anzeigen.

Das macht alles das wahrscheinliche Problem sichtbar: die Pull Up sind 
zu groß, irgendwas aus der Bastelkiste mit 1...2,7 kOhm anklemmen.

[Stefan F. (Gast)]

Manuel Z. schrieb:
> IMAGE1.BMP

6,5 Kästchen Höhe mal 500mV ergibt ungefähr 3,3V. Jetzt passt es.

> PXL_20220914_161459719.MP.jpg

Hier ist die untere Hälfte abgeschnitten, daran kann man nicht ablesen 
wie hoch der Ruhepegel ist.

Man sieht auf beiden Bildern wieder deutlich, dass die Signale während 
der Übertragung keine 3,3V erreichen. Also sind die Pull-Up Widerstände 
viel zu schwach.

Wenn du das korrigiert hast, ändere die Zeitbasis so, dass man ein 
einzelne Bit sieht. Bei 400 Kilobits will ich sehen, dass die steigenden 
Flanken weniger als 1µS in Anspruch nehmen.

[Manuel Z. (manuel_z)]

J. S. schrieb:
> Das macht alles das wahrscheinliche Problem sichtbar: die Pull Up sind
> zu groß, irgendwas aus der Bastelkiste mit 1...2,7 kOhm anklemmen.

Ich werde heute Abend versuchen, Pull-Ups anzulöten und dann berichten.

[Schlaumaier (Gast)]

Manuel Z. schrieb:
> Wenn ich nichts schicke kommen keine Pixel. Das gleiche macht
> die andere zweite Platine aber auch.

Vielleicht solltest du den "Sender" mal tauschen. Hast du noch irgendwo 
ein Nano o.ä. herum liegen wo die das Prg.-Chen das laufen lassen 
kannst.

[Stefan F. (Gast)]

Schlaumaier schrieb:
> Hast du noch irgendwo ein Nano o.ä. herum liegen

Damit hätte er auch keine 3,3V Pegel.

[Manuel Z. (manuel_z)]

Schlaumaier schrieb:
> Vielleicht solltest du den "Sender" mal tauschen. Hast du noch irgendwo
> ein Nano o.ä. herum liegen wo die das Prg.-Chen das laufen lassen
> kannst.
Das ist nicht so einfach, weil der RP2040 fest auf die Platine ist. Also 
nur rein der Chip. Einfacher wäre es, das Display auszulöten. Aber das 
wird Murks bei mir.

[Stefan F. (Gast)]

Manuel Z. schrieb:
> Das ist nicht so einfach, weil der RP2040 fest auf die Platine ist.

Ich würde es auch nicht machen, aber nur so als Tipp falls das mal nötig 
wird:

Du kannst den Raspi im Dauer-Reset Zustand halten (oder einfach das 
Programm löschen) und dann einen zweiten Mikrocontroller mit ein paar 
Drähten parallel dazu auf den Bus schalten. Es ist schließlich ein Bus.

[Peter D. (peda)]

Die Pullups sind viel zu hochohmig.
Der Takt muß fast symmetrisch sein und keine Nadeln.
Nimm mal je 1.8k für SCL und SDA.

[Manuel Z. (manuel_z)]

Stefan ⛄ F. schrieb:
> Wenn du das korrigiert hast, ändere die Zeitbasis so, dass man ein
> einzelne Bit sieht. Bei 400 Kilobits will ich sehen, dass die steigenden
> Flanken weniger als 1µS in Anspruch nehmen.

Image 1 bei Clock 100000
Image 2 bei Clock 400000
Image 3 bei Clock 400000 so dass nur ein Bit zu sehen ist

SCL und SDA haben jetzt 2k Pull-Up.

Ich habe jetzt auch nochmals versucht, einen Text drauf zu bringen. Es 
ist immer noch dasselbe Problem. Als hätte sich nichts geändert. Wirre 
Pixel sind zu sehen. Genau da wo sie vorher auch waren.

[J. S. (jojos)]

Sieht gut aus. Also doch eher Software. Werden Warnings beim kompilieren 
angezeigt? Doch ein falscher Displaytyp?

[Manuel Z. (manuel_z)]

J. S. schrieb:
> Sieht gut aus. Also doch eher Software. Werden Warnings beim
> kompilieren
> angezeigt? Doch ein falscher Displaytyp?

Hier die Ausgabe vom Compiler/Arduino.

Sketch uses 68156 bytes (0%) of program storage space. Maximum is 
16773120 bytes.
Global variables use 8312 bytes (3%) of dynamic memory, leaving 253832 
bytes for local variables. Maximum is 262144 bytes.
Resetting /dev/ttyACM0
Converting to uf2, output size: 167424, start address: 0x2000
Flashing /media/manu/RPI-RP2 (RPI-RP2)
Wrote 167424 bytes to /media/manu/RPI-RP2/NEW.UF2

Ich habe heute extra nochmals auf die Rückseite geschaut, um mir da auch 
100% sicher zu sein. Da steht EA OLEDM128-6LWA. Es passt ja auch von den 
Abmessungen und co. Also nach den Herstellerangaben sollte da dann ein 
SSD1306 drin sein. Oder ich übersehe irgendwas anderes.

Ich hatte schonmal den RTC getestet der mit auf dem i2c ist. Das 
funktioniert ohne Probleme.

[J. S. (jojos)]

Die Warnings muss man in den Einstellungen einschalten, default ist aus.
Sind die Grafik Libs für diesen RP2040 core getestet?

[Manuel Z. (manuel_z)]

J. S. schrieb:
> Die Warnings muss man in den Einstellungen einschalten, default
> ist aus.

ja es ist eingeschaltet.
Siehe Bild1

ich habe auch noch die Einstellung vom RP2040 mit.
Siehe Bild2

> Sind die Grafik Libs für diesen RP2040 core getestet?
ich denke mal nicht. Also keine Ahnung.

Aber ginge es denn nicht mit U8g2?

[Stefan K. (stk)]

Zu den Libs und deinem Programm und damit wohl deinem eigentlichen 
Problem kann ich nichts beitragen.

Zum elektrischen Teil aber eine Anmerkung: die 2k Pull-Up scheinen mir 
zu niedrig zu sein.
Im Datenblatt zum Display sind im I2C Schaltplan 10k Pull-Ups 
eingezeichnet und im Abschnitt DATA TRANSFER I²C wird auf den 
Ausgangswiderstand des Displays hingewiesen:
"Please make sure when defining the pull-up resistors that the internal 
resistance of the display is 600..1000 Ω. This affects the low level 
when reading data and ACK bit."
Höchster sicher als low erkannter Pegel beim RP2040 sind laut Datenblatt 
bei 3,3 V Versorgungsspannung 0,8 V.
Bei 1000 Ω Ausgangswiderstand des Displays kann es den Pegel nur auf 1,1 
V herunterziehen und selbst bei 600 Ω werden die 0,8 V  nur knapp 
erreicht.
Minimaler Pull-Up wären meiner Rechnung nach ca 3k3, ich würde aber eher 
etwas aus dem Bereich von 4k7 bis 10k nehmen.

Du hast jetzt ja schon etwas mit dem Oszilloskop gemacht, da kannnst du 
ja auch mal beide Eingänge nutzen und SCL und SDA gleichzeitig 
darstellen.

Wenn Pegel und Flanken in Ordnung sind kannst du mit einem (billigen) 
Logicanalyzer mit der Fehlersuche weitermachen.

[PittyJ (Gast)]

Ich verlasse mich nicht auf Libs. Ich programmiere meine I2C Slaves nur 
nach dem Datenblatt.
Meist haben alle Chips ein ID-Register. Das kann man auslesen um 
überhaupt erst einmal eine Kommunikation zu etablieren.

Wenn das Lesen dieses ID-Registers fehlschlägt, dann ist meist das 
Problem in der Hardware.

Wenn es klappt, dann ist alles weitere ein Software Problem.

Also Basisroutinen für I2C Read/Write implementieren. Datenblatt des 
Controllers besorgen. Und dann exakt nur eine Kommunikation mit einer 
definierten Antwort (z.B. ID-Register) ausführen.
Danach ergeben sich die weiteren Schritte.

[Manuel Z. (manuel_z)]

Stefan K. schrieb:
> Zu den Libs und deinem Programm und damit wohl deinem eigentlichen
> Problem kann ich nichts beitragen.

PittyJ schrieb:
> Ich verlasse mich nicht auf Libs. Ich programmiere meine I2C
> Slaves nur
> nach dem Datenblatt.
> Meist haben alle Chips ein ID-Register. Das kann man auslesen um
> überhaupt erst einmal eine Kommunikation zu etablieren.

Ich habe mit dem Hersteller geschrieben. Vorläufige Aussage ist, dass da 
ein SSD1309 bestückt sein soll.

Ich habe auch ein Codebeispiel für Arduino bekommen. Aktuell geht dieser 
aber nicht. Compiler wirft auch nichts brauchbares aus. RPI hat mit dem 
Code auch keine Reaktion.

Ich schaue mal und berichte am Nachmittag.

[Manuel Z. (manuel_z)]

Ich bin noch nicht weiter gekommen.

Im Anhang habe ich das Beispiel vom Hersteller, eventuell hilft es 
jemandem. Auch sollte ich nochmals SCL und SDA am Oszi haben. Ich kann 
mit dem Bild weniger etwas anfangen. Wenn ich das Code-Beispiel vom 
Hersteller in den RP2040 lade, reagiert er danach absolut nicht mehr. 
Der Compiler wirft keine Fehlermeldung, nur eine Warnung, dass eine 
Variable unbenutzt wird. Zu dieser habe ich keine Verwendung gefunden 
und bei mir auskommentiert.

[Stefan F. (Gast)]

Manuel Z. schrieb:
> Ich kann mit dem Bild weniger etwas anfangen.

Ist doch ganz einfach. Blau sind die Taktimpulse. Bei den ersten 7 
Takten (positive Impulse) wird die Slave Adresse übertragen, danach ein 
Read/Write Flag. Beim 9. Takt müsste das Display mit einem LOW Pegel 
(auf Gelb) antworten, wenn es die Adresse erkannt hat. Hat es aber 
offenbar nicht.

Also ist wohl die I²C Slave Adresse falsch. Oder das Display ist defekt.

Ich tippe mal auf die Adresse, den 0000001 ist Hexadezimal 0x01, und die 
ist laut https://i2cdevices.org/addresses reserviert, kann also nicht 
stimmen.

Benutze mal einen I²C Scanner (den gibt es z.B. in der Arduino IDE als 
Beispielprogramm).

Da die Pegel jetzt gut sind, wirst du mit einem Logic Analyzer (ab 10 
Euro) nun besser voran kommen. Der würde dir die Bits gut lesbar 
dekodieren.

[J. S. (jojos)]

I2C Scanner hatte er doch schon laufen.

@Manuel: hast du noch ein Display? Das mal an einem RPi Pico betreiben 
um zu sehen das die SW funktioniert? Damit es nur eine Baustelle wird.

[Manuel Z. (manuel_z)]

Stefan ⛄ F. schrieb:
> Also ist wohl die I²C Slave Adresse falsch. Oder das Display ist defekt.

Stimmt, oh sorry. Ich hab einfach den Scanner laufen lassen und eine 
andere Adresse vorgegeben.
Es ist nicht so einfach da ein geeignetes Bild hinzubekommen. Am besten 
ist es wenn alle 10ms es etwas gesendet wird. Wenn es drunter ist dann 
sieht es dann aus wie auf dem Image1.

Im Image3. habe ich nur immer wieder die Adresse vom Display angefragt 
und bekommen. 60 bzw. 0x3C.

[J. S. (jojos)]

ist der OLED_RESET 3 auch wirklich Gpio03?

[Manuel Z. (manuel_z)]

J. S. schrieb:
> I2C Scanner hatte er doch schon laufen.
>
> @Manuel: hast du noch ein Display? Das mal an einem RPi Pico betreiben
> um zu sehen das die SW funktioniert? Damit es nur eine Baustelle wird.

Ich habe ein weiteres, was in einer baugleichen Platine verlötet ist. 
Eventuell hab noch ein Nano und ein richtigen RP2040. Eventuell da mit 
den I2C direkt drauf gehen?

[Stefan F. (Gast)]

Manuel Z. schrieb:
> Es ist nicht so einfach da ein geeignetes Bild hinzubekommen.

Lies mal die Bedienungsanleitung von deinem Oszilloskop, such e dort 
nach den Stichworten "single shot" und "trigger on rising edge" (Trigger 
auf steigende Flanke).

Manuel Z. schrieb:
> Im Image3. habe ich nur immer wieder die Adresse vom Display angefragt
> und bekommen. 60 bzw. 0x3C.

Ja die ersten 7 Bits sind 0111100, das ist 0x3C. Das 9. Bit ist LOW, 
also ein Acknowledge. So weit so gut. Die physikalische Kommunikation 
steht. Der Rest ist Software.

[Manuel Z. (manuel_z)]

J. S. schrieb:
> ist der OLED_RESET 3 auch wirklich Gpio03?

Jup, habe ich schon durchgeklingelt, sollte passen. Die Pins sind aber 
auch echt klein am RP2040. Mit dem Hersteller auch schon 3,3V fest auf 
dem RES Pin am Display drauf gelegt. Selbses Ergebnis.

[Manuel Z. (manuel_z)]

Stefan ⛄ F. schrieb:

> Lies mal die Bedienungsanleitung von deinem Oszilloskop, such e dort
> nach den Stichworten "single shot" und "trigger on rising edge" (Trigger
> auf steigende Flanke).

Danke. Langsam werde ich sicherer mit dem Oszi.
Ich habe auch gleich mal den Trigger (Per Hand) genutzt.
Image1.

[Manuel Z. (manuel_z)]

Hello World!

Es geht! Danke nochmals an Alle!

[J. S. (jojos)]

ja und was wars?
Ich habe das mit einem Pico + SSD1306 aufgebaut, läuft auch.

[Joachim B. (jar)]

Manuel Z. schrieb:
> Es geht! Danke nochmals an Alle!

Was sind das immer nur für Antworten?
Warum muss man nachfragen?

J. S. schrieb:
> ja und was wars?

[Manuel Z. (manuel_z)]

J. S. schrieb:
> ja und was wars?

Eine kalte Lötstelle am Display RST. Das Zinn sah gut aus, auch der 
Kontakt mit dem Zinn. Aber wahrscheinlich nicht zum Pin. Lötkolben 
angesetzt und dann ging es. So recht mag ich es noch nicht glauben, weil 
es an beiden Displays war.

Mir wurde noch die Aussage gegeben, dass es ein SSD1309 sein soll, 
obwohl in der Beschreibung SSD1306 steht. Da warte ich noch auf Antwort. 
Versucht habe ich es mit einer Bibliothek vom SSD1306. Mit einer SSD1309 
Bibliothek ging es nicht.

[Steve van de Grens (roehrmond)]

Manuel Z. schrieb:
> So recht mag ich es noch nicht glauben, weil
> es an beiden Displays war.

Aber vorher hattest du zusätzlich noch zu schwache Pull-Up Widerstände, 
falls ich das richtig mit bekommen habe.

[Manuel Z. (manuel_z)]

Steve schrieb:

> Aber vorher hattest du zusätzlich noch zu schwache Pull-Up Widerstände,
> falls ich das richtig mit bekommen habe.

Ja, es waren auf der Platine sogar gar keine Pull-Up Widerstände.

[J. S. (jojos)]

Manuel Z. schrieb:
> Eine kalte Lötstelle am Display RST.

Danke für die Rückmeldung.
Hast du alle nachelötet? Wenn das maschinell gelötet wurde, dann war das 
Temperaturprofil für das Display eventuell nicht geeignet.

Ich habe es auch mal ohne PullUp probiert, geht trotzdem. Das ist 
natürlich nicht zu empfehlen und nicht störsicher, war aber sicher nicht 
die ursprüngliche Ursache.

Noch ein Hinweis:
das Wire.setClock() hat keine Wirkung. Die Adafruit Lib stellt den Clock 
selber ein und hat Einstellungen für Display und andere, siehe 
Konstruktor. Als Voreinstellung wird das Display mit 400 kHz betrieben. 
Allerdings sah der Clock im Oszi eher nach 50 kHz aus, also hattest du 
das schon geändert?

[Manuel Z. (manuel_z)]

Manuel Z. schrieb:
>
> Mir wurde noch die Aussage gegeben, dass es ein SSD1309 sein soll,
> obwohl in der Beschreibung SSD1306 steht. Da warte ich noch auf Antwort.
> Versucht habe ich es mit einer Bibliothek vom SSD1306. Mit einer SSD1309
> Bibliothek ging es nicht.

Ich habe nochmals eine genaue Aussage bekommen, welche Kontroller nun 
verbaut sind.

"EA OLEDM128-6: SSD1306
 EA OLEDL128-6: SSD1309
In unserem Beispiel verwenden wir nur die Register, die in beiden 
Kontrollern identisch sind."

In den Arduino Beispielen von dem EA OLEDM128-6 und EA OLEDL128-6 ist 
geschrieben, dass es für den Kontroller SSD1309 ist. Dies hatte mich 
verwirrt.

[J. S. (jojos)]

Die Adafruit lib ruft in begin() aus selber das Wire.begin() auf, das 
ist auch nötig bevor man auf den I2C Bus zugreift.

[J. S. (jojos)]

Cyblord -. schrieb im Beitrag #7193544:
> Langsam muss man sich fragen

warum du hier überhaupt noch posten darfst bei den vielen persönlichen 
Beleidigungen jeden Tag.

[Martin H. (horo)]

Manuel Z. schrieb:
> Ich habe auch gleich mal den Trigger (Per Hand) genutzt.

Das ist kein Trigger, wenn du das Bild anhältst - Trigger bedeutet, dass 
ein neuer Trace ausgelöst wird, wenn eine bestimmte Bedingung erfüllt 
wird, also z.B. Kanal "Blau" durchläuft einen bestimmten Wert in 
definierter Richtung (vorher war das Signal größer, jetzt ist es 
kleiner).
Wenn Du den blassblauen Pfeil auf der rechten Seite nach oben schiebst 
(das ist vermutlich der Trigger-Pegel), dann sollte es auch automatisch 
triggern. Und mit Single bleibt das Bild stehen. Siehe S. 16-17: (blank 
zw. '.cn' und '/probook' entfernen)
files.owon.com.cn /probook/HDS200_series_user_manual.pdf

Ich empfehle Dir, ein Scope-Tutorial durchzulesen oder anzuschauen, das 
erleichtert die weitere Benutzung erheblich, ebenso solltest Du dich mal 
(am Besten an Deinem jetzt funktionierenden Aufbau) mit der Bedienung 
eines LA beschäftigen. Das ist besser als alles auf einmal - 
Fehlersuche, SW? und neues Messgerät kennenlernen.

[Manuel Z. (manuel_z)]

J. S. schrieb:
> Manuel Z. schrieb:
>> Eine kalte Lötstelle am Display RST.
>
> Danke für die Rückmeldung.
> Hast du alle nachelötet? Wenn das maschinell gelötet wurde, dann war das
> Temperaturprofil für das Display eventuell nicht geeignet.

Ich habe die Platine bei "https://www.nextpcb.com/"; machen lassen. 
Dieses Display wurde meiner Erinnerung nach dann aber per Hand von 
jemanden eingelötet. Die RST am Display hatte ich nochmals nachgelötet. 
Das Lot, auf der Platine, sah gut verlötet aus. Gestern hatte ich 
nochmals die Kontakte mit dem Multimeter kontrolliert. aber nicht am 
Lötzinn gemessen, sondern am Pin nahe des Displays, um kalte Lötstellen 
auszuschließen. Nur dieser war leicht abgebogen, um anscheinend beim 
Einlöten dem Display etwas Halt zu geben. Keine Ahnung weshalb genau. 
Wenn man den Pin berührte, waren es 3,3V. Beim schwachen Auflegen mit 
dem Multimeter schwankte es ganz kurz. Aber ja, ich habe gleich mehrere 
Pins an beiden Displays nachgelötet. Kann eventuell sein, dass da noch 
eine kalte Lötstelle war.

> Noch ein Hinweis:
> das Wire.setClock() hat keine Wirkung. Die Adafruit Lib stellt den Clock
> selber ein und hat Einstellungen für Display und andere, siehe
> Konstruktor. Als Voreinstellung wird das Display mit 400 kHz betrieben.
> Allerdings sah der Clock im Oszi eher nach 50 kHz aus, also hattest du
> das schon geändert?

Stimmt, dies hatte ich auch so gesehen. Ich hatte diese lib auch teils 
schon umgeschrieben oder Inhalt gekürzt und die Wire.setClock() in der 
lib geändert. Aber nur zwischen 400kHz und 100kHz. 50kHz hatte ich nie 
verwendet. Ich bin mir gerade nicht sicher bei welchen Oszi Bildern 
welche Clock eingestellt war. Meist 400khz. Dies hätte ich dazuschreiben 
sollen.

[J. S. (jojos)]

ich kenne das Owon nicht, wenn es noch einen zusätzlichen Triggereingang 
hat, dann kann man im Programm noch einen gpio vor der Display Ausgabe 
setzen und den als Trigger für einen Single Shot benutzen. Dann hat man 
einen definierten Zeitpunkt. Die Flanken im Daten/Takt kommen ja in 
unregelmässigen Abständen.

[W.S. (Gast)]

J. S. schrieb:
> Cyblord -. schrieb:
>> Langsam muss man sich fragen
>
> warum du hier überhaupt noch posten darfst bei den vielen persönlichen
> Beleidigungen jeden Tag.

Du bist ein bissel sehr empfindsam, mein Lieber. Wenn hier jemand die 
Wahrheit sagt und selbige nicht genehm ist, dann faßt du das als 
Beleidigung auf. Ist aber keine.

Hier fragt einer nach, weil er zwar basteln will, aber nicht gelernt 
hat, logisch und systematisch vorzugehen. Und er konnte sich zwar ein 
Oszilloskop kaufen, weiß aber nicht damit umzugehen und hatte bislang 
auch noch wenig inneren Antrieb, herauszufinden wie es funktioniert. 
Nun, auch das Wissen um die eigentlich leicht verständlichen Details des 
Signalspiels auf dem I2C war ihm bislang nicht wirklich wichtig. Er 
wollte/will nur ein Display anschließen und eine dazu passende Lib 
verwenden.

Mir kommt da ein oller Männer-Witz über autofahrende Frauen in den Sinn: 
"Herr Tankwart, ich hätte gern einen Tank voll von dem Zeug, was man 
braucht, damit das Auto fährt." Bitte jetzt keine Diskussion über die 
Spritpreise.

W.S.

[J. S. (jojos)]

@W.S.:
Was du wieder alles weißt ohne die Leute zu kennen. Der TO hat 
dazugelernt wie man sieht und sich auch mit den Interna der Lib 
beschäftigt. Alles andere sind wieder deine üblichen Unterstellungen.

[Steve van de Grens (roehrmond)]

W.S. schrieb:
> Du bist ein bissel sehr empfindsam, mein Lieber. Wenn hier jemand die
> Wahrheit sagt und selbige nicht genehm ist, dann faßt du das als
> Beleidigung auf. Ist aber keine.

Beleidigungen bleiben Beleidigungen auch wenn sie wahr sind.

Es gibt auch Leute, die ihren Ferrari nicht gut einparken können. Um 
eine Tätigkeit zu meistern muss man sie üben. Das kann man sich nicht 
erkaufen.

[J. S. (jojos)]

Und es wird einem nicht in die Wiege gelegt. Außer vielleicht bei 
Göttern wie Cyblord und W.S.

[W.S. (Gast)]

Steve schrieb:
> Beleidigungen bleiben Beleidigungen auch wenn sie wahr sind.

Da hast du eine doch recht eigentümliche Logik.

Wenn jemand sowas schreibt:
"Außer vielleicht bei Göttern wie Cyblord und W.S."
was ist das dann für dich?
Sowas zeugt von einer inneren Giftigkeit und ist eine ziemliche 
Unfreundlichkeit.

W.S.

[J. S. (jojos)]

Unfreundlich sind deine Unterstellungen.

[Cyblord -. (cyblord)]

Steve schrieb:
> Beleidigungen bleiben Beleidigungen auch wenn sie wahr sind.

Vielleicht. Aber was wahr ist, darf man immer sagen.

Früher sagte man ja mal: "Trinken was klar ist, sagen was wahr ist und 
vögeln was da ist".

Was sagt man heute? "Bloß nichts falsches sagen, ein non-binäres 
metrosexuelles Schneeflöckchen mit Dutt und Männerhandtasche auf einem 
E-Roller könnte sich beleidigt fühlen?".
Ist das dein Leitspruch fürs Leben? ja?

Trotzdem musst du mir die angebliche Beleidigung erst mal noch zeigen. 
Finde keine in meinem Post.

[Axel R. (axlr)]

https://www.mikrocontroller.net/attachment/570254/PXL_20220914_091612234.jpg

Manuel Z. schrieb:
> Eine kalte Lötstelle am Display RST. Das Zinn sah gut aus, auch der
> Kontakt mit dem Zinn. Aber wahrscheinlich nicht zum Pin.

Das konnte man schon auf dem ersten Foto sehen

[Axel R. (axlr)]

W.S. schrieb:
> J. S. schrieb:
>> Cyblord -. schrieb:
>>> Langsam muss man sich fragen
>>
>> warum du hier überhaupt noch posten darfst bei den vielen persönlichen
>> Beleidigungen jeden Tag.
>
> Du bist ein bissel sehr empfindsam, mein Lieber. Wenn hier jemand die
> Wahrheit sagt und selbige nicht genehm ist, dann faßt du das als
> Beleidigung auf. Ist aber keine.
>
> Hier fragt einer nach, weil er zwar basteln will, aber nicht gelernt
> hat, logisch und systematisch vorzugehen. Und er konnte sich zwar ein
> Oszilloskop kaufen, weiß aber nicht damit umzugehen und hatte bislang
> auch noch wenig inneren Antrieb, herauszufinden wie es funktioniert.
> Nun, auch das Wissen um die eigentlich leicht verständlichen Details des
> Signalspiels auf dem I2C war ihm bislang nicht wirklich wichtig. Er
> wollte/will nur ein Display anschließen und eine dazu passende Lib
> verwenden.
>
> Mir kommt da ein oller Männer-Witz über autofahrende Frauen in den Sinn:
> "Herr Tankwart, ich hätte gern einen Tank voll von dem Zeug, was man
> braucht, damit das Auto fährt." Bitte jetzt keine Diskussion über die
> Spritpreise.
>
> W.S.

Hier mische ich mal ein.
Ich finde es die total falsche Herangehensweise, ein Projekt ans laufen 
zu bekommen. Man kann doch nicht ne Platine machen lassen, auf eine 
passende Library hoffen, aufdass am Ende alles so funktioniert, wie 
Eingangs angedacht?!?
man muss sich doch im Vorfeld mit den Spezifikationen der einzelnen 
Komponenten beschäftigen. Dazu zählt hier vielleicht auch dazu, 
ansatzweise zu wissen, was ein I2C Bus ist und wie der in etwa 
funktioniert.
Man kauft sich doch kein Messgerät, wenn man es garnicht braucht oder es 
nicht weiß, zu verwenden?
Zu guter Letzt muss man sich noch, dem jeweiligen Blutzuckergehalt 
gemäß, überlegen, wie man in welchem Tonfall Kritik äußert, damit die 
jungen Leuten aus der Makerszene sich nicht auf den Schlips getreten 
fühlen?
Die Posts häufen sich in letzter Zeit zusehends, in deren Verläufen es 
mir schon sauer aufstößt.
Aber zuweilen scrolle ich dann einfach weiter. Das "schlimme" daran; 
viele, die eigentlich wissen, was zu tun wäre, also die Das Fehlerbild 
kennen, machen das auch und so bleiben viele wertvolle Tipps ungenannt.

Auch mir geht es so: " Langsam muss man sich fragen "

[Axel R. (axlr)]

Cyblord -. schrieb:
> Was sagt man heute? "Bloß nichts falsches sagen, ein non-binäres
> metrosexuelles Schneeflöckchen mit Dutt und Männerhandtasche auf einem
> E-Roller könnte sich beleidigt fühlen?".
> Ist das dein Leitspruch fürs Leben? ja?

+1

[Manuel Z. (manuel_z)]

Martin H. schrieb:
> Ich empfehle Dir, ein Scope-Tutorial durchzulesen oder anzuschauen, das
> erleichtert die weitere Benutzung erheblich, ebenso solltest Du dich mal
> (am Besten an Deinem jetzt funktionierenden Aufbau) mit der Bedienung
> eines LA beschäftigen. Das ist besser als alles auf einmal -
> Fehlersuche, SW? und neues Messgerät kennenlernen.

Danke, vorher hatte ich nie ein Oszi gehabt und ungewendet. Ich hab es 
auf meiner ToDo-Liste

[Manuel Z. (manuel_z)]

> Ich finde es die total falsche Herangehensweise, ein Projekt ans laufen
> zu bekommen. Man kann doch nicht ne Platine machen lassen, auf eine
> passende Library hoffen, aufdass am Ende alles so funktioniert, wie
> Eingangs angedacht?!?
> man muss sich doch im Vorfeld mit den Spezifikationen der einzelnen
> Komponenten beschäftigen. Dazu zählt hier vielleicht auch dazu,
> ansatzweise zu wissen, was ein I2C Bus ist und wie der in etwa
> funktioniert.

Also ich mache dies nur nebenbei als Hobby. Ja, ich habe mich mit dem 
I2C Bus beschaeftigt und die Application Note AN10216-01 aus dem Jahr 
2003 weitestgehend gelesen, auch zu dem LTC4311, LTC1694, SSD1306, 
RP2040 und weitere Grundlagen, die meiner Ansicht nach wichtig sind und 
gerade deswegen auch nur auf diesen Bus gesetzt und nicht auf den SPI. 
Auch weil ich mit diesen Komponenten erfolgreich programmiert habe. 
Wahrscheinlich auch nicht Perfekt. Dies Ganze ist mir auch noch recht 
heavy. Dies gebe ich zu. Es ist mir auch bewusst gewesen, dass die 
Platine mit Fehler ankommt, weil ich sicherlich welche gemacht habe und 
es mit eine meiner Ersten ist. Aber daraus wollte ich lernen. Auch, dass 
ich vorher SSD1306 Displays genommen habe, die problemlos angeschlossen 
werden mussten und alles Wichtige drauf war. Lerning by doing. Die 
Pull-Up Wiederstaende habe ich schlichtweg vergessen. Auch mit dem 
Wissen, dass im RP2040 zu schwache sein sollen und selbst in der 
HW-Design darauf hingewiesen wird (Ich finde, diese Stelle gerade nicht, 
oder warum ich dies weis).

> Man kauft sich doch kein Messgerät, wenn man es garnicht braucht oder es
> nicht weiß, zu verwenden?

Dem gebe ich recht. Vielleicht habe ich bei dem ersten Post nicht 
richtig darauf aufmerksam gemacht, welchen Wissensstand ich habe. Aber 
darauf gefragt, was ich falsch gemacht habe.

> Die Posts häufen sich in letzter Zeit zusehends, in deren Verläufen es
> mir schon sauer aufstößt.

Als nicht aktiver neuer User(Leihe) in diesem Forum dachte ich 
konstruktive Hilfe zu bekommen. Zu dem Technischen-Problem sowie noch 
benötigten Wissensstand, was gebraucht wird. Für die Tipps des noch 
benötigten Wissensstandes bin ich dankbar. Für mich ist es auch ok zu 
schreiben, dass ich erst dies oder jenes mir aneignen sollte, dass man 
mir helfen kann.

Was ich aber auch beobachtet habe, ist, dass in diesem Forum schnell mal 
jemand abgewertet wird. Dies finde ich kontraproduktiv und nicht 
hilfreich für alle.

[Cyblord -. (cyblord)]

Manuel Z. schrieb:
> Als nicht aktiver neuer User(Leihe)

Rechtschreibung scheint jetzt aber auch nicht gerade dein Steckenpferd 
zu sein...

[Schlaumaier (Gast)]

Manuel Z. schrieb:
> So recht mag ich es noch nicht glauben, weil
> es an beiden Displays war.

Serienproduktionsfehler.  Die beiden sind wohl Zwillinge ;)

Ist ein bekannten Phänomen. Ich kenne mehre Geräte wo im Netz steht, das 
man nur an die+die Stelle mal den Lötkolben halten muss und alles ist 
fein.

Das gemeine ist halt, das es ein Industrieller Fehler ist, und man so 
Fehler mit den bloßen Auge fast nie sieht. So mies ist selber die QS in 
China nicht, das sie den sonst durchgehen lassen. ;))

Ich habe z.b. ein 5 China-Ardunio-IR-Sende-Module wo die Beschriftung 
von +5V und INI vertauscht ist.  G.s.D. sind die Module genügsam sonst 
wären sie alle Schrott. ;)

[Stefan (Gast)]

Manuel Z. schrieb:
> Die
> Pull-Up Wiederstaende habe ich schlichtweg vergessen. Auch mit dem
> Wissen, dass im RP2040 zu schwache sein sollen und selbst in der
> HW-Design darauf hingewiesen wird (Ich finde, diese Stelle gerade nicht,
> oder warum ich dies weis).

Steht im RP2040 Datasheet im Abschnitt 4.3.1.3. IOs.
"NOTE
There should also be external pull-ups on the board as the internal pad 
pull-ups may not be strong enough to pull up
external circuits."