Ich brüte aktuell über einem LCD-Uhrenprojekt als Vorbereitung für eine
Word-Clock.
Derzeit werte ich ein DCF77-Modul aus, stelle damit regelmäßig die
DS3132 RTC und habe auch noch einen DHT22-Temperatur/Feuchtigkeitssensor
angeschlossen. Daneben nutze ich auch 2 JQ6500 MP3-Soundmodule zum
Abspielen von Glockenschlägen und Uhrenticken.
Jetzt wollte ich noch eine Kalenderfunktionalität einbauen. Dazu wird im
Sketch am Anfang eine Struktur definiert und einmal am Tag geprüft, ob
relevante Ereignisse vorliegen. Diese werden dann abwechselnd auf dem
LCD-Display ausgegeben.
Die Kalenderdaten liegen im PROGMEM, um Variablenspeicher zu sparen.
Sobald ich die Einleseroutine mit kompiliere, fkt. der DCF-Emfang nicht
mehr und bei der Soundausgabe gibt es auch Probleme. Gerade als ob im
Speicher etwas durcheinander gekommen wäre.
Was mache ich hier falsch? Kann man den PROGMEM-Speicher so mit memcpy_P
() einlesen? Irgendwo ein ', ", & etc. vergessen?
Hier die Struktur:
Martin schrieb:> Was mache ich hier falsch?
Erstelle ein Minimal-Programm welches den Fehler repoduziert bzw.
repoduzierbar macht und poste es hier.
Dann kann man weiter sehen.
--> Längeren Sourcecode nicht im Text einfügen,
--> sondern als Dateianhang.
Du siehst schon an der Re-Formatierung deiner Source-Fragmente
dass es so wie es jetzt ist, eine Qual ist, abgesehen vom
fehlenden Gesamt-Programm.
Beim Erstellen der Minimalversion ist mit aufgefallen, dass der
Kalenderabfrageteil viel zu oft aufgerufen wird und vorher immer wieder
1
DateTimeRTC_Zeit=rtc.now();
zur Übernahme der Real-Time-Clock-Zeit aufgerufen wurde.
Habe nun den Block verschoben, dass er nur jede Sekunde aufgerufen wird.
Dort konnte ich mir das DateTime sparen, da RTC_Zeit schon gesetzt war.
Nun funktioniert´s, aber warum, kann ich nicht sagen ...
Komisch war vorher nur: Compiler nölt nicht, Prg. macht trotzdem
seltsame Dinge ;-)
@EAF: Mit pgm_read und Konsorten ist es mir nicht gelungen, den Text
einzulesen. Da sitzt das Problem ws. wieder 80 cm vor dem Bildschirm ...
Martin schrieb:> Mit pgm_read und Konsorten ist es mir nicht gelungen, den Text> einzulesen.
Oft vergisst man dabei dass pgm_read_byte(..) (als Beispiel)
ein Argument vom Datentyp PGM_P verlangt, also einen Pointer
auf Daten im Flash. Mit normalen Pointer auf einen String im
RAM funktioniert das nicht.
jo mei schrieb:> Oft vergisst man dabei dass pgm_read_byte(..) (als Beispiel)> ein Argument vom Datentyp PGM_P verlangt, also einen Pointer> auf Daten im Flash. Mit normalen Pointer auf einen String im> RAM funktioniert das nicht.
Gerne wird vergessen/unterschlagen, dass das Arduino Print, welches
seine Eigenschaften an Serial, Wire, LCD und viele weitere vererbt,
schon von hause aus Progmem Strings lesen und ausgeben kann.
Es macht also Null Komma gar keinen Sinn, Strings aus dem Progmem zu
lesen, wenn man sie unverändert ausgeben(printen) möchte.
Martin schrieb:> Nun funktioniert´s, aber warum, kann ich nicht sagen ...>> Komisch war vorher nur: Compiler nölt nicht, Prg. macht trotzdem> seltsame Dinge ;-)
Spekulation: Das Timing für den DCF77-Empfang reicht nicht, da das
sonstige Programm zuviel Verarbeitungszeit verbraucht. Das merkt der
Compiler natürlich nicht...
Da das DCF77-Signal ja recht langsam ist (1 Bit pro Sekunde) und im
Sketch selbst nicht so wahnsinnig viel passiert, sollte das Timing schon
passen. Ich verwende auch keine delays(); alles wird brav über millis()
abgefackelt.
Evtl. werden Timer oder Interrupts von den libraries parallel genutzt,
das muss ich gelegentlich noch prüfen. Wenn dem so wäre, müßte es jedoch
öfter Fehler geben.
Werde berichten.