Hi Leute, egal welche Library ich für mein 128x64 Oled Display (SSD1306) verwende, wenn ich den Screen Inhalt aktualisiere (sei es mit clear() oder per Leerzeichen) flackern kurz sämtliche LEDs meines Button Pads. Ich dachte zuerst irgendeine Strom-Unterversorgung. Aber dann habe ich meine OLED Funktionen im Code kommentiert, und siehe da, dann läuft's. Es sieht sogar so aus, als würde sich dieses "Flackern" blockend – ähnlich einem Delay – verhalten. Kennt jemand dieses Problem? Danke für jeden Tipp!
Schaltplan. Wenn die LEDs nicht gemultiplext sind, sollte man sich die GPIO Port/Pin Zugriffe genau anschauen, Stichwort Read-Modify-write und Interrupt.
I2C oder SPI und wie schnell? Der komplette Inhalt sind 1024 Byte, so roh, ohne Adressierung, das dauert seine Zeit, vielleicht braucht das einfach so lange?
Rudolph schrieb: > I2C oder SPI und wie schnell? I2C, und ich habe den Teensy 3.6. Ich weiß leider nicht wie ich die I2C Geschwindigkeit herausfinden kann? Jim M. schrieb: > Wenn die LEDs nicht gemultiplext sind, sollte man sich die GPIO Port/Pin > Zugriffe genau anschauen, Stichwort Read-Modify-write und Interrupt. Die LEDs sind ge-Shiftregistert. Macht das einen Unterschied? Ich zeichne gerne einen Schaltplan, ich habe derzeit keinen aktuellen, aber das schaffe ich erst heute Abend …
Ich hatte I2C auf 100Mhz, und es war schlichtweg zu langsam für die Buffergröße – so meine Annahme. Ich habe jetzt auf SPI gewechselt, und sogar mit der "dicken" Library funktioniert alles wie am Schnürchen. Offensichtlich bietet sich I2C nicht so gut für Displays mit hoher Refreshrate an? Danke euch! Gruß.
I2C eher auf 100kHz. :-) Und da dauert das dann mal eben 100ms um den Refresh zu machen. Da 10 Bilder pro Sekunde auf dem Display völlig ausreichend wären ist das Problem eher, wie die Daten in das Display geschaufelt werden. Den Controller blockierend am Stück ist da nicht die beste Strategie. :-)
OK, selbst bei SPI bekomme ich bei aufwändigeren Display Änderungen Probleme. Meine LEDs beginnen zu flackern und ich flackere mit :/ Habe probiert mit einer displayRefresh() Funktion welche sich nur alle 15 Millisekunden ausführen darf – wenn sie getriggert wird – eine Verbesserung zu erreichen, aber ne. Rudolph schrieb: > ist das Problem eher, wie die Daten in das Display geschaufelt werden. > Den Controller blockierend am Stück ist da nicht die beste Strategie. • Hast du eine bessere Strategie bzw einen Ansatzpunkt für mich? • Ist es Performance-technisch ein großer unterschied zwischen Hardware und Software SPI? Gruß!
Hardware-SPI liefert dir einen Interrupt wenn ein Byte rüber ist, damit kansnt du in der zwischenzeit anderes erledigen. Bei richtiger Programmierung sind das Welten.
Elias *. schrieb: > • Hast du eine bessere Strategie bzw einen Ansatzpunkt für mich? Ein volles Update könnte man in kleine Häppchen aufteilen, so 64*16 Pixel und dazwischen was anderes. Oder eben nicht blockierend per DMA. Alternativ nur die Änderungen übertragen, etwa in dem man einen statischen Bereich und einen dynamisch bedienten Bereich im Display definiert und den statischen Kram nur einmal überträgt. > • Ist es Performance-technisch ein großer unterschied zwischen Hardware > und Software SPI? Kommt darauf an, wenn man sowieso nur in einer Schleife einzelne Bytes verschickt, hat man zwischen diesen je nach Takt des SPI und des Controllers ohnehin nicht viele Taktzyklen in denen man was anderes machen könnte. Eine 80MHz CPU hat zwischen zwei Transfers mit einem 10MHz SPI gerade eben mal 64 Taktzyklen. Das ist schon was, aber eben nicht gerade viel. Max D. schrieb: > Hardware-SPI liefert dir einen Interrupt wenn ein Byte rüber ist, damit > kansnt du in der zwischenzeit anderes erledigen. Bei richtiger > Programmierung sind das Welten. Auch eine Frage der Takte, bei einem 16 MHz AVR mit 8 MHz SPI würde der ja aus den Interrupts quasi nicht mehr raus kommen. Der Teensy hat doch nen ARM drauf, oder? Der hat doch bestimmt DMA -> Puffer füllen, Übertragung anschieben und der Interrupt kommt wenn der Puffer übertragen wurde.
Rudolph R. schrieb: > Alternativ nur die Änderungen übertragen, etwa in dem man einen > statischen Bereich und einen dynamisch bedienten Bereich im Display > definiert und den statischen Kram nur einmal überträgt. Habe ich probiert, läuft nur semi gut. Rudolph R. schrieb: > Oder eben nicht blockierend per DMA. Ich habe mich eben ein wenig über DMA schlau gemacht, und das klingt ja genau nach dem was ich suche. Zu meinem Teensy 3.6: 180 MHz ARM Cortex-M4 with Floating Point Unit 1M Flash, 256K RAM, 4K EEPROM Nun verwende ich aktuell die Adafruit 1306 Library für das OLED, und ich habe gesehen es gibt auch eine "DmaSpi" Library für den Teensy 3.6. Muss ich jetzt in der Adafruit Library etwas ändern um DMA zu verwenden oder kann ich das einfach in meinem Sketch deklarieren? Und noch eine Verständniss Frage am Ende: Wer verwendet denn OLED Displays zB mit Arduino und I2C wenn es so "lahm" ist? Ich meine einen Sensorwert auf einem Display auszugeben und ständig aktuell zu halten ist ja keine all zu spezifische Anwendung, und wenn das Arduino dann die ganze Zeit ins stocken kommt ... Wie machen die das :)? Danke ihr helft mir sehr! Gruß.
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.