Hallo alle zusammen ich habe folgendes Problem seit einigen Tagen & bin jetzt schlussendlich zu den Entschluss gekommen, mir mal Rat hier im Forum zu holen: Ich gebe über ein Drehgeber_Interrupt einfache Positionswerte ein, die mir über mein OLED wieder ausgegeben werden sollen. Oben im rechteckigen Kästchen als INT Unten im runden Kästchen als STRING in beiden fällen habe ich das Problem, das wenn ich eine zu schnelle Drehung mit dem Drehgeber mache, das Display hakt, und solche Ausgaben wie auf dem Bildern entsteht. Drehe ich nun weiter verschwindet das auch sofort wieder, nur indem Moment ist es bisschen ärgerlich weil ich zwischenzeitlich auf dem Display abgehackt "Zeichen" sehen muss. Folgendes habe ich schon probiert: -Drehgeber wird über ein Interrupt ausgewertet -Delay sowohl in der Loop als auch (Todsünde ich weiß) in der ISR Bin dankbar für jede Hilfe !
Angehängte Dateien:
-
png1.png
10 MB
> Arduino OLED Display hackt bei zu schneller Werteingabe
Holz oder Heizöl?
Damian M. schrieb: > Bin dankbar für jede Hilfe ! Lies die Hinweise im Kasten oberhalb der bei jedem Posten zu sehen ist. Insbesondere: -------------------------------------------------------- Bitte das JPG-Format nur für Fotos und Scans verwenden! Zeichnungen und Screenshots im PNG- oder GIF-Format hochladen. Siehe Bildformate. -------------------------------------------------------- Wenn du das nicht verstehst dann lass das Posten sein.
OMG schrieb: > Damian M. schrieb: >> Bin dankbar für jede Hilfe ! > > Lies die Hinweise im Kasten oberhalb der bei jedem Posten zu sehen ist. > > Insbesondere: > -------------------------------------------------------- > Bitte das JPG-Format nur für Fotos und Scans verwenden! > Zeichnungen und Screenshots im PNG- oder > GIF-Format hochladen. Siehe Bildformate. > -------------------------------------------------------- > > Wenn du das nicht verstehst dann lass das Posten sein. ok ok sorry. ganz ruhig. Wollte dich damit nicht demütigen
Der Drehgeber Interrupt unterbricht nunmal das zeilenweise Schreiben aufs Display, das wird sich nicht ändern lassen. Während eines zusätzlichen delays, egal wo, wird das Display auch nicht fertig gefüllt. Dazu bräuchtest du zwischen einen Framebuffer, der dann auf Kommando auf einen Rutsch ohne weiteres Zutun des Microcontrollers angezeigt wird.
Damian M. schrieb: > Ausgaben wie auf dem Bildern entsteht Welche Bilder, ich kann sie nicht sehen. Kannst du die nicht in einem "normalen" Format anhängen?
Damian M. schrieb: > Wollte dich damit nicht demütigen Nein, du willst nur zeigen dass du dich an minimale Regeln im Forum nicht kümmern willst. Es scheint so als ob die Leute die dir helfen sollen sich deine "Codierungen" gefälligst selbst zurechtschneidern. Du bist hier lang genug angemeldet um zu wissen wie und was man postet.
Hier sind noch mal die Fotos in einem richtigen Format Hier sind noch mal die Fotos in einem richtigen Format
Damian M. schrieb: > Hier sind noch mal die Fotos in einem richtigen Format → 10MB PNG. Ist das Absicht?
OMG schrieb: > Damian M. schrieb: >> Wollte dich damit nicht demütigen > > Nein, du willst nur zeigen dass du dich an minimale Regeln > im Forum nicht kümmern willst. > > Es scheint so als ob die Leute die dir helfen sollen sich > deine "Codierungen" gefälligst selbst zurechtschneidern. > > Du bist hier lang genug angemeldet um zu wissen wie und > was man postet. Ich entschuldige vielmals das ich dein Tag so ruiniert habe. Hätte ich nach den ganzen Jahren die ich hier angemeldet bin nur nicht vergessen was für eine schwere Tat es ist unbewusst ein falsches Format hochgeladen zuhaben, dann hätte ich es mir vorhin 2 mal überlegt was zu posten. Tut mir wirklich wirklich leid
heic, voll das Bildformat, is klar. H g schrieb: > Der Drehgeber Interrupt unterbricht nunmal das zeilenweise Schreiben > aufs Display, das wird sich nicht ändern lassen. > > Während eines zusätzlichen delays, egal wo, wird das Display auch nicht > fertig gefüllt. > > Dazu bräuchtest du zwischen einen Framebuffer, der dann auf Kommando auf > einen Rutsch ohne weiteres Zutun des Microcontrollers angezeigt wird.
Angehängte Dateien:
-
png1.png
970 KB
Jack V. schrieb: > Damian M. schrieb: >> Hier sind noch mal die Fotos in einem richtigen Format > > → 10MB PNG. Ist das Absicht? Nein irgendwas stimmt hier nicht. spinnt alles total beim hochladen..
Vorschlag: warum lädst du die Bilder nicht einfach im JPG-Format hoch, wie’s dir nun schon mehrfach nahegelegt worden ist? Ich mein … du möchtest doch, dass die Leute sich das anschauen und idealerweise den Fehler benennen können, oder? Warum machst du’s ihnen denn nahezu unmöglich, die Bilder anzuschauen?
Jack V. schrieb: > Vorschlag: warum lädst du die Bilder nicht einfach im JPG-Format hoch, > wie’s dir nun schon mehrfach nahegelegt worden ist? Ich mein … du > möchtest doch, dass die Leute sich das anschauen und idealerweise den > Fehler benennen können, oder? Warum machst du’s ihnen denn nahezu > unmöglich, die Bilder anzuschauen? Weil hier irgendwas ist dem hochladen nicht ganz so funktioniert wie es soll...
Kommt noch ein Kommentar auf Beiträge zum Thema oder hängen wir uns am Datenvolumen auf? Das eine Bild reicht, auch das Thumbnail, keine muss die 10MB laden
Die Fehlerursache ist in der Stromversorgung, der Verkabelung, der Schaltung oder dem Quelltext.
Damian M. schrieb: > Nein irgendwas stimmt hier nicht. spinnt alles total beim hochladen.. Nein, der Fehler sitzt vor Bildschirm und Tastatur. Du scheinst keine Ahnung zu haben was du tust.
Damian M. schrieb: > spinnt alles total beim hochladen... Kann nicht sein, Apple Geräte funktionieren immer so wie sie sollen. Wenn etwas nicht klappt, liegt es an falschen Erwartungen der Benutzer. Oder so ähnlich.
Damian M. schrieb: > Jack V. schrieb: >> Vorschlag: warum lädst du die Bilder nicht einfach im JPG-Format hoch, >> wie’s dir nun schon mehrfach nahegelegt worden ist? Ich mein … du >> möchtest doch, dass die Leute sich das anschauen und idealerweise den >> Fehler benennen können, oder? Warum machst du’s ihnen denn nahezu >> unmöglich, die Bilder anzuschauen? > > Weil hier irgendwas ist dem hochladen nicht ganz so funktioniert wie es > soll... Jetzt geht's !
Stefan ⛄ F. schrieb: > Wenn etwas nicht klappt, liegt es an falschen Erwartungen der Benutzer. Nein, Apple-User sind unfehlbar. Muss an was Anderem liegen. Aber ansonsten ist die Frage ja schon umfassend beantwortet worden: Stefan ⛄ F. schrieb: > Die Fehlerursache ist in der Stromversorgung, der Verkabelung, der > Schaltung oder dem Quelltext.
>> Stefan ⛄ F. schrieb: >> Die Fehlerursache ist in der Stromversorgung, der Verkabelung, der >> Schaltung oder dem Quelltext. Ja danke.. wo denn auch sonst. Aber wo genau ist hier die Frage
Damian M. schrieb: > Aber wo genau ist hier die Frage Woher soll ich das wissen? Du rückst ja nicht mit den nötigen Informationen raus. Du hast uns nichts angeboten, was wir überprüfen können. Messequipment ist vermutlich auch nicht vorhanden, oder doch?
Jack V. schrieb: > Aber ansonsten ist die Frage ja schon umfassend beantwortet worden: Das ist keine Antwort, sondern das typische Geschwätz von: > Stefan ⛄ F. schrieb: >> Die Fehlerursache ist in der Stromversorgung, der Verkabelung, der >> Schaltung oder dem Quelltext.
Sieht für mich nach ’nem Timingproblem aus. Insbesondere, wenn ich sowas lese: Damian M. schrieb: > Delay sowohl in der Loop als auch (Todsünde ich weiß) in der ISR Damit lässt sich der Fehler eingrenzen auf: liegt am Code. Solange der also geheim gehalten wird, wird das wohl auch so bleiben.
Ich würde erstmal Fragen, ist das SPI oder I2C und bei welcher Frequenz? Der Sketch wäre ganz interessant und welche Library für den Encoder. vielleicht kann man mal Testweise einen "Block" zwischensetzen.
Null Infos aber aber 80 MB Bilder angehangen, das ist vermutlich schon der Rekord für das ganze künftige Jahr. Benutze mal dein Hirn! Hakim schrieb: > Das ist keine Antwort, sondern das typische Geschwätz Dein einziger Beitrag bisher war saudummes Geschwätz: Hakim schrieb: > Holz oder Heizöl? Sei so nett und mache uns vor, wie du es besser machst.!
Hakim schrieb: > Das ist keine Antwort Das ist leider die einzige Antwort, welche die zur Verfügung gestellten Informationen mit einiger Sicherheit erlaubt. Alles Andere wäre grundlagenlose Spekulation, und daher nicht zielführend.
H g schrieb: > Der Drehgeber Interrupt unterbricht nunmal das zeilenweise > Schreiben > aufs Display, das wird sich nicht ändern lassen. > > Während eines zusätzlichen delays, egal wo, wird das Display auch nicht > fertig gefüllt. > > Dazu bräuchtest du zwischen einen Framebuffer, der dann auf Kommando auf > einen Rutsch ohne weiteres Zutun des Microcontrollers angezeigt wird.
Stefan ⛄ F. schrieb: > Null Infos aber aber 80 MB Bilder angehangen, das ist vermutlich schon > der Rekord für das ganze künftige Jahr. Benutze mal dein Hirn! > > Hakim schrieb: >> Das ist keine Antwort, sondern das typische Geschwätz > > Dein einziger Beitrag bisher war saudummes Geschwätz: > > Hakim schrieb: >> Holz oder Heizöl? > > Sei so nett und mache uns vor, wie du es besser machst.! Bitte verzieh dich und geh jemand anderen auf die Nerven. Du gibst einfach nur ein unnötigen Müll von dir weil du wahrscheinlich ein einfach unzufriedener Mensch bist. Der selber keine Ahnung hat aber gerne auf andere Ahnungslose rumhakt weil er sich dadurch überlegen fühlt.
Damian M. schrieb: > Bitte verzieh dich und geh jemand anderen auf die Nerven. Ok, dann bleibe halt ohne Hilfe.
Philipp K. schrieb: > Ich würde erstmal Fragen, ist das SPI oder I2C und bei welcher Frequenz? > > Der Sketch wäre ganz interessant und welche Library für den Encoder. > vielleicht kann man mal Testweise einen "Block" zwischensetzen. Hallo, I2C und die Frequenz musst du wohl aus dem Code entnehmen, da ich nicht weiß woher ich die sonst ablesen kann. HIER ABER ERSTMAL DER Sketch :
Damian M. schrieb: > Philipp K. schrieb: >> Ich würde erstmal Fragen, ist das SPI oder I2C und bei welcher Frequenz? >> >> Der Sketch wäre ganz interessant und welche Library für den Encoder. >> vielleicht kann man mal Testweise einen "Block" zwischensetzen. > > Hallo, > > I2C und die Frequenz musst du wohl aus dem Code entnehmen, da ich nicht > weiß woher ich die sonst ablesen kann. > > > HIER ABER ERSTMAL DER Sketch : Das war der falsche hier noch mal der richtige
Damian M. schrieb: > Damian M. schrieb: >> Philipp K. schrieb: >>> Ich würde erstmal Fragen, ist das SPI oder I2C und bei welcher Frequenz? >>> >>> Der Sketch wäre ganz interessant und welche Library für den Encoder. >>> vielleicht kann man mal Testweise einen "Block" zwischensetzen. >> >> Hallo, >> >> I2C und die Frequenz musst du wohl aus dem Code entnehmen, da ich nicht >> weiß woher ich die sonst ablesen kann. >> >> >> HIER ABER ERSTMAL DER Sketch : > > Das war der falsche hier noch mal der richtige "OLED_LCD_Testcode_mit_Drehgeber.ino" der hier ist es
Stefan ⛄ F. schrieb: > Damian M. schrieb: >> Bitte verzieh dich und geh jemand anderen auf die Nerven. > > Ok, dann bleibe halt ohne Hilfe. Auf deine Hilfe kann ich verzichten
Ich habe den Fehler erkannt, aber da ich ja "keine Ahnung" habe und nur "unnötigem Müll" von mit gebe, behalte ich die Erkenntnis für mich. Jetzt fühle ich mich tatsächlich überlegen.
Stefan ⛄ F. schrieb: > Ich habe den Fehler erkannt, aber da ich ja "keine Ahnung" habe und nur > "unnötigem Müll" von mit gebe, behalte ich die Erkenntnis für mich. > > Jetzt fühle ich mich tatsächlich überlegen. Lieber suche ich noch ein Monat weiter als von so einem Menschen wie dir Hilfe anzunehmen :)
Damian M. schrieb: > Lieber suche ich noch ein Monat weiter als von so einem Menschen wie dir > Hilfe anzunehmen Viel Glück dabei
Kann nur ich das lesen? schrieb: > H g schrieb: >> Der Drehgeber Interrupt unterbricht nunmal das zeilenweise >> Schreiben >> aufs Display, das wird sich nicht ändern lassen. >> >> Während eines zusätzlichen delays, egal wo, wird das Display auch nicht >> fertig gefüllt. >> >> Dazu bräuchtest du zwischen einen Framebuffer, der dann auf Kommando auf >> einen Rutsch ohne weiteres Zutun des Microcontrollers angezeigt wird.
H g schrieb: > Der Drehgeber Interrupt unterbricht nunmal das zeilenweise Schreiben > aufs Display, das wird sich nicht ändern lassen. > > Während eines zusätzlichen delays, egal wo, wird das Display auch nicht > fertig gefüllt. > > Dazu bräuchtest du zwischen einen Framebuffer, der dann auf Kommando auf > einen Rutsch ohne weiteres Zutun des Microcontrollers angezeigt wird. Und wie genau bekomme so einen Framebuffer ?
Kann nur ich das lesen? schrieb: > Kann nur ich das lesen? ... Framebuffer Das mache die AdaFruit Library doch schon so! Aber hey, ich habe ja keine Ahnung.
Damian M. schrieb: > Und wie genau bekomme so einen Framebuffer ? Um auch kurzzeitige Artefakte loszuwerden: Entweder du nimmst ein Display, dass schon einen hat, oder es muss zusätzliche Hardware her, z.B. ein weiterer Microcontroller. Es sollte doch aber auch reichen mit dem Neuzeichnen erst aufzuhören, wenn es erfolgreich abgeschlossen ist und kein Interrupt dazwischen gefunkt hat.
Jack V. schrieb: > Hakim schrieb: >> Das ist keine Antwort > > Das ist leider die einzige Antwort, welche die zur Verfügung gestellten > Informationen mit einiger Sicherheit erlaubt. Alles Andere wäre > grundlagenlose Spekulation, und daher nicht zielführend. Dann wäre die Antwort "42" wohl korrekt!
Kann nur ich das lesen? schrieb: > Es sollte doch aber auch reichen mit dem Neuzeichnen erst aufzuhören, > wenn es erfolgreich abgeschlossen ist Das macht die Adafruit Library doch schon so. Interrupts stören dabei nicht. Aber hey, ich habe ja keine Ahnung!
Stefan ⛄ F. schrieb: > Das macht die Adafruit Library doch schon so. Interrupts stören dabei > nicht. Die Adafruit lib kann also verhindern, dass die SPI Übertragung durch einen Interrupt gestört wird?
H g schrieb: > Die Adafruit lib kann also verhindern, dass die SPI Übertragung durch > einen Interrupt gestört wird? Zähle mal die Anzahl der Anschlüsse an Display.
Stefan ⛄ F. schrieb: > Zähle mal die Anzahl der Anschlüsse an Display. Ups, dann eben I²C, selbes Problem
Den macht man sich selber.. meine letzten Sachen mit dem SSD1306 sind lange her. Ich habe mal ein mögliches Beispiel angehängt wie man Tricksen kann.
H g schrieb: > dann eben I²C, selbes Problem Der I²C Port überträgt per Hardware immer vollständige Bytes. Pausen zwischen den Bytes stören per Definition nicht.
in dem Sketch fehlt noch ein "display.setCursor(83, 57);" nach "display.println(oldposition);" EDIT: Achja zum Loop.. Du weisst schon das der Loop mehrere Tausende/Millionen male pro sekunde durchlaufen wird?
@ Damian Ich denke das Programm-Konzept ist zu einfach um erfolgreich zu sein. Um kurz zusammenzufassen, was ich zu erkennen meine: 1. Du reagierst per Interrupt auf Drehgeberbewegungen. 2. Du setzt unmittelbar die Ausagebvariable 3. Das geschieht unabhängig davon, ob die vorherige Ausgabe schon fertig ist, oder nicht. Du wiederholst in der loop-Funktion einfach nur immer wieder die Ausgabe mit dem momentanen Wert der Variablen. 4. Die Ausgabe erfolgt auch, wenn sich der Variableninhalt nicht geändert hat. Ist-Zustand: In gewissen Fällen werden zwei Fragmente (oben und unten) von zwei verschiedenen Ziffern ausgegeben. Man kann nach der Programmkonstruktion und der Anzeige annehmen, dass sich der Inhalt der Variablen während der Anzeige durch den Interrupt verändern kann. Der Variableninhalt aber fortlaufend von der Anzeigefunktion benutzt wird um die Pixelzeilen zu adressieren. Daher wirkt sich eine Änderung des Variableninhalts sofort , wenn die Anzeigefunktion nach dem Drehgeberinterrupt fortfährt, aus. Offenbar wird die I2C-Kommunikation nicht entscheidend gestört (obwohl klar ist, dass sie durch den Drehgeber-Interrupt unterbrochen wird). Soll-Zustand Die sofortige Übertragung des veränderten Variableninhalts gilt es zu verhindern. Und zwar so, dass die Drehungen einerseits fortaufend und ohne Lücken erfasst werden, die Anzeigefunktion aber so kurz wie möglich unterbrochen wird. Umgekehrt darf, während der momentane Variablenhinhalt verarbeitet wird, keine Änderung daran stattfinden. Vorteilhaft wäre auch, dass die Anzeige nur dann neu aufgebaut wird, falls sich der Variableninhalt geändert hat. Lösung: Hast Du vielleicht eine Idee dazu? P.S. Die Reaktionen würde ich an Deiner Stelle ausschliesslich nach ihrem sachlichen Inhalt beurteilen und auswerten. Diskussionen über Stil und Ton sind erfahrungsgemäß in der Regel sinnlos. Wenn ich auch sehe, dass Du formale Fehler gemacht hast, bedaure ich dennoch, dass so mit Dir umgegangen wird.
H g schrieb: > SPI Nix SPI
1 | Initialize display with the I2C address of 0x3C |
Ich tippe auf Hardware (neben der grottigen Drehencoder-Abfage) - z. B. fehlende Pull-ups o. ä. Es könnte auch schlicht das Display defekt sein. Mal probiert in den oberen Bereich etwas zu schreiben oder einen Punkt / eine Linie in die oberen 2 Zeilen zu setzen?
Beitrag #6092891 wurde von einem Moderator gelöscht.
> > P.S. Die Reaktionen würde ich an Deiner Stelle ausschliesslich nach > ihrem sachlichen Inhalt beurteilen und auswerten. Diskussionen über Stil > und Ton sind erfahrungsgemäß in der Regel sinnlos. > Wenn ich auch sehe, dass Du formale Fehler gemacht hast, bedaure ich > dennoch, dass so mit Dir umgegangen wird. Vielen Vielen dank :)
Hugo H. schrieb: > H g schrieb: >> SPI > > Nix SPI > >
1 | > Initialize display with the I2C address of 0x3C |
2 | >
|
> > Ich tippe auf Hardware (neben der grottigen Drehencoder-Abfage) - z. B. > fehlende Pull-ups o. ä. > > Es könnte auch schlicht das Display defekt sein. Mal probiert in den > oberen Bereich etwas zu schreiben oder einen Punkt / eine Linie in die > oberen 2 Zeilen zu setzen? Mein Drehgeber hat schon verbaute Pull-Up Widerstände
Damian M. schrieb: > Mein Drehgeber hat schon verbaute Pull-Up Widerstände Plonk! Deswegen funktioniert der auch richtig. (Kleiner Wink mit dem Zaunpfahl)
Hat der Hinweis von Hugo bzw. mein Wink mit dem Zaunpfahl geholfen?
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.