Druckbare Version
Hallo,
ich habe einen Code geschrieben, der die Zeit mit einem DCF-Modul auslesen soll. Dieses Modul kommt in einer Alarmanlage zum Einsatz. Die Alarmanlage funktioniert aber nicht wirklich so, wie sie soll. Ich vermute, dass sie irgendwo beim auslesen der Zeit hängen bleibt. Jetzt wollte ich euch mal fragen, ob ihr in meinem Code noch irgendwelche Fehler findet.
Danke
_R2D2
Wo ist denn DEIN Code?Zitat:
... wollte ich euch mal fragen, ob ihr in meinem Code noch irgendwelche Fehler findet.
Gruß Dirk
@Dirk
dcf77.h - als Anhang zum download
Hallo,
es fehlt die int main().
Im Ernst, Fehlerbeschreibung, Controllertype, minimales compilierfähiges Programm fehlen.
Worauf stützt sich deine Vermutung.Zitat:
Ich vermute, dass sie irgendwo beim auslesen der Zeit hängen bleibt.
Wonach soll ich suchen? Weiß der Fuchs, was du noch alles mit der Variable wert anstellst, nur mal als Beispiel.
Ich möchte dir gerne bei deinem Problem helfen, kann es so aber nicht.
Gruß
Jens
Der Fehler wurde von SprinterSB doch schon längst benannt, wenn auch etwas ungewöhnlich und knapp.
Die Funktion GetTime bleibt hier hängen:
weil fertig nicht als volatile deklariert ist.Zitat:
while(!fertig)
{}
Nach der Korrektur dieses Fehlers wird GetTime aber vermutlich immer noch nicht richtig funktionieren, weil auch Fehler volatile sein muss.
(Und vielleicht noch weitere Variablen, denn so genau habe ich es mir nicht angesehen)
Davon abgesehen springt mir noch eine andere Sache ins Auge:
Diese beiden Zeilen sind NOPs, die tun rein gar nichts, schon gar nicht halten sie den Timer an.Zitat:
TIFR |= (0 << ICF1) | (0 << TOV1);
TIMSK |= (0 << TICIE1) | (0 << TOIE1);
Und auch in den Blöcken dieser Form:
steckt ein kapitaler Denkfehler.Zitat:
Zeit.Stunde =
ZeitBits[28]*1+
ZeitBits[29]*2+
ZeitBits[30]*4+
ZeitBits[31]*8+
ZeitBits[32]*10+
ZeitBits[33]*20;
Hallo,
ein fehlendes volatile ist sicher ein Fehler. Führt aber nicht zwingend sondern nur möglich zu einer Fehlfunktion. Die weiteren, von dir aufgeführten Sachen, habe ich mir schon nicht mehr angeschaut. Mein erster Verdacht liegt in den großen Variablentypen und der Verwendung in der ISR bei leichtfertigem Zugriff außerhalb dieser. :mrgreen:
Ist aber alles Spekulation.
Gruß
Jens
Stimmt, nicht zwingend, aber beim GCC mit eingeschalteter Optimierung liegt die Wahrscheinlichkeit, dass "while(!fertig) {}" zu einer Endlosschleife wird, sehr nahe an 100 %. ;-)
Stimmt, man kann ja mit OR keine 1 löschen.Zitat:
Davon abgesehen springt mir noch eine andere Sache ins Auge:
Diese beiden Zeilen sind NOPs, die tun rein gar nichts, schon gar nicht halten sie den Timer an.Zitat:
TIFR |= (0 << ICF1) | (0 << TOV1);
TIMSK |= (0 << TICIE1) | (0 << TOIE1);
So müsste sich der Timer doch beenden lassen.Code:TIMSK ^= (1 << TICIE1);
TIMSK ^= (1 << TOIE1);
Was stimmt den daran nicht? Ich habe mir es so gedacht:Zitat:
Und auch in den Blöcken dieser Form:
steckt ein kapitaler Denkfehler.Zitat:
Zeit.Stunde =
ZeitBits[28]*1+
ZeitBits[29]*2+
ZeitBits[30]*4+
ZeitBits[31]*8+
ZeitBits[32]*10+
ZeitBits[33]*20;
Wenn das Bit an der entsprechenden Position 1 ist, so wird das Produkt 1*X zu Zeit.Stunde addiert.
Danke für eure Hilfe
mfg _R2D2
Ja, wenn beide Bits ganz sicher vorher 1 sind. Sicherer wäre ein auf Null setzen, das nicht vom aktuellen Zustand abhängt:Zitat:
So müsste sich der Timer doch beenden lassen.
TIMSK &= ~((1<<TICIE1) | (1<<TOIE1));
Und welche Wertigkeiten (X) haben die Bits an Position 4 und 5? (Tipp: 10 und 20 sind es jedenfalls nicht)Zitat:
Wenn das Bit an der entsprechenden Position 1 ist, so wird das Produkt 1*X zu Zeit.Stunde addiert.
Hallo,
sowohl die Minuten- als auch die Stundencodierung ist BCD (4 Bit für die Einer- und 2 Bit für die Zehnerstelle, obwohl das eine Verschwendung darstellt...); die Wertigkeiten "10" und "20" sind deshalb schon korrekt.Zitat:
Zitat von sternst
Gruß
Fred
Ups, dass das BCD kodiert sein könnte, habe ich nicht bedacht.
Daher von mir ein großes zu Kreuze kriechendes SORRY!
Eins habe ich jetzt immer noch nicht verstanden: Wann wendet man "volatile" an?
mfg
Hi,
Beim Programmieren von "embededed systems" wird grundsätzlich "volatile" eingesetzt,Zitat:
Zitat von _R2D2
- 1. wenn eine Variable in einer ISR und gleichzeitig in einem anderen Programmteil vorkommt,
2. beim Datenaustausch zwischen mehreren Threads und
2. wenn man auf ein "memory mapped" peripheres Register zugreift.
Dies ist alles mit Beispielen hier erklärt.
MfG
Fred
Ich hatte jetzt Zeit, alles noch mal genau zu testen und dabei ist mir aufgefallen, dass der µC nach dem Aufruf von GetTime nach ca. 14 Sekunden einen Reset macht. Nach diesem Reset fängt das Programm wieder von vorne an, die Variablen werden aber komischerweise nicht gelöscht. Wenn nach dem ersten Reset ein Timer gestartet wird macht der Controller wieder diesen komischen Reset. Ich denke, dass irgendetwas mit der Timersteuerung im Programm nicht stimmt.
Am µC kann es nicht liegen, da es weder mit einem AtMega8, noch mit einem AtMega32 funktioniert.
Stimmt diese Zeile oder kann man den Wert so nicht umrechnen?
Ich habe langsam das Gefühl, dass der AVR-gcc Compiller mit sehr großen Programmen nicht zurecht kommt. Weiß jemand, wo ich die neueste Version finde (Ich habe schon danach gegoogelt, finde aber nichts)?Code:wert = (ICR1L | (ICR1H << 8)) * (TAKT / (256UL * 65535UL) / 1000UL); //gezählter Wert in ms umrechnen (Takt=3,6864MHz)
mfg
Ich bin schön dumm: Suche ewig lang alles nach diesem Fehler ab, dabei habe ich in dieser Zeile
"SIG_" vergessen. Jetzt macht der µC keinen Reset mehr, aber die Zeit kann ich auch nicht empfangen. Entweder igrendetwas im Programm stimmt nicht, oder das Modul empfängt nichts. Was muss man beachten, um überhaupt ein Signal zu bekommen?Code:SIGNAL(SIG_OVERFLOW1)
mfg
Hast du schon mal eine LED über einen Transistor an den Ausgang des Moduls gehängt. Noch besser wenn du dir einen Ausgang programmierst an den du eine LED hängst, die dir die Eingangsimpulse anzeigt. Die Impulse müssen schön gleichmässig kommen. Den Minutenwechsel kann man durch die größere Pause erkennen.
Das Modul mit Antenne sollte schon min. 20cm von µC und LCD entfernt sein.
Die Ausrichtung zum Sender sollte auch stimmen.
Das Modul funktioniert, ich habe eine LED an den DATA Ausgang gehängt und diese wird regelmäßsig heller und dunkler. Also muss der Fehler im Programm sein.
Setz dir trotzdem auf einen freien Ausgang deines Kontroller eine LED, diesen Ausgang kannst du dann Schritt für Schritt in dein Programm einbauen und so kontrollieren wie weit es funktioniert.
Wenn du den Fehler im Programm vermutest und dir von uns Hilfe bei der Fehlersuche erhoffst, wäre es dann nicht angebracht, mal die aktuelle Version des Sourcecode zu posten?Zitat:
Zitat von _R2D2
OK, hier ist mal die überarbeitete Version der Datei.
Ich habe jetzt doch ein kleines Programm geschrieben, das eine LED einschällt, wenn das Signal kommt. Dieses Programm funktioniert auch. Die LED blinkt ziemlich gleichmäßig.
Ich habe das Gefühl, dass der Timer1 ein bisschen zu schnell zählt, da der Overflow-Interrupt ziemlich schnell hinter einander erfolgt. Mein Verdacht liegt immer noch in dieser Zeile (obwohl ich es mit dem Taschenrechner nachgerechnet habe und der Timer erst alle 14,4 Sekunden überlaufen dürfte):
mfgCode:wert = (ICR1 * (TAKT / (256UL * 65535UL) / 1000UL)); //gezählter Wert in ms umrechnen (Takt=3,6864MHz)
Poste mal, wie du das ausrechnest.Zitat:
der Timer erst alle 14,4 Sekunden überlaufen dürfte
Bei 3,6864 MHz und einem Teiler von 256 komme ich auf einen Overflow alle 4,55 Sekunden.
Was hat das 65536 darin zu suchen? Wenn du eine bestimmte Anzahl Zählertakte in die äquivalente Zeit umrechnen willst, welche Rolle spielt dann, nach wie viel Takten der Zähler überläuft? Ein Takt ist immer gleich lang, egal ob der Zähler nun bei 65535 überläuft, oder niemals. Und auch die Tatsache, dass TAKT im Zähler steht, zeigt, dass die Formel falsch sein muss, denn t = 1 / fZitat:
wert = (ICR1 * (TAKT / (256UL * 65535UL) / 1000UL)); //gezählter Wert in ms umrechnen
Was denn nun, steigende Flanke oder fallende?Code:SIGNAL(SIG_INPUT_CAPTURE1)
{//wird bei steigender Flanke des Signals ausgelöst um die Dauer der Pause zu berechnen
...
TCCR1B |= (1 << ICNC1) | (1 << CS12); //Störunterdrückung ein; fallende Flanke; Taktteiler: 256
Ich habe zwar den Code noch nicht so detailliert analysiert, um dir sagen zu können, was du da genau per Input Capture misst, aber die "Pause" ist es sicher nicht.
Das passt auch nicht, denn wenn wert zwischen 875 und 925 liegt, landest du nicht nur im ersten if, sondern zusätzlich auch im else-Zweig.Code:if((wert>875) && (wert<925))
{
...
}
if((wert>775) && (wert<825))
{
...
}
else
{//keine Übereinstimmung der Pausendauer -> An aktueller Position Fehlermarke (-1) setzen
Stimmt, das habe ich vorher auch bemekt. Aber die Funktion SetTime() liefert bei mir schon nach ca. 6 Sekunden false zurück. Das heist ja, dass der Timer viel zu schnell zählt?!Zitat:
Poste mal, wie du das ausrechnest.
Bei 3,6864 MHz und einem Teiler von 256 komme ich auf einen Overflow alle 4,55 Sekunden.
Wie ich genau auf diese Formel gekommen bin, weiß ich auch nicht mehr. In meinem µC-Buch ist die Berechnung solcher Dinge auch nicht gut erklärt (das Buch ist sicher nicht das beste). Wie würde die Formel richtig lauten?
mfg
Wenn man die Zeile so umändert, müsste es doch funktionieren, da der Wert 65535 in ICR1 4,55sec entspricht. Dann entspricht der Wert 14 1ms.Code:wert=ICR1/14;
Aber es funktioniert immer noch nicht...
mfg
Edit: Ich habe gar nicht bemekt, dass der Thread schon 2 Seiten hat, deswegen habe ich die letzten Beiträge nicht gefunden. :wink:
Aber das mit der Messung der Pausen müsste schon stimmen, da der Interrupt am Ende der Messung, eben bei einer steigenden Flanke ausgelöst wird. Das Bit ICES1 in TCCR1B ist deshalb nicht gesetzt, damit die Messung bei einer fallenden Flanke gestartet wird.
Hallo _R2D2,
Im Prinzip ist es egal, auf welche Flanke man reagiert. In einem meiner DCF-Decoder habe ich auf jede Flanke reagiert und die Zeit zwischen den Flanken gemessen. Wenn das 100 oder 200 ms waren, dann hatte ich die Impulse selbst, bei Werten von 800/900/1800/1900 ms waren es die Pausen. Die braucht man dann für die Decodierung.Zitat:
... das mit der Messung der Pausen müsste schon stimmen, da der
Interrupt am Ende der Messung, eben bei einer steigenden Flanke ausgelöst wird.
Gruß Dirk
Kommt ungefähr hin.Zitat:
Dann entspricht der Wert 14 1ms.
Unter anderem deswegen, weil in ICR1 einfach nicht das drin steht, was du vermutest. (*1)Zitat:
Aber es funktioniert immer noch nicht...
Wenn du ICES1 auf "fallende Flanke" konfigurierst, wieso glaubst du dann, der Interrupt würde bei der steigende Flanke ausgelöst? (*2)Zitat:
Aber das mit der Messung der Pausen müsste schon stimmen, da der Interrupt am Ende der Messung, eben bei einer steigenden Flanke ausgelöst wird. Das Bit ICES1 in TCCR1B ist deshalb nicht gesetzt, damit die Messung bei einer fallenden Flanke gestartet wird.
*1+2: Da ist wohl noch mal ein genaues Studium des Input-Capture-Kapitels im Datenblatt nötig.
Ich habe das Programm jetzt noch einmal überarbeitet. Das mit den Flanken stimmt jetzt. Das Programm schällt jetzt noch eine LED an und aus, wenn das Signal kommt, bzw. nicht kommt. Die LED blinkt auch regelmäßig. Aber die einzelnen Bits kann ich immer noch nicht auslesen...
Ich finde trotz gründlichem Überprüfen einfach keinen Fehler mehr. :(
mfg
Setz dir einmal eine Led dort in dein Programm wo du den Start erkennst.
Wo schaltest du zwischen fallender und steigender Flanke um?
Es fehlt mir die main() und warum schreibst du das in die dcf77.h und nicht in dcf77.c
Was meinst du damit? Wo soll denn ich umschalten?Zitat:
Wo schaltest du zwischen fallender und steigender Flanke um?
In main() wird was das dcf-Modul betrifft nur als erstes dcf_init() und dann SetTime() aufgerufen.
mfg
Wenn du die Zeit zwischen zwei gleichen Flanken misst (egal ob steigende oder fallende), wie willst du dann entscheiden, ob es eine 0 oder 1 war?Zitat:
Was meinst du damit? Wo soll denn ich umschalten?
PS: Das würde zwar auch gehen, aber man müsste dann auch den Zustand des vorigen Bits mit in die Entscheidung einbeziehen.
Ich habe mal so eine Erkennung gebastelt, da habe ich auf die fallede Flanke gewartet, dann den Timer gestartet, auf steigende Flanke umgeschalten, bei erkennen den Timer gestoppt, ausgelesen und wieder auf fallende Flanke umgestellt für das nächste Bit.
Das erklärt nicht warum du den Code in die dcf.h und nicht dcf.c schreibst.Zitat:
In main() wird was das dcf-Modul betrifft nur als erstes dcf_init() und dann SetTime() aufgerufen.
Das mache ich schon lange so, weil ich keine zwei Dateien (dcf77.h und dcf77.c) haben möchte. In .c-Dateien kommen bei mir nur die Hauptprogramme und die dazugehörigen Unterprogrammen. Aber das ist doch für die Funktion des Programms egal.Zitat:
Das erklärt nicht warum du den Code in die dcf.h und nicht dcf.c schreibst.
Ich habe das Signal jetzt mal aufgezeichnet, und dabei ist mir aufgefallen, dass sehr viele kleine Störungen (meist direkt vor den eigentlichen Impulsen) auftreten. Dann ist es ja kein Wunder, dass das Auslesen der Zeit nicht funktioniert. Woran können diese Störungen liegen? An anderen Geräten, die in der Nähe sind und den Empfang stören könnten kann es nicht liegen, da ich es auch schon drausen auf dem Balkon probiert habe.
Ich invertiere und verstärke die Signale der DATA-Leitung sonst nur mit einem einfachen Transistor (BC 547C). (DATA an Basis; Pulldown an Basis (R mit 40kOhm); Kollektor an ICP1 (interner Pullup im µC ist aktiviert); Emitter an GND) Ist der Pulldown Widerstand möglicherweise zu groß?
Als Anhang habe ich die Aufzeichnung von einer Minute und von den ersten 10 Sekunden der Minute angehängt. Dort kann man die Störungen gut sehen.
mfg
_R2D2
Wenn der Ausgang des DCF-Moduls Open-Collektor ist dann glaube ich nicht das deine Beschaltung richtig ist.
Siehe mal hier: http://www.mikrocontroller.net/artic...wecker_mit_AVR
Doch, meine Beschaltung stimmt schon, da der µC die Impulse ja erkennt. Nur die Störungen stören eben das Empfangen.Zitat:
Wenn der Ausgang des DCF-Moduls Open-Collektor ist dann glaube ich nicht das deine Beschaltung richtig ist.
Siehe mal hier: http://www.mikrocontroller.net/artic...wecker_mit_AVR
Es haben aber noch andere das Problem mit den Störungen: http://www.mikrocontroller.net/topic/97295
bei genauerem Betrachten erkennt man nämlich an meinen Aufzeichnungen auch diesen Sägezahn bei den Flanken und diese Störimpulse, die vor dem eigentlichen Impulsen auftreten. Hat jemand eine Idee, wie ich den Eingang des µCs ohne großen Aufwand entsprechend entprellen kann (möglichst mit der Software, damit ich auf meine schon volle Platine nicht noch mehr Bauteile löten muss)?
mfg
_R2D2