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
Disclaimer: none. Sue me.
Wo ist denn DEIN Code?... 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.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.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.TIFR |= (0 << ICF1) | (0 << TOV1);
TIMSK |= (0 << TICIE1) | (0 << TOIE1);
Und auch in den Blöcken dieser Form:
steckt ein kapitaler Denkfehler.Zeit.Stunde =
ZeitBits[28]*1+
ZeitBits[29]*2+
ZeitBits[30]*4+
ZeitBits[31]*8+
ZeitBits[32]*10+
ZeitBits[33]*20;
MfG
Stefan
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.
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 %.
MfG
Stefan
Stimmt, man kann ja mit OR keine 1 löschen.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.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:Und auch in den Blöcken dieser Form:
steckt ein kapitaler Denkfehler.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: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)Wenn das Bit an der entsprechenden Position 1 ist, so wird das Produkt 1*X zu Zeit.Stunde addiert.
MfG
Stefan
Lesezeichen