Hallo und guten Morgen. Mir raucht schon ein bischen der Schädel vom vielen Lesen, komischer weise macht das aber Spaß. Plan vom Programmieren würde ich mir -noch- keinen attestieren, ich arbeite daran das zu ändern. Schauen wir mal. Hartes Brot das Ganze. Folgenden Hintergrund habe ich: Ich habe mir einen Arduino programmiert der über eine Temperatur- und Feuchteauswertung Relais und Motoren ansteuert zum Fenster öffnen, funktioniert auch, Daten wie Temperatur und Luftfeuchte werden auf einem OLED sh1106 ausgegeben. Ich habe also Code-Schnipsel zusammengefügt, verändert und erweitert und habe nun ein Problem. Bei einer Menüerweiterung um die Temperatur zum ansteuern der Motoren über das Menü zu ändern, Funktioniert die Temperaturwerterhöhung problemlos. Die Temperaturwertabsenkung macht probleme. Auf dem Seriellen Monitor wird die Temperaturänderung einwandfrei umgesetzt, nur der entsprechende Menüpunkt wird nicht auf dem Oled angezeigt. Tausche ich die beiden Menüpunkte (Temp_erhöhung gegen Temp_absenkung), funktioniert die Absenkung problemlos, nur die Erhöhung wird nicht angezeigt. Speicher ist nicht einmal zu 60% belegt, ergo sollten auch ausreichende Ressourcen noch vorhanden sein. Ich, in meiner Ahnungslosigkeit, würde das Problem beim Bildschirm bzw der entsprechenden Libary verorten, die ss_oled.h Allerdings finde ich da nichts was mir weiterhelfen würde. Vielleicht hat einer von euch auch schon diese Erfahrung gemacht, weis eine Lösung oder wo ich was nachgucken kann? Beste Grüße.
Xaver M. schrieb: > Ich, in meiner Ahnungslosigkeit, würde das Problem beim Bildschirm bzw > der entsprechenden Libary verorten Ich in meiner "Ahnungslosigkeit" würde das Problem vor deinem Bildschirm und Tastatur verorten. Xaver M. schrieb: > Folgenden Hintergrund habe ich: > ............. > Ich habe also Code-Schnipsel zusammengefügt, verändert und erweitert So wird das auf jeden Fall nix. Mein Vorredner hat schon gesagt was es braucht.
Darf ich fragen wozu? Mich interessiert gerade weniger eine direkte Lösung des Problems, vielmehr eine Hilfestellung um die Lösung selbst zu finden, wird ja nicht nicht das letzte Problem sein dem ich begegne, und es wäre schön sich eine Vorhegensweise erarbeiten zu können.
Xaver M. schrieb: > Darf ich fragen wozu? Weil aus deiner Vorgehens- und Fehlerbeschreibung kein Schwein schlau wird.
Xaver M. schrieb: > Darf ich fragen wozu? Damit wir nachvollziehen können, was du gemacht hast. Ansonsten wird das hier wie so oft für alle Beteiligten eine große Zeitverschwendung mit widersprüchlichen Aussagen und Beleidigungen.
Hi >Tausche ich die beiden Menüpunkte (Temp_erhöhung gegen >Temp_absenkung), >funktioniert die Absenkung problemlos, nur die Erhöhung wird nicht >angezeigt. Vielleicht liegt der Menüpunkt einfach außerhalb deiner Anzeige. MfG Spess
Spess53 schrieb: > Hi > >>Tausche ich die beiden Menüpunkte (Temp_erhöhung gegen >Temp_absenkung), >>funktioniert die Absenkung problemlos, nur die Erhöhung wird nicht >>angezeigt. > > Vielleicht liegt der Menüpunkt einfach außerhalb deiner Anzeige. > > MfG Spess Ich denke nicht. Als Hintergrundinfo dazu, das Menü besteht aus 8 Gruppenanzeigen, jeweils mehrzeilig, alle 7 Gruppen-texte werden einwandfrei angezeigt, die erste ist leer. Diesem Verdacht bin ich nachgegangen, und habe eine, eher unnütze Anzeige, auskommentiert um die Anzahl zu verringern, ohne Erfolg. das ist der funktionierende Teil:
1 | case 7: |
2 | oledFill(&ssoled, 0, 1); |
3 | char buffer[32] = {0}; |
4 | sprintf(buffer, "%d ",(t1)); |
5 | oledWriteString(&ssoled, 0,0,3,(char*)" Temperatur 1 ", FONT_NORMAL, 0, 1); |
6 | oledWriteString(&ssoled, 0,0,4,(char*)" -erhoehen- ", FONT_NORMAL, 0, 1); |
7 | oledWriteString(&ssoled, 0,0,5,(char*)" ", FONT_NORMAL, 0, 1); |
8 | oledWriteString(&ssoled, 0,0,6,(char*)" ", FONT_NORMAL, 0, 1); |
9 | oledWriteString(&ssoled, 0,35,6,(char*)buffer, FONT_STRETCHED, 0, 1); |
10 | oledWriteString(&ssoled, 0,70,6,(char*)"Grad", FONT_NORMAL, 0, 1); |
11 | break; |
Case 8: also der Nachfolgende, wird mit fast identischem Text nicht angezeigt.
Xaver M. schrieb: > der Nachfolgende, wird mit fast identischem Text nicht > angezeigt. Deswegen sollte man den nichtfunktionierenden Code-Teil auch tunlichst nicht zeigen, denn dann könnte man vielleicht einen Fehler finden.
beo bachta schrieb: > Xaver M. schrieb: >> der Nachfolgende, wird mit fast identischem Text nicht >> angezeigt. > > Deswegen sollte man den nichtfunktionierenden Code-Teil auch > tunlichst nicht zeigen, denn dann könnte man vielleicht > einen Fehler finden. Endlich mal einer der versteht was ich schreibe, genau richtig, ICH will den Fehler finden, daher will ich auch "nur" Hinweise die mich das Lösen lassen. Und weil du so erpicht auf Code bist, ist der gleiche wie oben, ohne Zeile 3 & 4 weil dann eine Fehlermeldung "redeclaration char buffer" kommt und in Zeile 6 steht natürlich nicht erhoehen, sondern senken.
Hi
>eine Fehlermeldung "redeclaration char buffer" kommt
Und warum beseitigst du den Fehler nicht?
MfG Spess
Xaver M. schrieb: > Darf ich fragen wozu? Weil es mit sehr hoher Wahrscheinlichkeit ein Abfragefehler im Code ist. Falsche Zuweisung. Fehler in einer IF-Abfrage, Fehler in der Berechnung der Umwandlung, Fehler bei Vergleichszeichen = ist NICHT gleich. Bei Arduino ist == gleich. Standartfehler ;) von mir . Nur um nur mal 4 der üblichen Fehler aufzulisten. Also würde ich zuständige Variable "beobachten" nach JEDER Änderung. Und ich würde dann entscheiden ob diese Änderung richtig ist wie sie sein sollte bzw. mich fragen wieso sie diesen Unsinn anzeigt. Das ist das übliche Vorgehen bei Fehlersuche. Jedenfalls meins die letzten 27 Jahren und in jede Menge Programmiersprachen. Also einfach viele seriall.print (wert) einfügen bzw. wie das in deiner Sprache geschrieben wird. Dann sieht man die Werte am Seriell-Monitor . Kleiner Tipp schreibe vor jede Zeile Seriall.print("hier bin ich") also eindeutige Stelle wenn man diese Abfrage öfters im Code macht. Das verhindert das du bei der Liste an Zahlen den Fehler an der falschen Stelle suchst. Das ganze nennen die meisten Profis debuggen. Normalerweise macht das die IDE mit Haltepunkten, aber bei der Programmierung eins MC geht es nur so. Die Alternative ist, du lässt ein anderen dein Fehler suchen. Das löst DAS Problem aber du lernst NIE wie man selbst so Fehler sucht. Glaub mir, Syntax-Fehler sind beim Programmieren die harmlosesten. Ein falscher Wert in einer Variable kann dir problemlos das ganze Programm zum Absturz bringen oder schlimmeres.
Xaver M. schrieb: > Case 8: also der Nachfolgende, wird mit fast identischem Text nicht > angezeigt. Frag ihn erst mal via serial-Monitor ab. Und zwar 1 Zeile bevor du ihn den Display zuweist. Das sagt dir ob der Fehler wirklich in der Zuweisungsroutine liegt, oder der Wert schon vorher Falsch bzw. leer ist.
Xaver M. schrieb: > Case 8: also der Nachfolgende, wird mit fast identischem Text nicht > angezeigt. Wird Case 8 überhaupt ausgelöst. ??? Variable für Wert von CASE überprüfen. Du kannst ja Spass halber den Code von Case 7 nach Case 8 kopieren bzw. beide Case einfach vertauschen. Dann weißt du ob Case 8 ausgelöst wird. Einfach bis zur Perversion LOGISCH denken, das ist das einzige was hilft. Wenn du das nicht halbwegs drauf hast, wirst du nie ein gescheites Programm auf die Reihe bekommen. Ist keine Kritik sondern ein wichtiger Hinweis. Es gibt in der Programmierung kein grau, nur s/w, und auch kein Halb schwanger. Den Anfängern wurde damals auf den Schulen (k.a. obs das noch gibt) sogenannte Ablaufdiagramme beigebracht. Damit sie genau DAS verstehen. Ich habe die Dinger gehasst. Das Programm hatte ich schneller geschrieben als die Dinger gemalt. Aber damit war ich der Einzige auf den Lehrgang.
Schlaumaier schrieb: > Das ganze nennen die meisten Profis debuggen. Normalerweise macht das > die IDE mit Haltepunkten, aber bei der Programmierung eins MC geht es > nur so. Mittlerweile kann man die meisten Mikrocontroller mit Haltepunkten debuggen. Nur nicht in der Arduino Welt. Aber printf() ist auch hilfreich. Ich entwickle kein Projekt mehr ohne eine entsprechende Ausgabeschnittstelle. Den einen Pin gönne ich mir.
Schlaumaier schrieb: > Xaver M. schrieb: >> Case 8: also der Nachfolgende, wird mit fast identischem Text nicht >> angezeigt. > > Wird Case 8 überhaupt ausgelöst. ??? Variable für Wert von CASE > überprüfen. > > Du kannst ja Spass halber den Code von Case 7 nach Case 8 kopieren bzw. > beide Case einfach vertauschen. Dann weißt du ob Case 8 ausgelöst wird. > Habe ich schon geschrieben, ja, der case wird ausgelöst, auch weil ich das am Seriellen Monitor sehe, wo ich die entsprechende Temperaturänderung über die Taster sehe, nur das auf dem Bildschirm das vorletzte Menü mit der Temperaturerhöhung angezeigt wird. Beim Austauschen der Cases bleibt die Auswirkung die Gleiche. An dem Programm schreibe ich schon etwas länger rum und teste die entsprechenden neuen programmierten Teile und überprüfe entsprechend kritische Variablen am seriellen Monitor. >Also würde ich zuständige Variable "beobachten" nach JEDER Änderung. ja, genau, so mache ich das am Seriellen Monitor wo die Änderungen richtig und erwartunggemäß angezeigt werden. Deshalb habe ich den Oled bzw Bibliothek in verdacht.
Xaver M. schrieb: > Deshalb habe ich den Oled bzw Bibliothek in verdacht. welche und mal eine andere eingesetzt ? Wenn Du die Schuld auf die Library schiebst-dann versuch doch eine andere z.B. U8G2. Auch Dein (angeblich) defektes OLED kannst mit "Hello World" auch damit testen. Ich persönlich glaube nicht,dass es an OLED+Library liegt.
Warum setzt er bei case 8 keinen Breakpoint hin?
Spess53 schrieb: > Hi > >>eine Fehlermeldung "redeclaration char buffer" kommt > > Und warum beseitigst du den Fehler nicht? > > MfG Spess Wäre auch meine Frage. Bei lokaler Variable im case sind Klammern nötig:
1 | case 7: { |
2 | int x; |
3 | …
|
4 | break; |
5 | }
|
Danke für die Beiträge, auch wenn keiner mir wirklich weiter geholfen hat. Schlußendlich habe ich in der ss_oled. gesucht, zumal ich ja vermutet hat, dort meinen Fehler bzw Lösung zu meinem Problem zu finden. Der Entwickler schreibt da: >If you need to print formatted output of numbers, strings, etc, you can do it >like this: > >
1 | char szTemp[32]; |
und wer jetzt etwas hoch scrollt findet bei meinem Code-Schnipsel:
1 | char buffer[32] = {0}; |
und wie ja bereits sagte, habe ich KEINE Ahnung vom Programmieren, dafür
gehen andere Sachen ganz gut, wie das weglassen der " = {0}
Jetzt funzt es.
Danke.
Vielleicht kann und will mich ja jemand erleuchten was für ein
Zusammenhang das ist.
Freundliche Grüße,
X.
Xaver M. schrieb: > char buffer[32] = {0}; > > und wie ja bereits sagte, habe ich KEINE Ahnung vom Programmieren, dafür > gehen andere Sachen ganz gut, wie das weglassen der " = {0} Naja der Befehl legt die Zeichen-Variable Buffer an, und weißt ihr 0 zu. Ergo ist sie leer. So sehe ich das. Ich habe mir angewöhnt, das nie in einer Befehl zu machen. Der Grund ist, das ich es übersichtlicher finde, es in 2 Zeilen zu machen. Was ich oft mache ist, das in mehre Variablen gleichen Typ in einer Zeile deklariere. Die einzige Ausnahme sind Boolean Variablen. Da müssen die eh ein Zustand haben. Das macht den Code übersichtlicher. Und damit ich den Typ der Variable hinterher noch weiß mach ich je nach Sprache entweder hinter Strings ein $ oder beginne sie alle mit t_. Das hilft mir gewaltig Texte von Zahlen zu unterscheiden. Fakt ist. ICH muss mein Code lesen können.
Xaver M. schrieb: > Vielleicht kann und will mich ja jemand erleuchten was für ein > Zusammenhang das ist. die Variable wird angelegt und gleich initialisiert, das ist hier wichtig weil diese auf dem Stack liegt und der Inhalt sonst undefiniert und vom bisherigen Programmlauf abhängig ist. Höre bitte nicht auf den Schlaumeier. Mit dem weglassen mag es jetz ein gültiges Ergebnis geben, aber das ist dann reiner Zufall bzw. eben von der vorherigen Nutzung des Buffers abhängig. Der Compiler sollte hier eigentlich warnen, aber da haben wir ja wieder das Elend das das in der Arduino IDE nicht per default eingeschaltet ist. Es wird funktionieren wenn der Buffer und die Initialsierung jeweils im case mit Klammern steht:
1 | case 7: { |
2 | char buffer[32] = {0}; |
3 | sprintf(buffer, "%d ",(t1)); |
4 | ...
|
5 | break; |
6 | }
|
da der buffer aber mit sprintf in jedem case initialisiert wird, kann der auch oberhalb des switch-case deklariert werden und die Klammern sind nicht nötig. Schlaumaier schrieb: > Fakt ist. ICH muss mein Code lesen können. ja, eine sehr egoistische Einstellung.
Schlaumeiers Antwort ist selbsterklärend, finde ich, das ich mit "= 0" eine Zuweisung mache ich mir schon klar, die ist doch üblicherweise nicht in geschwungenen Klammern ...? oder? Das der Schlaumeier >seinen< Code lesen können muss sehe ich schon ein, und wenn er allein arbeitet reicht das ja auch, wird nur bei Erklärungen ein bischen dünn. Jedenfalls hat mir dieses Problem SEHR geholfen einer Lösusung näher zu kommen und zunküftig mal a) verschiedene Bibliotheken auszuprobieren b) mal in die entsprechende Referenz und Wiki reinzugucken und c) Code zu L-E-S-E-N, damit meine ich nicht nur mit den Augen abtasten, sondern auch mal ein digitalWrite(Gehirn, HIGH); zu benutzen. Besten Dank, Xaver
Xaver M. schrieb: > die ist doch üblicherweise > nicht in geschwungenen Klammern ...? oder? Das ist neu seit C++ 11 https://en.cppreference.com/w/cpp/language/list_initialization https://en.cppreference.com/w/cpp/language/initialization
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.