Guten Tag zusammen,
ich bin dabei mir ein Menü zu schreiben. Dieses ha´t mehrer Unterpunkte
und die Darstellung wird über switch-cases realisiert.
Im Menüpunkt "submenu1_1" wird im case 1: in der oberen Zeile des 16x2
Displays ein Text ausgegeben und darunter ein Potiwert. Dieses Menü wird
nur einmal durchlaufen und sobald der Potiwert einmal übernommen wurde,
bleibt der, so lange das Menü nicht erneut aufgerufen wird, gleich.
Ich weiß leider nicht wie ich nur diesen Wert entweder dauerhaft
aktualisiert bekomme, ohne ständig durch gesammte Menü rauschen zu
müssen und damit ein Displayflimmern zu verursachen oder den Wert immer
nur dann zu aktualisiren wenn der +/- 2 ist. Auch da bleibt die Frage
der Aktualisierung. Ich habs wie folgt versucht.
Im loop steht eine if-Anweisung. Wenn der Menüteil true ist, soll die
Funktion updatePoti ausfeführt werden. Der Schwellenwert der Änderung
beträgt +/- 2 und der aktuelle Potiwert soll immer zwei sekunden
gespeichert werden eh dieser aktuallisiert wird, damit, da der Arduino
so schnell ist, auch die Differenz erreicht wird und nicht mit dem
drehen des Potis so schnell angepasst wird, dass die Differenz immer
Null bleibt. Also sollte die ganze Zeit das switch-case Menü angezeigt
werden und im Hintergrund immer auf einen aktuellen Wert des Protis
gewartet werden. Leider hab ich da wohl irgendwo einen Denkfehler.
Ich poste hier nur die wichtigtsten Stellen des Codes, der sich für
diesen Teil über drei Seiten erstreckt. Falls ihr den ganzen braucht,
hänge ich noch zip-Sketch an.
//---Submenu1_1--//
void submenu1_1() {
menuState1_1 = true;
switch (menu) {
case 1:
lcd.clear();
lcd.setCursor(0, 0);
lcd.print("Timer einstellen");
lcd.setCursor(0, 1);
lcd.print(PotiWert(1));
lcd.print("ms");
if (!digitalRead(selectButton)) {
submenu1_2();
}
}
//---loop---//
void loop() {
Bedienung();
if (menuState1_1 == true)updatePoti(); // die Variable menuState1_1
ist static boolean
//---updatePoti---//
void updatePoti() {
int const potiPin = 0;
int actPotiWert = analogRead(potiPin);
int oldPotiWert;
int PotiDif_1;
int PotiDif_2;
int Poti_update = 2000;
timestamp = millis();
if (millis() - timestamp >= Poti_update)
{
oldPotiWert = actPotiWert;
}
PotiDif_1 = actPotiWert - oldPotiWert;
//PotiDif_2 = oldPotiWert - actPotiWert;
Serial.println(PotiDif_1);
if (PotiDif_1 >= 2)submenu1_1(); else loop();
//if (PotiDif_2 >= -5)submenu1_1();else loop();
}
Ich hoffe ihr könnt helfen.
Gruß
:
Bearbeitet durch User
Den Poti-Wert kannst du auch einfach so ins Display schreiben, ohne den Rest vom Display zu aktualisieren. SetCursor hast du ja schon benutzt...
Markus O. schrieb: > Ich weiß leider nicht wie ich nur diesen Wert entweder dauerhaft > aktualisiert bekomme, ohne ständig durch gesammte Menü rauschen zu > müssen und damit ein Displayflimmern zu verursachen Das sollte man sich einmal anschauen und lösen, wenn es geht: a) Zeile nicht vorher löschen, sondern überschreiben (von ganz links bis ganz rechts) b) Texte lokal spiegeln und nur das überschreiben, was sich geändert hat Zum durchrauschen: Auch das ist auf viele Arten möglich, z.B.: a) Durchrauschen und Messwerte nur jede s aktualisieren. b) Durchrauschen, aber jeder Menüpunkt schaut: Update nur, wenn (neues Menü ODER letztes Update > 1s her) c) Für jeden Menüpunkt mit Messwerten eine "Update-Routine" hinterlegen. d) Statt der Update-Routine eine Beschreibung (wo ist der aktuelle Wert, wo soll er wie angezeigt werden) Am Ende ist es egal, wie Du es machst. Jedes Verfahren hat seine Vor- und Nachteile, daher ist es wichtig, dass Du "alles" mal ausprobierst um das kennen zu lernen. Es gibt ja auch nicht nur eine Methode, Einkäufe ins Auto zu packen.
Danke für deine Antwort. Aber dann müsste ich den case im loop laufen lassen, was wieder zum flackern führt. Oder hast du eine andere Idee?
Hallo A.S. und wie bekomme ich das nur für diesen Eintrag hin? Ich bin da noch nicht so bewandert und erst ca. einen Monat richtig aktiv dabei. Der Switch läuft ja nur einmal durch. Und dann brauche ich innerhalb dieser Methode und des Switches ein loop der diesen Wert immer kontrolliert/aktualisiert.
Markus O. schrieb: > Ich weiß leider nicht wie ich nur diesen Wert entweder dauerhaft > aktualisiert bekomme, ohne ständig durch gesammte Menü rauschen zu > müssen und damit ein Displayflimmern zu verursachen Flimmern entsteht durch ein falsches Schreiben des LCD. Man nutzt NICHT das lcd.clear(), sondern überschreibt immer den Inhalt des LCDs. Dadurch flimmert nix. > oder den Wert immer > nur dann zu aktualisiren wenn der +/- 2 ist. Nicht sinnvoll. > gewartet werden. Leider hab ich da wohl irgendwo einen Denkfehler. Ja, im Konzept. So ein Menu wird periodisch aktualisiert, je nach Anwendung mit 1-10 Hz. Also muss man die Funktion zur LCD Ansteuerung mit dieser Frequenz aufrufen. Das kann man mit der bekannte millis() Abfrage machen, die in allen Arduino Foren rumgeistert. > Ich poste hier nur die wichtigtsten Stellen des Codes, der sich für > diesen Teil über drei Seiten erstreckt. Falls ihr den ganzen braucht, > hänge ich noch zip-Sketch an. Es gibt keinen Zip-Sketch. Der Quelltext beim Arduino wird sketch genannt, wenn gleich man über den Namen streiten kann. Eine einfache Quelltextdatei über 2 Seiten muss man nicht mit ZIP packen, die paar kB interessiert das Internet schon seit Jahrzehnten nicht. Pack sie einfach in den Anhang und gut.
Hallo, entweder per millis aller halben oder ganzen Sekunde o.ä. ständig sturr aktualisieren. Oder was sich mit Ganzzahlen anbietet die sich nicht permanent ändern eine Aktualisierung nur bei Wertänderung. Kannste machen wie Nolte. Desweiteren solltest du alles in Funktionen schreiben. Danach wird mittels switch case nur das notwendige Menü ausgewählt und das aktive case ruft alle erforderlichen Funktionen auf. Wenn das LCD in verschiedenen Untermenüs verschiedene Werte anzeigen soll, dann muss der LCD Funktion eben der Anzeigewert als Parameter übergeben werden und die LCD Funktion in allen case aufgerufen werden.
Ich würde die Display Ausgabe als eigenen Thread (oder in einer ISR) ganz unabhängig vom Rest des Programms implementieren. Irgendwo im RAM steht, was ausgegeben werden soll. Das macht der Thread in regelmäßigen Intervallen. Mit dem Ansatz wird vieles einfacher. Es macht auch Sinn, die Eingabe vom Hauptprogramm zu trennen. Richte dir Warteschlange ein, in der alle Ereignisse abgelegt werden, wie 1 = Taste gedrückt 2 = Taste ist immer noch gedrückt (alle 200ms) 3 = Taste losgelassen 4 = Drehgeber wurde 1 Schritt nach links gedreht 5 = Drehgeber wurde 1 Schritt nach rechts gedreht usw. Dein Hauptprogramm arbeitet dann die Ereignisse ab, und erzeugt die Ausgabe im RAM. Bei dem Konzept ist es viel einfacher, später weitere Eingabe- und Ausgabe-Schnittstellen hinzuzufügen. Das Timing der Schnittstellen wird außerhalb des Hauptprogramms geregelt.
Sag mal Markus, mir fällt gerade was auf. Machst du dich gerade mit deinen Fragen in mehreren Foren breit? Erst im Arduino Forum wo du deine Themen nicht mehr beantwortest und jetzt gehts hier weiter? Das kann ganz schnell nach hinten losgehen. Deine verstreuten Threads kannst du sowieso nicht mehr vernünftig pflegen, also überlege dir wie du deine Fragen bündelst und deine Themen auch pflegst. Man muss auch nicht wegen jeder Frage einen neuen Thread aufmachen wenn sowieso alles zusammenhängt. Nur einmal so als Tipp für die Zukunft.
Stefan ⛄ F. schrieb: > Ich würde die Display Ausgabe als eigenen Thread (oder in einer ISR) > ganz unabhängig vom Rest des Programms implementieren. Jaja, der Experte wieder. Der Rest der Welt, vor allem Anfänger, nutzen eine popelige Funktion.
Falk B. schrieb: > Stefan ⛄ F. schrieb: >> Ich würde die Display Ausgabe als eigenen Thread (oder in einer ISR) >> ganz unabhängig vom Rest des Programms implementieren. > Jaja, der Experte wieder. Der Rest der Welt, vor allem Anfänger, nutzen > eine popelige Funktion. Ich machs wie Stefan: das "Bild" wird im RAM aufgebaut und irgendwas sorgt dafür, dass das dann irgendwo erscheint. Ein 2x20 Display wird in meinem Fall dann bei 2x20 = 40Zeichen bei einer langsamen Updaterate von 2ms/Zeichen mit 80ms aktualisiert. Das ist schnell genug. Das Schöne daran ist, dass jederzeit und von überall (auch ein Interrupt) Werte in diesem "Display-RAM" geändert werden kann. Und auch, dass ich den "Bildinhalt" z.B. per serieller Schnitte irgendwo anders hin schicken und dort auch anzeigen kann. Und das Beste daran ist, dass das Schreiben aufs "Display-RAM" fix geht, ich auf das Display nicht warten muss und dass die Anzeige auf dem Display dank des unnötigen lcd_clear() nicht flackert. Aber wie immer: jeder nach seinem Gusto... ;-)
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Ich machs wie Stefan: Vermutlich, weil Du kein Falk B. schrieb: > Anfänger bist, im Gegensatz zum TO.
Ich denke dass es sinnvoll ist, einem Anfänger Anregungen zu geben, wie er es konzeptionell besser machen kann. Vor allem nachdem er darum gebeten hatte.
Stefan ⛄ F. schrieb: > Ich denke dass es sinnvoll ist, einem Anfänger Anregungen zu geben, wie > er es konzeptionell besser machen kann. Vor allem nachdem er darum > gebeten hatte. Aber nicht, was er im Moment gar nicht verarbeiten kann. Man erklärt einem 5 Klässer auch keine Integralrechnung.
Falk B. schrieb: > Man erklärt einem 5 Klässer auch keine Integralrechnung. Du übertreibst. So kompliziert ist das nicht. Wenn ihn der Ansatz interessiert, kann er ja gerne nachfragen, dann helfen wir ihm.
Falk B. schrieb: > Man erklärt einem 5 Klässer auch keine Integralrechnung. Genau. Der TO ist mit der einfachen Ausgabe aufs Display (ohne clear) oder dem Konzept der Loop noch heillos überfordert. Das mag in 2 Tagen oder Wochen anders sein. Aber heute sind Multitasking, Race Conditions und Eventhandling 3 Nummern zu groß.
A. S. schrieb: > Vermutlich ... weil ich weiß, dass komplizierte Programme, die einfache Sachen machen, in der Realität nicht gut funktionieren. Und das hört sich mal echt kompliziert an, was Markus O. schrieb: >>> Der Schwellenwert der Änderung beträgt +/- 2 und der aktuelle Potiwert >>> soll immer zwei sekunden gespeichert werden eh dieser aktuallisiert >>> wird, damit, da der Arduino so schnell ist, auch die Differenz >>> erreicht wird und nicht mit dem drehen des Potis so schnell angepasst >>> wird, dass die Differenz immer Null bleibt. Mich würde es als Bediener echt anviechen, wenn ich am Poti drehe und erst 2 Sekunden später passiert was. Oder schlimmer noch: manchmal passert sofort was, und manchmal erst nach 2 Sekunden. Je nachdem wo der Timer grade war, als ich zu drehen begonnen habe. Markus O. schrieb: > Ich weiß leider nicht wie ich nur diesen Wert entweder dauerhaft > aktualisiert bekomme, ohne ständig durch gesammte Menü rauschen zu > müssen 1. trenne das Menü von der Anzeige 2. trenne das Einlesen des Potis von der Menüverwaltung 3. trenne die Anzeige vom Poti Weil du alles ineinander verwurstelst, wird es irgendwann halt kompliziert. Und in dem Fall hier schon ziemlich bald. Natürlich wird durch das Auftrennen der Code länger, aber er wird letztlich garantiert auch einfacher. Falk B. schrieb: > Man erklärt einem 5 Klässer auch keine Integralrechnung. Wenn er mich danach fragt, warum nicht? Ich klatsche ihm dazu natürlich nicht gleich jede Menge hochwichtiger Fachbegriffe vor den Latz. Aber auch der Fünftklässler wird kapieren, dass er schon beim volllaufenden Waschbecken mit diesem "Integrieren" zu tun hat, und dass es eigentlich gar nicht so schlimm ist... Markus O. schrieb: > Falls ihr den ganzen braucht, hänge ich noch zip-Sketch an. Tu das mal, aber häng lieber einzelne ino Dateien an, dann kann man den Code auch mit dem Handy anschauen.
:
Bearbeitet durch Moderator
Hallo, nur zur Info. Den TO werdet ihr hier nicht wiedersehen. Der verfasst lieber Crosspostings.
Aber wenigstens versucht er sich nun an den Grundlagen von FSM: https://forum.arduino.cc/t/gegen-lcd-flackern/912265
Markus O. schrieb: > Ich hoffe ihr könnt helfen. Vergiss den Andatz, den Zustand in dem sich das System befindet, welches Menü aktiv ist, durch die Programmposition zu speichern, ob es also in submenu1_1() Nutze eigene Variablen um den Zustand zu speichern. und lasse die loop dauernd ganz durchlaufen, nie stoppen, ob Tastendruck oder Tastenloslsssen, ob in Menü oder Submenü. Markus O. schrieb: > Auch da bleibt die Frage der Aktualisierung. Wenn man ein LCD nicht löscht, sondern nur alle (2 x 20?) Zeichen inklusive der Leerzeichen überschreibt, flimmert da nichts ausser dem Cursor (wenn man ihn vergessen hat auszuschalten).
Hallo, erstmal abwarten, kann auch sein er verlässt seinen Thread und stellt die nächste Frage. Das ging die letzten Tage nur so. Irgendwann sollte er das lernen. Zurück zu eurer Unterhaltung. Ihr meint mit Display RAM sicherlich nicht einen RAM im Display sondern einen (char) Buffer im Programm? Nur warum aus einer ISR heraus das Display beschreiben? Das blockiert doch die ISR. In der Regel hat man doch sicherlich eine Funktion die den Bufferinhalt an die gewünschte Schnittstelle rausgibt. Man kann es vielleicht unter Umständen aus einer ISR heraus machen, wenn man weiß das die Serielle und Wire wie bei Arduino einen eigenen Buffer hat. Aber SPI hat laut meines Wissens unter Arduino keinen Buffer und würde unmittelbar blockieren. Die Serielle und Wire würde blockieren wenn deren Buffer voll ist. Will sagen aus irgendeiner ISR heraus wäre ich erstmal vorsichtig. Ich hatte mal vor paar Jahren begonnen eine Lib zu schreiben, erstmal nur für SPI Ausgaben aller Art. Also nicht speziell für Displays obwohl das der Hauptgrund war. Jedes Display Objekt (C++) hat seinen eigenen Buffer und eine Statemaschine behandelt alle Objekte. Wenn irgendwo etwas im Buffer stand und damit ausgegeben werden soll kümmert sich die SM darum, setzt und löscht den Objektzugehörigen CS Pin und sendet mittels SPI Interrupts die Daten raus. Das läuft im Kreis über alle Objekte. Damit blockiert nichts wie bei der Seriellen. Liegt auf Eis weil das irgendwann zu kompliziert wurde mit der Anzahl der Objekte. Ich warte noch bis sich schlauer bin und eine bessere Lösung finde. Obwohl mir der Ansatz an sich nachwievor gefällt. Kommt Zeit kommt Rat. :-)
:
Bearbeitet durch User
Veit D. schrieb: > Zurück zu eurer Unterhaltung. Ihr meint mit Display RAM sicherlich nicht > einen RAM im Display sondern einen (char) Buffer im Programm? Nur warum > aus einer ISR heraus das Display beschreiben? Das blockiert doch die > ISR. In der Regel hat man doch sicherlich eine Funktion die den > Bufferinhalt an die gewünschte Schnittstelle rausgibt. Wenn Du das "stupide", jeweils dann ausgibst, wenn dein Prog. das vorsieht, musst Du, weil Du ja keine Ahnung hast wann die letzte Ausgabe gemacht wurde, erst einmal warten und dies dann für jedes Zeichen wiederholen (Main-Loop blockieren). Oder halt ein Flag setzen (diese ISR muss ja nich immer aktiviert sein) und per ISR solange jeweils ein Zeichen auszugeben, bis der Buffer leer ist. Beim letzten Zeichen im Buffer, nich vergessen das zugehörige Flag zu löschen. Das musst Du natürlich auch darauf Prüfen ob der Buffer frei ist, bevor Du da wieder reinschreiben kannst. Aber wenn Du die beiden Befehle, Display-Clear, Cursor-Home, "ausklammerst", sonder behandelst, kann man die ISR alle 50µs aufrufen. Ich machs vieeel eleganter (Hab seltenst genug RAM über), ich prüf das Busy-Bit und warte dann stupide auf Freigabe.... zum Glück nich in der ISR. *_+ PS: Letzteres ist nur real umgesetzte Ironie .... Weil ichs kann!-)
Teo D. schrieb: > Wenn Du das "stupide", jeweils dann ausgibst, wenn dein Prog. das > vorsieht, musst Du, weil Du ja keine Ahnung hast wann die letzte Ausgabe > gemacht wurde, erst einmal warten und dies dann für jedes Zeichen > wiederholen (Main-Loop blockieren). Deswegen war die Rede davon, die Ausgabe zeichenweise in einem Timer Interrupt zu machen. Dann braucht man nicht zu warten, weil man weiß dass die letzte Ausgabe lange genug her ist.
Stefan ⛄ F. schrieb: > Teo D. schrieb: >> Wenn Du das "stupide", jeweils dann ausgibst, wenn dein Prog. das >> vorsieht, musst Du, weil Du ja keine Ahnung hast wann die letzte Ausgabe >> gemacht wurde, erst einmal warten und dies dann für jedes Zeichen >> wiederholen (Main-Loop blockieren). > > Deswegen war die Rede davon,.... Du hast wirklich nich weiter gelesen!?-O ... :´(
Markus O. schrieb: > in der oberen Zeile des 16x2 > Displays ein Text ausgegeben und darunter ein Potiwert. HimmelHerrgott, was für ein höllisches Menue wird man schon auf diesem Display ausgeben können?! Und was für eine himmlische Anwendung läuft da wohl, die einen zwingt mit dem Display so einen Blödsinn anzustellen?? Überwachst du die Brennstäbe eines Reaktors, während der User unverschämt und penetrant das Menue aufruft und das neue Datum für die Firmenfeier eingeben will? Ich muß mir immer ein realistisches Szenario vorstellen können...hier kann ich es beim besten Willen nicht! Rainer
Markus O. schrieb: > ich bin dabei mir ein Menü zu schreiben. Dieses ha´t mehrer Unterpunkte > und die Darstellung wird über switch-cases realisiert. > Im Menüpunkt "submenu1_1" wird... Oh je, du machst es also wie die üblichen C-Programmierer: zuerst in die Tasten hauen und Quellcode produzieren und erst anschließend anfangen, darüber nachzudenken, wie das Ganze eigentlich funktionieren soll. Vielleicht nützt es dir, wenn ich mal ein wenig darüber plaudere, wie ich es vor vielen Jahren für reine Text-Displays gemacht habe: 1. das Menü besteht aus einem Array von Structs 2. ein jeder Struct enthält ein Byte mit Flags sowie einen Text, der in sich diverse Platzhalter enthält (im Prinzip so ähnlich, wie es auch beim Formatstring von printf gemacht wird) und dazu ggf. drei Zeiger auf Funktionen, die zum Editieren dieses Menüpunktes benötigt werden (oder eben 3x nil) 3. bei den Flags gibt es wenigstens 2, die für das Manövrieren im Menü benötigt werden: Flag für den ersten Eintrag und flag für den letzten Eintrag. Dazu können weitere Flags je nach Gusto kommen: ein Flag für Einträge, die alle nase lang mal aktualisiert werden müssen usw. 4. es gibt einen Positionszeiger, der anzeigt, wo im gesamten Menü man momentan steht und es gibt ein generelles Flag, was anzeigt, ob man grad am Manövrieren oder am Editieren ist 5. es gibt ein paar Standardfunktionen für das Menü: eine zum Anzeigen, eine die bei 'enter' bzw. 'Auswahl' aufgerufen wird und zwei, die (jeweils) bei 'Rauf' bzw. 'Runter' aufgerufen werden. Das war's so im Groben, man kann damit ohne irrwitzige switch-case Artistik ein Menü (auch mit Untermenüs) machen und auf Alpha-LCD's darstellen. Eine Besonderheit nur noch: entweder spendiert man jedem Menüpunkt einen void Zeiger zum Zeigen auf eine darzustellende Variable oder man hat in der Anzeige-Funktion eine switch-case Latte, die so lang ist wie man verschiedene Variablen im Menü anzeigen will. Für die heutigen bunten Grafik-Displays muß das Ganze natürlich anders aussehen, da ist ein Array nicht die richtige Wahl und C eigentlich auch nicht so recht. Da läuft das Ganze eher auf eine verkettete Liste hinaus mit Elementen, so ähnlich wie man sie von Delphi oder so her kennt. Also sowas wie verschiedene Fenster, die Dinge wie Text oder ein Icon oder einen Rand oder einen besonderen Hintergrund enthalten können und eine Koordinate haben. Aber das ist hier nicht nötig. W.S.
Markus O. schrieb: > lcd.clear(); ist oft Mist und es flimmert, brauchst du das oder könnte man auch nur die Änderungen überschreiben?
Rainer V. schrieb: > Markus O. schrieb: >> in der oberen Zeile des 16x2 >> Displays ein Text ausgegeben und darunter ein Potiwert. Und ich schlage jetzt noch mal drauf! Wenn schon dieses Kinderdisplay flimmert, weil der Programmer nicht das geringste verstanden hat, dann wundert mich gar nix! Und es ist ihm natürlich wegen mangelnder Kenntnisse auch nichts nahe zu bringen. Denn er weiß ja gar nicht, was er nicht weiß. Das ewige Problem. Rainer
Rainer V. schrieb: > Das ewige Problem. Naja, es ist schon ein ewiges Problem. Deshalb ist wohl auch nicht jeder zum Lehrerberuf geeignet, denn ein Lehrer hat jedes Jahr exakt dieselben Probleme. Kaum hat er einer Schulklasse etwas beigebracht, schon kommt die nächste Klasse dran, die es noch nicht weiß. Und viele Leute, die hier schreiben haben nicht den Gleichmut, der für Lehrer notwendig ist (ich auch nicht), weswegen man hier öfter als es einem lieb ist ausrastet und schimpft. So. Wenn der TO so einigermaßen lernfähig (und lernwillig) ist, dann kann er aus dem bisherigen Threadverlauf genug lernen, um mit seinem Vorhaben weiter zu kommen. Man wird es sehen. W.S.
Stefan ⛄ F. schrieb: > Möchte noch jemand nach treten? Es sind die Geister, die Du riefst: Der TO war damit überfordert, den Rat der ersten beiden Posts (kein clear, nur schreiben) umzusetzten. Also ein If einzubauen. Dann kommen Multitasking, ISR, Eventpuffer und später Typen, die allen Ernstes so tun, als wäre das Display pillepalle. Was absolut daneben ist. Ich kenne höchst komplexe und produktive Systeme mit kleinerer Anzeige.
Veit D. schrieb: > Ihr meint mit Display RAM sicherlich nicht einen RAM im Display sondern > einen (char) Buffer im Programm? Nur warum aus einer ISR heraus das > Display beschreiben Das waren 2 unterschiedliche Konzepte: Stefans das Schreiben per ISR, Lothars das füllen des char-buffers im Interrupt. Können beide allein oder in Kombination sinnvoll sein. Überfordern den TO aber sicher noch (Race Conditions)
Hallo, mir fehlt die Antwort welche ISR/Interrupt beide meinen. Mit ISR kann ja auch die der Schnittstelle (USART, SPI, I2C) gemeint sein die letztlich die Daten aus einem angelegten Buffer selbstständig rausschaufelt. Das wäre nachvollziehbar. Ich wüßte aktuell nicht warum man einen Buffer mittels ISR oder in einem Interupt beschreiben sollte. Dafür gibts memcpy & Co. Wenn allerdings der Buffer über die Schnittstelle rausgeschoben werden soll, dann kann man das mittels der Interrupts/ISR der Schnittstelle machen. Mir ist das einfach zu schwammig formuliert was beide mit welchen Interrupt bzw. ISR beide für sich meinen. Das kann alles oder nichts sein. Einen Grund für einen Timer sehe ich erst recht nicht. Ich will es einfach nur wissen um mir das vorstellen zu können welche Gründe es dafür geben kann. Entweder sage ich mir dann "oh interessant ggf. für neue Ideen" oder "ist nichts für mich bzw. passt nicht zu meiner Programmierweise". Ich habe auch nicht vor das irgendwie zu bewerten.
A. S. schrieb: > Das waren 2 unterschiedliche Konzepte: Stefans das Schreiben per ISR, > Lothars das füllen des char-buffers im Interrupt. NEIN! Da ist ein und das selbe gemeint. Wenn dann is höchstens die Gestaltung des Buffers unterschiedlich (Immer alles -> Schattenspeicher oder halt nur das was gerade eben partiell geändert/angezeigt werden soll). Veit D. schrieb: > mir fehlt die Antwort welche ISR/Interrupt beide meinen. Mit ISR kann ja > auch die der Schnittstelle (USART, SPI, I2C) gemeint sein die letztlich > die Daten aus einem angelegten Buffer selbstständig rausschaufelt Stellst Du dich nu mit absichtlich blöde oder.....
W.S. schrieb: > Naja, es ist schon ein ewiges Problem. Mir geht es um den Unterschied zwischen "kapiere nichts wegen fehlender Grundlagen" oder "kapiere nichts, weil mir der entscheidende Kick fehlt". Ich sage das nicht als langbewährte Lehrerweisheit, sondern aus meinen bescheidenen Erfahrungen mit Nachhilfeschülern. Neben den zweien, die Nachhilfe wollten, weil sie das Abi mit mindestens 2+ machen wollten (und auch geschafft haben...), habe ich immer gegen fehlende Grundlagen gekämpft...oft sogar gegen blödsinniges Elternverständnis. Wer in die Oberstufe kommt und Dreisatz nicht kapiert hat, die simpelsten Formelvereinfachungen und -Umstellungen nicht hinkriegt (Motivation lasse ich mal außen vor), der kommt halt auf keinen grünen Zweig. Weder in Mathe selbst, noch in Fächern, wo Mathe halt Handwerkszeug ist. Und hier in diesem Fall scheint mir eben, dass der TO 2 Gänge zurückschalten sollte und sein Programm mit seinen "Wünschen" vergleichen sollte. Vielleicht ist die Erfahrung, dass so ein Display überhaupt "ruckeln" kann, auch ganz neu und da muß man halt versuchen zu ergründen warum. Das haben viele hier mit ihren Beiträgen versucht, aber es stellt sich (mal wieder) der Eindruck ein, dass der TO weder was kapiert, noch eben nicht kapieren kann, warum er nichts kapiert! Dafür ist irgendwo eine Grenze gesetzt, die man nur mit energischer Eigenarbeit überwinden kann!! Gruß Rainer
@ Teo, falls du der Echte bist Das ist genau die Antwort die eine Unterhaltung fördert. Immer erst den Anderen für doof hinstellen. Ich kann da nur mit Kopf schütteln. Es wurden nur Begriffe wie ISR und Interrupt in den Raum gewurfen. Ein µC hat jedoch viele Interrupts und viele ISRs. Dann kamst du noch mit Timer um die Ecke. Wer soll daraus schlau werden ...
Veit D. schrieb: > r. Ich wüßte aktuell nicht warum man einen Buffer mittels ISR oder in > einem Interupt beschreiben sollte Nicht "mittels". Sondern "auch": Lothar M. schrieb: > Das Schöne daran ist, dass jederzeit und von überall (auch ein > Interrupt) Werte in diesem "Display-RAM" geändert werden kann. Also im adc Interrupt z.b. oder wenn ein Wert per SPI oder sio reingekommen ist. Im Sinne von "rattenschnell den eigentlichen Text ändern ohne lange zu blockieren". (Wobei das sicher nicht als generelle Empfehlung gemeint war, da sowas komplexe Randbedingungen hat. Also eher im Sinne von "sogar")
OK, der TO ist standesgemäß abgetaucht und wir können wieder einmal überlegen, ob es an unserer Feinfühligkeit gelegen hat oder wo oder wieso... Rainer
Rainer V. schrieb: > ob es an unserer Feinfühligkeit gelegen hat oder wo oder wieso... Hier erklärt sich das von selbst. Markus O. schrieb: > Ich bin da noch nicht so bewandert und erst ca. einen Monat richtig > aktiv dabei. Andere haben das schon sehr früh gemerkt. A. S. schrieb: > Der TO war damit überfordert Da helfen die ganze kompetenten Hinweise unserer Fachkräfte nichts.
Hallo zusammen, vielen Dank für die zahlreichen Antworten und Diskussionen. Danke unter anderem an Falk B. und A.S., das überschreiben funktioniert sehr gut. Das switch-case-menu wurde nur einmal aufgerufen, und ist dann da hängengeblieben, da ich dafür kein loop eingerichtet hatte. Wenn dieser Menüpunkt der switch-cases nun aufgerufen wird, wird dieses Menü durch eine Variable auf true gesetzt und durch den hauptlooop immer wieder, bis zum Abbruch, ausgeführt. Gleiches gilt auch für alle anderen Menüpunkte. Lothar: Der Potiwert wird in dem eingentlichen Sketch nicht alle zwei Sekunde, sondern scnellstmöglich aktuallisiert. Diese war hier auf zwei Sekunden gestellt um den Fehler oder Ablauf besser beobachten zu könnnen. Veit D.: Da hast du Recht. Ich hatte das Gefühl dass mir da nicht allzu gut geholfen wird. Wehaalb ich nun hier bin. Danke für den Hinweis! Danke nochmal an alle Vorschläge und Anregungen. Ich habe mir die für mich interessantesten Punkte notiert und werde mir diese step by step anschauen und hier sicherlich noch die eine oder andere Frage zu stellen. Gruß
Markus O. schrieb: > Danke nochmal an alle Vorschläge und Anregungen. Ich habe mir die für > mich interessantesten Punkte notiert und werde mir diese step by step > anschauen und hier sicherlich noch die eine oder andere Frage zu > stellen. ich versuch auch noch was: Ich schreibe meine Texte immer mit sprintf in ein Array dort kann ich schreiben wann immer sich was ändert und muss mir keine Gedanken machen wann was wo. Das Array (Schattenram) braucht ja nicht viel Platz, bei meinen Nokia LCD 5110 6 Zeilen a 14 Zeichen + /0 Terminator. 90 Byte! Ich habe für Tastenentprellung (nach Dannegger: Artikel im µC.net) einen 10ms Timer IRQ laufen und zähle dort eine Variable von 25 auf Null runter. Wenn die Variable 0 ist wird ein LCD Update gemacht und der Schattenram das Array ins LCD geschrieben mehr als 4 / Sekunde kann eh keiner lesen und das flimmert auch nicht nach dem LCD Schreiben die Variable wieder auf 25 setzen. Für ganz schnelle ADC Werte mit Nachkomma kann das auch auf 10 / Sekunde erhöht werden, wer es braucht.
:
Bearbeitet durch User
Joachim B. schrieb: > ich versuch auch noch was: Hatten wir schon mindestens, wenn nich öfter! Das eigentliche Problem liegt hier, das ein "NichtProgrammierer" die Bäume vor lauter Wald nicht sieht! Beitrag "Schrittkette"
Teo D. schrieb: > Hatten wir schon mindestens, wenn nich öfter! stimmt und manche lernen durch Wiederholung und manche suchen auch nicht. 90% der Antworten hier könnten entfallen weil die Fragen immer wieder kommen.
Wenn mehrere Leute den gleichen bzw. ähnliche Lösungsansätze empfehlen, erkennt der TO, dass dies keine exotische Meinung ist.
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.