mikrocontroller.net

Forum: Projekte & Code DCF-Uhr, Sonnenstand, TWI-Port, Alarmfunktion für m8 in C


Autor: Michael S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

zum neuen Jahr eine neue DCF77-Uhr.
Ok - nicht der absolute Innovationsschub, aber einige Features habe ich 
noch an die Uhr drangebastelt (bis der Flash voll war):
- Die Uhr führt eine Plausibilätsprüfung durch und arbeitet auch ohne
  DCF-Signal (nachdem mindestens 1x erfolgreich synchronisiert wurde).
- Die Uhr steuert ein 4-Zeilen-LCD.
  Man kann aufs LCD aber auch verzichten und den Chip in eine finstre
  Box einsperren.
  Dann bleibt sogar wieder Platz für neue Ideen.
  (Die Antwort auf die Frage "Wie liest man dann die Zeit ab?" folgt
  gleich.)
- Die Uhr berechnet den aktuellen Sonnenstand sowie
  Sonnenauf-/untergang.
- Es sind zeitgesteuerte Schaltfunktionen eingebaut:
  zu definierbaren Uhrzeiten können Portpins ein-/ausgeschaltet oder
  getoggled werden.
- Verwendet wird ein mega8, aber sein SRAM ist für diese Aufgabe weit
  überdimensioniert.
  Daher stellt die Uhr als TWI-Slave 768 SRAM Byte zur freien Verwendung
  von aussen bereit.
- Alle relevanten Daten (uncodiertes DCF-Signal, Uhrzeit, UTC-Zeit,
  Sonnenstandsdaten) können via TWI ausgelesen werden.
  Schreiben geht auch - erscheint aber nicht sinnvoll.
  Die Alarm-/Schaltfunktionen können per TWI gesetzt und ausgelesen 
werden.
  Gelesen werden kann hoffentlich auch der Quellcode, ich habe mich um 
eine
  Dokumentation bemüht.

Vielleicht interessiert's ja doch ?

mfg

Michael S.

Autor: Peter Grzeschik (p-e-t-e-r)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michael,
ist ne sehr interessante Sache. Zu den Schaltzeiten wäre eine 
Ausnahmeregelung an Feiertagen und/oder Wochenenden wünschenswert. Sehr 
effiziente Codeschnipsel zu diesem Thema könnte ich beisteuern, aber 
nicht implementieren, da ich nur in BASIC programmiere.
Falls Du Interesse hast, melde Dich einfach mal. Am besten direkt per 
Email über den Link (p-e-t-e-r) oben hinter dem Namen.
Gruß, Peter

Autor: Michael S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

stell doch einfach mal hier rein.

Michael S.

Autor: Peter Grzeschik (p-e-t-e-r)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Michael,
ich habe die Sache noch in Arbeit, ist aber fast fertig. Außerdem habe 
ich alles in einem BASIC-Dialekt geschrieben der eigentlich nicht recht 
hier ins Forum passt. Ich habe bisher nur mit C-Control von Conrad 
gearbeitet, erwäge aber einen einstieg in AVR. Der Code ( C-Basic ) 
lässt sich also erst nach Anpassung in BASCom bzw. in C oder ASM 
verwenden, daher dachte ich wir sollten das erst mal unter uns direkt 
abhandeln. Später können wir das dann auch hier veröffentlichen.
Zu klären wäre u.A. noch mit wievielen Stellen das Jahr verrechnet 
werden kann. Bei zwei Stellen kann ja nur von 2000 bis 2099 rechnen. 
Vierstellig würde mein Code jedoch 1900 - 2199 abdecken. ( Natürlich mit 
allen Schaltjahren und Ausnahmen ) Das DCF-Protokoll liefert aber nur 
Zwei Stellen, oder ?
Für die Berechnung der Feiertage werden übrigens in BASIC NUR DREI 8-Bit 
Variablen an Speicher gebraucht.
Gruß, Peter

Autor: Michael S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

> Außerdem habe ich alles in einem BASIC-Dialekt geschrieben der
> eigentlich nicht recht hier ins Forum passt.
Nicht ohne Grund.
Wer mal mit einem AVR und Bascom oder AVR-gcc oder Assembler gearbeitet
hat, der wird eine C-Control und sein/ihr Basic nicht vermissen.
Aus Unkenntnis habe ich leider vor einigen Jahren auch diesen Umweg 
gemacht.

> Zu klären wäre u.A. noch mit wievielen Stellen das Jahr verrechnet
> werden kann.
Nun, ein Byte = 0 .. 255.
Das DCF-Signal transportiert 80 + 40 + 20 + 10 + 8 + 4 + 2 + 1 = ?
Aber ob es diesen Veteranen noch so lange geben wird, das wage
ich zu bezweifeln.

> Für die Berechnung der Feiertage werden übrigens in BASIC NUR
> DREI 8-Bit Variablen an Speicher gebraucht.
3 x 8Bit = 3 Byte ? Das ist o.k.
Aber an Speicher mangelt es ja nicht wirklich.

Eine Frage habe ich auch.
Welche praktische Anwendung schwebt dir vor, wenn du Schaltzeiten an
Feiertagen definieren willst ?
Was mir dazu nur einfällt:
Alljährlich am Karfreitag um 12.00h die Kirchturmglocken läuten lassen.

Dass man Wochentage bereits definieren kann, das hast du sicherlich 
gesehen?

mfg

Michael S.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Welche praktische Anwendung schwebt dir vor, wenn du Schaltzeiten an
> Feiertagen definieren willst ?

Ich denke umgekehrt wird ein Schuh draus:

Schalte an Wochentagen wenn Werktag, also ausser an Feiertagen

Autor: Michel S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Karl heinz,

> Schalte an Wochentagen wenn Werktag, also ausser an Feiertagen

Diese Problem zu lösen wäre sicherlich ungleich einfacher, als 
bewegliche Feiertage zu bestimmen.
Wie war das da noch mit Ostern ?
Irgendwann vor einem Vollmond - oder danach ...
Und an Ostern koppeln sich dann doch die übrigen Feiertage.

Aber wie ermittelt man den Zeitpunkt des Vollmondes ?
Das ist vermutlich ähnlich aufwändig wie die Ermittlung des 
Sonnenstandes.

Die Formel zur Berechnung des Heiligabend und Tages der Arbeit kommt
möglicherweise ohne Kenntnis der Mondphase aus.


mfg

Michael S.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Michael
> Aus Unkenntnis habe ich leider vor einigen Jahren auch diesen Umweg gemacht.
OK, dann kennst Du das Ding ja wenigstens

> Nun, ein Byte = 0 .. 255.
Das ist nicht so gut, aber ich denke mal die ersten zwei Stellen wird 
man berechnen können. Muss ich mal drüber nachdenken. Sonst ist der 
Kalenderbereich ja doch etwas eingeengt. ( Nur noch gut 90 Jahre, naja, 
mir würde es ja reichen ) Ich müsste halt den Code dann noch mal auf 
Jahr = Zweistellig umstellen. Sollte aber keine Problem sein.

> Aber an Speicher mangelt es ja nicht wirklich.
Nicht bei AVR, aber bei der C-Control. Ich habe noch die alte 1.1er, bei 
der muss man mit 24 Bytes ( = 12 Words ) auskommen.
Außerdem gibt es da glaube ich auch Unterschiede bei den Datentypen. Bei 
mir gibt es keinen Typ "Integer". Zwei Bytes sind bei mir schon ein 
WORD. Allerdings kann ich auf ein Word auch Byteweise und Bitweise 
zugreifen. Deshalb habe ich es so "umständlich" ausgedrückt.

> Eine Frage habe ich auch.
Bei mir geht es um die Steuerung von Rollläden. Die sollen an Feiertagen 
(Optional) erst mit einem Offset hochfahren.
Auch sollte "Nicht öffnen vor" und "Spätesten schließen um" Anwählbar 
sein.
Die Sonnenzeiten haben ja doch eine erhebliche Schwankungsbreite.
Eventuell auch noch Option morgens "Spalt ziehen" vor dem öffnen.
Damit ist auch die Frage von Karl-Heinz beantwortet.

Im Moment denke ich die Uhr und die Steuerung sollten auf zwei Geräte 
verteilt werden, aber das steht noch nicht ganz fest. Das Hauptproblem 
ist eigentlich das Rechnen mit Float-Werten, Winkelfunktionen usw. für 
die Astro-Zeiten. Das kann die C-Control halt nicht.

Gruß, Peter

Autor: Michael S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

> OK, dann kennst Du das Ding ja wenigstens
Deswegen empfehle ich dir auch aus voller Überzeugung, über den
C-Control-Tellerrand hinaus mal andere Welten anzusehen.
Es zahlt sich aus (im wahrsten Sinne des Wortes).

Ich selbst kenne "leider" auch nur die AVR's, aber es ist schon ganz
beachtlich, was man bereits mit einem kleinen Tiny25 anstellen kann.
Und der kostet ca. schlappe 1.50 Eur (natürlich nicht in der Apotheke).

> Das Hauptproblem ist eigentlich das Rechnen mit Float-Werten,
> Winkelfunktionen usw. für die Astro-Zeiten.
> Das kann die C-Control halt nicht.

Diese Probleme wirst du mit anderen Controllern auch haben.
Da muss dann - wenn möglich - ein wenig getrickst werden.
Oder du arbeitest in einer Umgebung, in der Bibliotheken diese
Berechnungen notfalls bereitstellen (das kostet aber natürlich richtig 
Speicherplatz ...).
Mit dem C++ Basic bist du aber schon wieder gekniffen.

Kopf hoch und durch ...

Michael S.

Autor: Uwe Berger (boerge) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MoinMoin,


> Aber wie ermittelt man den Zeitpunkt des Vollmondes ?
> Das ist vermutlich ähnlich aufwändig wie die Ermittlung des
> Sonnenstandes.
>
nein, ganz einfach! Sämtliche (kirchliche) Feiertage werden relativ von 
Ostersonntag berechnet. Problem ist also Ostersonntag zu ermitteln. Und 
da hat sich Herr Gauß was einfallen lassen: die Gaußsche Osterformel, 
die relativ einfach zu implementieren ist...

http://de.wikipedia.org/wiki/Gau%C3%9Fsche_Osterformel

Grüße Uwe

Autor: Michael S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Uwe Berger,

danke für den Tipp.

Manche Probleme lösen sich ja doch deutlich einfacher als man denkt.
Wenn man denkt - bzw. goggelt.

mfg

Michael S.

Autor: Michael S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter und Karl heinz,

schönen Dank für eure Anregungen, hier meine skizzenhaften Lösungen:

zum Vorschlag von Karl heinz (Wochentage/Wochenende zu unterscheiden):

Ist sicherlich sehr nützlich - und einfach zu implementieren.
Anstatt den 'day of week' mit einer Ziffer 1..7 zu kodieren, wird
einfach für jeden Wochentag ein Bit spendiert:

Montag = Bit.0 .. Sonntag = Bit.6

Durch glückliche Fügung bleibt das 7.Bit frei (das wird ja verwendet, um
anzuzeigen, dass dieses Datum als Filter herangezogen werden soll).

Für diejenigen Tage, für die der Filter TRUE liefern soll, wird in
der Maske ein Bit gesetzt:
0x60 liefert TRUE am Wochenende (+ Bit.7 versteht sich)
0x1F liefert TRUE an Wochentagen (dito).
0x10 zeigt an, das nach spätestens 24 Stunden Wochende ist ...

Um Peters Idee mit den Feiertagen umzusetzen:

Im 'day of month' (1..31) sind noch zwei Bit unbenutzt
(Bit.5 , Bit.6).
Wenn man zum Programmstart und von da an jeweils täglich um 00:00
berechnet, ob dieser Tag ein Feiertag ist - und dann das Ergebnis in
Bit.5 (wenn Feiertag) und Bit.6 (wenn nicht Feiertag) schreibt,
dann könnte man diese beiden Bits als Filterbedingung heranziehen:

Als Tagesdatum 0x20 liefert der Filter an jedem Feiertag TRUE.
Als Tagesdatum 0x2F liefert der Filter TRUE an jedem Feiertag,
der das Datum 15 hat.
Als Tagesdatum 0x30 liefert der Filter TRUE an einem Nicht-Feiertag.
Und wenn wir schon dabei sind für die Abergläubischen:
Wenn Tagesdatum 0x0D und DOW 0x10, dann liefert der Filter TRUE
am Freitag, den 13. eines Monats.

Jetzt höre ich von Peter den Einwand:
Wenn meine Rolläden aber am Wochenende ODER an Feiertagen erst
später aufgehen sollen.
Da gibts zunächst ein Problem, weil alle Filter einer Alarmdefinition
über ein logisches UND verknüpft sind.

Aber die Lösung ist auch nicht weit:
Es werden zwei unterschiedliche Alarmdefinitionen für den selben
Schaltausgang definiert, und schon funktioniert alles wie gewünscht:

1. Alarm: Schalter 1 einschalten, wenn Feiertag und 08.00h
2. Alarm: Schalter 1 einschalten, wenn Wochenden und 08.00h

Jetzt müsste Peter nur noch seinen Rechenweg für die Feiertage ins Netz 
stellen ...
Und irgendwer alles zusammenfügen.
Aber interessiert das hier überhaupt jemanden ?


mfg

Michael S.

PS. an Peter: $SIM in Bascom könnte den lahmen Debugger auf Trab 
bringen.

Autor: Werner B. (werner-b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt braucht man nur noch eine Formel welche die Feiertagsregelungen 
der einzelnen Bundesländer berücksichtigt. In Bayern (und Sachsen ?) 
muss natürlich auch nach "überwiegend katholische / überwiegend 
evangelische Bevölkerung" anhand der GPS-Koodinaten unterschieden 
werden.

Schade dass Herr Gauss schon nicht mehr unter uns weilt :-((

;-)  Werner

Autor: Michael S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter

> Warum für jeden Tag ein Bit spendieren, ein Bit für "Wochenende" und
> eins "Feiertag" reicht doch völlig aus.
Da die Bits bezahlt sind, kann man sie ja auch benutzen.
Und eine Selektion nach Wochentagen ist ja nicht schädlich.
Wäre ich z.B. Friseur, dann hätte ich am Montag noch Wochenende ...

> Einmal am Tag testest Du, wie Du auch schon sagtest, jeweils auf
> Wochenende und Feiertag.
Die Wochentage (und damit das Wochenden) sind der Uhr immer bekannt.

> Idealer Weise spendiert man noch zwei Schalter mit denen man die Option
> für Wochenende und/oder Feiertag unabhängig ein- und ausschalten kann.
Richtig.
Denn Feiertage fallen glücklicherweise nicht immer auf ein Wochenende.

Den Rest schaue ich mir später an.
Leider ist mein Wochenende nämlich vorüber.

mfg

Michael S.

Autor: Peter Grzeschik (p-e-t-e-r)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Michael

> Die Wochentage (und damit das Wochende) sind der Uhr immer bekannt.

Das ist auch mir bekannt. Ist sogar bei C-Control so ;-).
( Unglaublich aber wahr ist aber das die C-Control den DOW von 0 .. 7 
zählt. Die hat also eine 8-Tage Woche )

Aber der Controller weiß nicht das es sich um ein Wochenende handelt 
wenn er der DOW = 0 vorliegen hat. Also muss der DOW von heute mit einer 
"Maske" verglichen werden. ( Ist DOW von heute 6 oder 0, dann ist 
Wochenende )
Nichts anderes mache ich ja in meinem Code. Ich frage den von System 
bereitgestellten DOW ab und prüfe auf Null oder Sechs.
Hast Du vermutlich in der kürze der Zeit nicht gesehen.

Die Idee mit dem Friseurwochenende von So.- Mo. hat allerdings was für 
sich. Es gibt sicher noch mehr Berufsgruppen die kein "normales" 
Wochenende haben.

> Da die Bits bezahlt sind, kann man sie ja auch benutzen.

Klar, solange man noch genug davon hat ist das OK.
Ich, als geplagter C-Controller, muss da leider anders denken. Meine 
bezahlten Bytes beschränken sich auf nur 24 Stück. ( Den Stückpreis trau 
ich mich erst gar nicht zu nennen )
Daher muss ab und an auch "unsauber" programmiert werden.
( Siehe Variablenüberschneidung. Das ist bei mir leider Alltag )
Auch das einzeilige "IF" kann einen manchmal zur Verzweiflung bringen. 
Ist halt so.

Also dann bis zum nächsten mal.

Gruß, Peter

Autor: wborck (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

im dcf_77.c steht folgendes:
// PD.2/3  INT0, INT1   // hier wird die Uhr angeschlossen

Pin-Belegung meines DCF77-Moduls.
VDD    Betriebsspannung
GND    Masse
DATA   DCF-Ausgang
PON    Power On/Down

Mir ist nicht ganz klar, was ich an INT0 und INT1 anschließen soll. Kann 
mir jemand auf die Sprünge helfen?

Danke und Grüße,
wborck

Autor: Michael S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo ebenfalls,



beide INT's werden genutzt, der eine reagiert auf eine rising edge, der 
andere auf eine falling edge.

Daher müssen beide INT's mit dem Signalausgang des DCF-Moduls verbunden 
werden.

Oder anders formuliert: INT0 und INT1 werden kurzgeschlossen - und einer 
von beidem mit dem DCF-Modul verbunden.



Michael S.

Autor: wborck (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,

hab´ mir schon gedacht, dass das so hingehört aber sicher ist sicher...

Das DCF77 habe ich an mein STK500 angeschlossen. Leider kommt die 
Verarbeitung an folgender Abfrage nicht vorbei:
------------------------------------------
while (!(flag & (1<<DCF_MINUTE))); // solange warten, bis das 
Minutenflag gesetzt ist
------------------------------------------

Vor der Abfrage setze ich eine LED auf on und danach auf off. LED bleibt 
an, so dass die Verarbeitung in der While-Schleife hängt.


Laut dcf_77.c wird ein Quarz benötigt:
// PB.6/7 XTAL  // der Quarz benötigt zwei Pin

Leider habe ich keinen zur Hand, geht´s denn nicht ohne bzw. mit dem 
internen?

Grüße,
wborck

Autor: Michael S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo wborck,

wenn die Uhr auch ohne DCF-Signal einigermaßen korrekt mitlaufen soll, 
dann ist ein XTAL schon notwendig.
Man kann zwar an der OSCCAL-Schraube drehen und den RC-Oszillator 
versuchen zu kalibrieren ...

Aber eine zuverlässige Uhr wird das dann eher nicht werden.

Michael S.

Autor: wborck (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,

ja, das ist mir schon bewusst, wundere mich aber, dass bei mir gar 
nichts geht.

Ich werde erstmal ein wenig rumexpimentieren und hoffe, ich finde den 
Weg... :-)

Grüße,
wborck

Autor: Michael S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo allerseits,

nachfolgend einige Überarbeitungen der DCF77-Uhr, die entstanden sind,
nachdem ich das Programm für eine eigene Anwendung praktisch einsetzen
wollte (die Version aus der Weihnachtszeit war ‘just for fun’ 
entstanden).

- Die grundlegende Funktionalität der DCF-77 Uhr und der Sonnenstands-
  berechnung ist unverändert.
- Es werden nun 63 Definitionen für Schaltzeitpunkte berücksichtigt.
- Diese Definitionen können im Eeprom resetfest abgelegt werden.
- Zusätzliche Definitionen können leicht nachgerüstet
  (aber nicht im Eeprom gesichert) werden.
- Das TWI-Modul kann als Slave oder als Master agieren.
- Es sind 70 "Schalt-"Pins adressierbar
  (davon 6 am Controller, der Rest auf bis zu 8 TWI-Portexpandern).
- Anstelle von Schaltaktionen können zeitgesteuert Kommandos an
  TWI-Slaves versendet werden.
- Die globalen Daten sind nun komplett in einem 2-dimensionalen Array
  abgelegt und per Pointer/Index adressierbar.
- Alle relevanten globalen Programmdaten (Zeiten und Schaltdefinitionen)
  können via TWI gelesen und geschrieben werden.

Zusätzliche Schnörkel:
alle 15 Minuten wird ein Zeitsignal an einen Slave geschickt, der dann
wie eine klassiche Uhr akustische Signale aussenden kann.
Bei Sonnenuntergang/Sonnenaufgang wird ein Portpin gesetzt/gelöscht.
Eine ausführlichere Beschreibung findet sich in der beigefügten Readme.
Und der Programmcode ist auch dokumentiert.

Michael S.

Autor: Horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe mal in sun.c sun_calc(void){} eingesetzt (das rechnet natürlich 
nichts und führt wohl zu einer Endlos-Schleife bei der 
Sonnenaufganngsbestimmung) und schon wurden aus 9706 Byte Flash 7700 und 
völlig ohne die Sonnenberechnung 5300.

Was mich so verwundert ist die Tatsache, dass dies soviel ausmacht 
(sin/cos/atan/asin Rechnereien) von sun_calc, denn der Quelltext ist am 
Ende nur 1276 Byte durch sun.c -> sun.lst belegt, der Rest von 3130 Byte 
wohl durch die Fliesskomma-Bibliotheken.
Könnte man nicht eine Tabelle für den jeweiligen Standort berechnen, die 
Jahre wiederholen sich ja, sodass man mit einer Abweichungstabelle und 
ohne die Winkelfunktionen auskäme?

Gruß Horst
P.S.
Man kommt in sun_calc auch mit 5 statt 20 double Variablen aus, wenn man 
nur die zur Zeit nötigen nutzt das spart zusammen mit dem direkten 
Einsetzen von julian_day() und dezimal_day() 222 Byte, aber eben nicht 
mehr :-(

Autor: Michael S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ebenfalls hallo,

auch wenn der Quelltext schlank aussieht, die trigonometrischen 
Funktionen sind natürlich nicht das, was ein 8-Bit-Controller am 
liebsten rechnet.
Versuch doch mal, nur mittels Addition und Subtraktion einen Sinus zu 
berechnen.

Das wird ein langer Rechenweg. Und die kostet entsprechend viel 
Speicher.
Aber auf einem mega168 ist ausreichend davon vorhanden.

Tabellen sind  unflexibel, weil sie immer nur für einen Standort korrekt 
sind. Und Speicher kosten sie auch.

Noch eine Anmerkung zum letzten Quellcode.
Bevor ich den ins Netz gestellt habe - hatte noch mal eben schnell einen 
Watchdog eingebaut.
In der Annahme, dass er nur nützlich sein kann.
Leider bereitet er aber Probleme, die Uhr hängt sich manchmal auf und 
reagiert nicht einmal mehr auf einen RESET.
Den Fehler habe ich bislang nicht gefunden (aber auch nicht ernsthaft 
gesucht) - ich habe den Wachhund einfach entlassen.

Michael S.

Autor: Horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich finde die Verwendung einer ortsbezogenen Tabelle nicht schlecht, da 
ich nicht mit dem Kollektor auf Reisen gehe ;-) und die Genauigkleit der 
von Dir verwendeten Formel mit 0.01 Grad für die nächsten 40 Jahre 
http://de.wikipedia.org/wiki/Sonnenstand muss ich ja nicht unbedingt 
einhalten.
Bei Verwendung als Reisewecker müßte man ja auch die Koordinaten per GPS 
einlesen können.

Ich habe eine Frage bezüglcig togglen.
Wenn ich einen Modus 3 (umschalten) -Alarm setze, beim dem die Minute 
durch setzen des Bit7 nicht berücksichtigt werden, dann schaltet der 
entsprechend Ausgang nun jede Minute um, oder wie oder was?
Ich dachte zuerst klasse, für eine Stunde einschalten und schaltet sich 
selber aus, aber dem ist nicht so und ist auch viel zu unflexibel.
Also muss ich zwei Plätze belegen, einer der einschaltet und einen der 
diesen später wieder ausschaltet.
Eine dumme Frage, wozu brauchen Alarmzeiten das Jahr, man kann doch am 
1.1 eines Jahres ( oh ein Feiertag ) alle beweglichen Feiertage neu 
berechnen, oder will jemand seine Silberhochzeit nicht verpassen 
(Hochzeitstag ist jedes Jahr...) eine gespartes Byte bringt doch was.
Ich denke immer noch an sowas wie 03:17 Uhr Waschmaschine ein, 155 min 
Laufzeit. Dann wäre die 155 im jetzigem Jahr-Byte eine Laufzeit in 
Minuten.
In dem einfach dieser Alarm den Schaltbefehl sendet, sich selbst auf die 
die neue Alarm Zeit (+155 min) einstellt und nach Ablauf von dieser , 
wieder 155 vorstellt und den Ausgang abschaltet.

Gruß Horst

Autor: Michael S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Horst,

bei konstantem geographischen Standort reicht eine Tabelle sicherlich 
aus.
Auch die Genauigkeit mit 2 Nachkommastellen ist übertrieben, aber sie 
fällt ohne Mehrkosten mit ab.
Der Vorteil der Nachkommastellen ist, dass man bei jedem Minutenwechsel 
an der Veränderung der Anzeige erkennen kann, dass das Programm 
arbeitet.
Und der Vorteil der Berechnung in einer Funktion ist, das nicht jeder 
Anwender (sofern es mehr als einen gibt) eine Tabelle für seinen 
Standort erstellen muss.
Der Nachteil ist der Speicherbedarf.

Was willst du bei Verwendung als Reisewecker mit die GPS-Koordinaten 
anfangen, wenn du sie (die Koordinaten) nicht an eine Funktion zur 
Berechnung des Sonnenstandes weitergeben kannst ?

Zur Logik des Schaltens:
Wenn mindestens EINE der gesetzten Bedingungen erfüllt ist, dann wird 
ein Schaltvorgang (ein/aus/toggle) ausgelöst.
Wenn du als einzige Bedingung "alle Wochentage" definierst, dann ist 
diese Bedingung zu jeder Minute erfüllt und es wird zu jedem 
Minutenanfang geschaltet.
Wenn du stündlich zu einer bestimmten Zeit umschalten willst, dann legst 
die NUR die gewünschte Minute fest - und als Modus "toogle".
Nun wird genau dann getoggelt, wenn die angegebene Minute mit der 
Uhrzeit übereinstimmt, also jede Stunde einmal.

Ob man das Jahr als Schaltbedingung benötigt, das ist in der Tat 
unwahrscheinlich.
Da die im Hintergrund stehende Funktion in einer Schleife arbeitet, ist 
es aber völlig egal, ob sie 7 oder 8 Bedingungen abfragt.
Im Zweifelsfall wähle ich in solchen Fällen die flexiblere Lösung.
Vielleicht will ja wirklich jemand an seine Goldenen Hochzeit erinnert 
werden.

mfg

Michael S.

Autor: Denny S. (nightstorm99)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Bastel gerade mit deinem Programm ein wenig rum.
Was muss ich hier vertauschen damit ich ein Invertiertes Signal 
auswerten Kann?
#ifdef M168
EICRA = (1<<ISC11 | 1<< ISC10 | 1<< ISC01);// Rising INT1, Falling INT0
EIMSK  = (1<<INT1 | 1<< INT0);      // INT0 / INT1_isr enablen
#endif

Danke

Denny

Autor: Michael S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Horst,

ein Lapsus meinerseits:

Zur Logik des Schaltens:
> Wenn mindestens EINE der gesetzten Bedingungen erfüllt ist, dann wird
> ein Schaltvorgang (ein/aus/toggle) ausgelöst.

Das ist natürlich Käse!
Wenn JEDE der GESETZTEN Bedingungen erfüllt ist, dann wird ein 
Schaltvorgang ausgelöst.

Beispiel: gesetzt: 12h 30min
Geschaltet wird wenn GENAU 12h UND 30Minuten!


Hallo Denis S.

weiß ich nicht auswendig, habe kein Handbuch zur Hand,
aber vermutlich:

EICRA = (1<<ISC01 | 1<< ISC11 | 1<< ISC11); (ohne Gewähr)

mfg

Michael S.

Autor: Horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Nur bei einem Reisewecker wäre der Standort variabel und viele 
Alarmzeiten machen dann für mich weniger Sinn.
Mir ist schon klar, dan man die Tabelle auch für jeden Standort auch 
erzeugen lassen muss, was umständlicher ist.Man könnte ja ein javascript 
mit document.write als Text in ein Fenster schreiben.... Ist ja nicht 
wichtig.

Wenn schon soviel seriell genutzt wird, reicht es doch bestimmt noch für 
ein Eeprom mit z.B. 8k-Byte per TWI oder SPI.
Denn 70 Ausgänge mit 63 Schaltzeiten passt nicht wirklich zusammen ;-)
Auf dem ausgelagertem Eeprom könnten ja bis zu 1000 Schaltzeiten 
gespeichert sein, aber man kann es auch noch anders nutzen.
Mir schwebte dann etwas wie in 
http://www.mikrocontroller.net/articles/Soft-PWM vor.
Also eine Liste für die 70 Schaltausgänge und wann diese das nächste Mal 
und im welchem Modus (Byte 7) geschaltet werden sollen, wie Du auch 
beschrieben hast, der letzte, der sich auf diesen Kanal und Schaltzeit 
bezieht gewinnt.
Eigentlich braucht man eine Liste die nach Schaltzeiten aufwärts 
sortiert den Schaltkanal/Modus angibt, aber ich will jeden Kanal ja nur 
einmal vorkommen haben.Dafür reicht ein Bitfeld.
Innerhalb einer Minute kann man sicher aus 1000 Einträgen, den nächsten 
Eintrag für den/die gerade abgearbeiteten Schaltka nal/äle finden.
Damit müsste die CPU auch länger schlafen zu legen sein können.
Die braucht ja jede Sekunde nur einmal die Zeit korrigieren und LCD 
ansteuern und Sonnenstand berechnen und jede Minute, falls nötig,den/die 
jeweiligen Kan-al/äle schalten und nur dann die Tabelle der Einträge 
nach diesen durchsuchen, die zeitlich dahinterliegen.
Das wäre eine üppige Schaltzentrale.Die das eigene Eeprom 
freilässt.Externe Eeprom sind doch datensicherer.Da kann 1,9 Jahre jeden 
Minute einen Speicherplatz ändern statt nur 69 Tage lang.

Gruß Horst

Autor: Denny S. (nightstorm99)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Benutze das DCF-Modul von Conrad und bekomme irgendwie keine Verbindung.
Habe beide Ausgänge probiert und im Display bleibt immer "wait for sync" 
stehen.
Hat einer eine Idee von euch?


Gruß Denny

Autor: Horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

kannst Du denn Spannungen an DCF / *DCF messen, die sich ab und an 
ändern. In einer Minute sollten schon ein paar Änderungen sichtbar sein.
Ist die Antenne quer (orthoganal) zur Richtung Frankfurt/Main 
ausgerichtet?.Ist die Antenne mindestens 1 m weg von jeder 
elektromagnetischen Störung (Computernetzteil,Monitor (Zeilenfrequenz 
50-85 khz), Fernseher ...) Hast Du 20 min Geduld gehabt?

Man kann scheinbar viel Spass mit DCF 77,5 khz haben.

Gruß Horst

Autor: Horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

und überhaupt, passt es nicht hierher..
Suchen:
http://www.mikrocontroller.net/forum/mikrocontroll...

Autor: Adrian Karle (proinovest)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael (Gast),
habe Deinen Beitrag mit gr0ßem Interesse gelesen. Die Idee und die 
Software ist auch gut. Ich habe mich mit Deinem Source intensiv 
beschäftigt und wollte auch mal die Hardwareseite kennenlernen. Hast Du
die Schaltung passend zum Source? Habe versucht den Source passend umzu-
stricken. Sehr Zeitintensiv und bisher gesamt noch nicht gelungen.
Ich habe auch schon DCF77 auf ATMEGA8/16/32 umgesetzt. Dein Source im 
Original einzusetzten und zu testen würde mich reizen.

Melde Dich doch mal - wäre nett.

Gruß
Adrian

Autor: Michael S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Adrian,

eine (aus)gedruckte Schaltung habe ich nicht (nur im Kopf).
Die Schaltung ist aber relativ trivial:
- DCF-Signal an INTO und INT1,
- XTAL wie üblich,
- das LCD wie in lcd.h beschrieben.

Da das Programm mehr als 8Kb benötigt, habe ich zuletzt einen Mega168 
einsetzten müssen.

Zur Software:
Da ich selbst wissen wollte, ob das Programm fehlerfrei schaltet und 
auch Fehler im DCF-Signal gutmütig wegbügelt, habe ich mir im Sommer 
eine Debug-Ausgabe über die RS232-Schnittstelle auf einen USB-Logger 
eingebaut.
Und logge jede Minute die ausgebenene Zeit, das DCF-Signal, ggf. die 
Fehlercodes und die Schaltvorgänge.

Dadurch habe ich noch einige Fehler finden können.

Im Moment laboriere ich am DCF-Empfangsteil.
Versehentlich hatte ich das Gerät zu nahe am Fernseher stehen.
In der Log-Datei konnte ich dann sehen, wie der Empfänger mit Fehler 
zugemüllt wurde - und am Ende die Uhr teilweise aus dem Tritt gerät.
Was nicht sein sollte.
Die Logik des Empfangs und der Neusynchronisation auf das DCF-Signal 
habe ich mehrfach umgestellt - aber zufriedenstellend ist das Ergebnis 
noch nicht. Ich befürchte fast, hier muss ein komplettes Neudesign her.

Da die Resonanz auf meinen Beitrag verhalten war, habe ich die Gemeinde 
mit meinen Programmierübungen nicht weiter belästigen wollen.

mfg

Michael S.

Autor: proinovest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,
da ich noch Anfänger bei C, WINAVR und Studio 4 bin,
habe ich noch ein paar Fragen:

1. Es sind *.c Dateien vorhanden (DCF77, Sun, etc.)
2. Es sind *.h Dateien vorhanden (sun.h, etc.)

Wenn ich studio4 BUILD angebe, dann kommt im Ablauf die Fehlermeldung

304: undefined reference to "Sun_display"
Build failed with 57 errors and 0 Warnings

Die Hauptdatei ist DCF77.c

Ich weiß nicht mehr weiter. Kannst Du mir helfen?

Gruß
Adrian

Autor: Michael S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Adrian,

sun_display() wird in main() aus dcf_77.c aufgerufen.
Offensichtlich ist die Funktion sun_display() in main() unbekannt.
Sie steht in sun.c.
Es muss also in main() - bzw. in dcf_77.c  darauf hingewiesen werden,
dass die Funktion extern ist.
Indem man sun_display() in der Liste der Prototypen nennt oder indem man
dasselbe letztlich über das Einbinden einer Headerdatei macht.

Was bei dir genau schiefläuft, das kann ich nicht sagen, da ich aus dem 
Studio nur in Assembler programmiere.
Alles in C mache ich über WINAVR.
Vielleicht versuchst du es auf diesem Weg ?

Da ich gerade einige Dinge im Programm geändert habe:
- Logdateien zur Fehlersuche
- geänderte Empfangslogik wegen Fehler bei gestörtem Empfang
füge ich den aktuellenm Stand einfach mal bei.
Unter WINAVR kompiliert der Code (zumindest heute Vormittag noch)
ohne Murren.

Es ist auch eine Log-Datei vom Sonnabend-Sonntag beigefügt.
Der Wechsel der Sommer- auf die Winterzeit.

Ob dieser Wechsel funktioniert, das interesssierte mich.
Ab 18.00h beginnt das Loggen. Ab 22.00 bis 00:15 ist die Glotze 
eingeschaltet - Empfang fast zu 100% gestört.
Danach wird um 02.00h das A1-Signal (Ankündigung der Sommerzeit) 
empfangen.
Und die Uhrzeit springt nach 02.59 wieder auf 02.00h.
Wie es sein sollte.
Die übrigen Einträge zeigen das Protokoll der Schaltvorgänge.

mfg

Michael S.

Autor: henry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,

für die Synchronisiation von RTC's habe ich Teile deiner Software 
genutzt.
Die Funktion ist ok. Bei Störsignalen kam es bei mir zu folgendem 
Phänomen:
Es wurden mehr DCF-Impulse empfangen als vorhanden sein dürften.
Dabei wird in der Routine "DCF_save_bit" über das vorgesehene Array 
hinaus der Speicher beschrieben und führte zu Programmfehlern.

Vielleicht hilft Dir der Hinweis.

MfG
Henry K

Autor: Michael S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo henry,

das Problem hatte ich noch nicht.
Im Zweifelsfall sollte man den Index der dcf_bits mit 63 UNDIEREN,
dann kann er nie über die Arraygrenzen hinauslaufen.
Und fehlerhaft ist das Signal ja eh schon.

mfg

Michael S.

Autor: henry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,

in der Zwischenzeit habe ich einige Änderungen durchgeführt und das 
Ergebnis ist durchweg positiv.
1. Zwischen Empfangsmodul und MC habe ich einen OP als Komperator mit TP 
geschaltet.
2. Umstellung von Flankenerkennung auf Abtastung des IO-Pins, Abtastrate 
alle 10ms.
Die Erkennung der Impulse und deren Länge erfolgt in einem 1ms Timer, 
der auch die Systemzeiten erzeugt.



Gruß
Henry

Autor: haribo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo henry..du hast also den code so verändert dass die ignal leitung 
des dcf-moduls nicht mehr an into/int1 liegt sondern einfach ein 
beliebiger Einagng des µC auf seinen Pegel abgefragt wird? könntest du 
den veränderten Code posten?

mfg

Autor: Michael S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo allerseits,

eigentlich ist ein DCF-Empfanger/Decodierer ja keine wirklich schwierige 
Aufgabe.
Sofern das DCF-Signal schulbuchmäßig empfangen wird.

Beim Loggen der Uhrzeit musste ich feststellen, dass immer wieder 
absonderliche Fehler im Signal
auftraten - immer dann, wenn der Emfänger in der Nähe eines 
eingeschalteten Fernsehers (Röhrengerät) plaziert war.
Das teilweise fehlerhaft Signal ist manchmal sogar mit blossem Auge an 
der Kontroll-LED des Empfängers wahrnehmbar.

Meine ersten Versuche, das Problem in den Griff zu bekommen, waren 
leider nicht von nachhaltigem Erfolg gekrönt.

Henry hatte den Hinweis gegeben, dass ein Array (in ungünstigen Fällen) 
überlaufen kann.
Auch seinen Hinweis auf einen zwischen Empfänger und mc geschalteten 
Tiefpass habe ich umgesetzt.

Aber erst die Umstellung auf völlig unabhängige Zeitzählung für 
DCF-Signal und interne XTAL-Uhr haben die Probleme beseitigt.
Eine Synchronisation zwischen beiden Signalen findet nur dann noch 
statt, wenn mindestens 3 Minuten lang das DCF-Signal fehlerfrei ist (so 
in der Testphase).
Im Normalbetrieb kann man die Synchronisationsabstände nach Belieben 
erweitern, das ändert aber nichts an der Tatsache, dass die 
Synchronisation im Grundsatz funktionieren muss.

Durch Loggen des DCF-Signals und der Uhrzeiten habe ich das Programm 
getestet, es sind am Ende trotz mehrstündiger TV-Betriebes und ständiger 
Synchronisationsversuche keine Fehler mehr in der ausgegebenen Zeit 
aufgetreten.

Im beigefügten Programmcode habe ich die vermutlich weniger 
interessierenden (aber dafür irritierenden) Schnörkel wie 
Sonnenstandsberechnung und Schaltfunktionen rausgelassen und die 
Funktionalität auf die reine DCF-Uhr beschränkt.

Durch Auskommentieren von #define LCD sollte die Uhr zum Testen auch 
ohne LCD nur mit Debug-Ausgabe über die serielle Schnittstelle laufen.
Sollten sich immer noch Fehler ereignen, dann wäre ein Hinweis 
hilfreich.

mfg

Michael S.

Autor: Michael S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo nocheinmal,

in der letzten Programmversion hatte ich alle Tests mit dem Wert 0 in 
der Konstanten SYNCH_TIME durchgeführt.
Leider hatte ich längere Synchronisationsintervalle nicht ausprobiert - 
und so kommt es, wie es kommen muss ...

Daher als Anlage noch die geänderte dcf.c und dcf.h, damit sind auch 
längere Intervalle einstellbar.

mfg

Michael S.

Autor: Karl-heinz "s." (kahese)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michel,
Bei der letzten Version hast du vergessen die Datei Global.h
mit anzuhängen. da ich nicht so fit bin in WinAVR schaffe ich es nicht 
sie passend zu ändern. Wäre incht schlecht wenn du das gesamte Paket 
noch einmal reinstellst.

Mfg Kalle.

Autor: Michael S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Karl-Heinz,

die global.h habe ich tatsächlich vergessen. Peinlich.
Ich liefere sie hier nach.
Allerdings als Kopie aus meinem vollständigen Projekt.
Hofftenlich gibt damit keine Probleme.

Ansonsten läuft die Uhr jetzt ohne dass in den Logdateien Fehler 
erkennbar sind.

mfg

Michael S.

Autor: Karl-heinz "s." (kahese)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,
Danke für die Global.h, aber jetzt sind neue Probleme aufgetaucht. Das 
Makefile paßt nicht. Ein haufen Syntax Error und unbekannter Befehle. 
Kannst du nicht noch einmal das ganze Paket reinsetzen. Mit welcher 
Version von WinAvr arbeitest du? Datum?

MfG
Kalle.

Autor: Michael S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Karl-Heinz,

hier stelle ich dir den aktuellen Stand meines Programmes rein.
Das ist allerdings das komplette Projekt mit allem Tüdel dran.

Wenn dich nur die DCF-Uhr interessiert, dann musst du allen Schnörkel 
rauswerfen - oder mir einen Hinweis geben.


Michael S.

Autor: Clemens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,

ich bin gerade dabei Deine Uhr nachzubauen. Die Hardware mit dem 
DCF77-Modul, das LCD und der Mega88 spielt bereits. Aus Deiner S/W habe 
ich alles bis auf das LCD rausgeworfen.
Ein Error ist geblieben:
../lcd.c:27:20: global.h: No such file or directory

Wenn ich die Zeile auskommentiere, findet der Compiler einige LCD 
Prozeduren nicht mehr:
../DCF_77.c:777: undefined reference to `lcd_goto_xy'

Dies allerdings nur im unteren Teil des Quellcodes.

Hast Du eine Idee?

Gruß

Clemens

Autor: Michael S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Clemens,

eine spontane Lösung habe ich nicht.

Du wirst an irgendeiner Stelle zu viel gelöscht haben ...
Die global.h vermutlich nicht, denn dann kämen vermutlich mehr 
Fehlermeldungen ?

Wenn ich am Wochenende etwas Zeit habe, werden ich mich mal ransetzen 
und bis auf die LCD-Routinen alles abspecken.

mfg

Michael S.

Autor: Michael S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Clemens,

als Anhang die reduzierte Version der DCF-Uhr.
Ausser der LCD-Ausgabe sind alle anderen Option entfernt.
Das Programm benötigt nun noch ca. 3700 Byte Flash und 80 Byte Daten.

Läuft also ab einem mega48.

Wenn Debugging-Information zugeschaltet werden (Anzeige von Fehlern auf 
dem LCD, Protokollierung der Daten via RS232), dann kommt man auf 4000 
bzw. ca. 5000 Byte.

Ich habe das Programm kurz auf einen mega168 gespielt - es läuft.
Weitergehende Tests habe ich allerdings nicht durchgeführt.

Viel Spaß - heute Nacht wird's spannend (wenn die Uhr auf Sommerzeit 
umschalten soll). Man wird sehen ...

Michael S.

Autor: Fabian H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,

ich verwende ein MK3 von myAVR mit einem mega2560. Meinst du es ist 
möglich deine reduzierte Version so umzuschreiben das sie auch auf dem 
2560 läuft? Bin Anfänger, würde mich also über Tipps sehr freuen...

Gruss Fabian

Autor: Michael S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Fabian,

möglich ist das sicherlich.
Aber es würde bedeuten, mit Kanonen auf Spatzen zu schießen.

Denn wie ich oben geschrieben habe, das Programm benötigt in dieser 
abgespeckten Variante mal gerade 4kb an Speicher.
Und wieviel davon hat der mega2560 ?

Aber machbar ist es.
Anzupassen sind lediglich die verwendeten Pins für das LCD und den 
DCF-Empfänger.
Und vielleicht noch einige Registernamen.

Da ich selbst noch nie einen mega2650 eingesetzt habe, wird wohl die 
Lektüre der Manuals notwendig.

Übrigens ist der "größte" Controller, den ich bislang verwendet habe, 
der mega168 im Zusammenhang mit diesem DCF-Programm.
Als ich mit den AVR's angefangen habe, habe ich mir als erstes 2 mega32 
beschafft: die habe ich bis heute noch nicht benutzt.

mfg

Michael S.

Autor: Fabian H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,

du hast absolut recht damit das der mega2560 ein bißchen übertrieben 
ist.
Ich habe mich für diesen Controller entschieden, weil er mir genügend 
Reserven bietet. Die Auswertung des DCF Signals ist nicht alles, es 
sollen noch Motoren und Sensoren gesteuert werden. Wenn am ende klar ist 
wieviel Speicher bzw. Pins benötigt werden, wollte ich mir einen 
passenden Controller suchen. Der mega2560 ist also nur zum 
experimentieren gedacht.

Ist es richtig das es sich bei den von dir erwähnten Registernamen um 
die Register der Timer handelt?

mfg Fabian

Autor: Clemens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,

vielen Dank für die Modifikation des Source Codes.
Ich habe es leider noch nicht durch den Compiler.
Ich werde heute Abend noch einmal auf die Fehlersuche gehen.

Gruß

Clemens

Autor: Michael S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Fabian,

da ich den mega2560 nicht kenne, ist mir auch nicht klar, welche 
Fallgruben da lauern.

Aber sicher sind alle Einstellung im Bereich des Timers und der 
Interrupts für INT0 / INT1 zu prüfen.
(Ich habe gerade mal einen kurzen Blick ins Datenblatt des mega2560 
geworfen, der hat ja Interrupts via INT0 bis INT7  ...
Und die müssen alle irgendwie konfiguriert werden.)

Der Timer muss halt am Ende wieder den gleichen Takt erzeugen, wie auf 
dem mega48/88/168.
Alternativ könnte man natürlich das Programm entsprechend ändern ...

Im Zweifelsfalle einfach mal den Compiler anwerfen und schauen, worüber 
er meckert.
Und wenn er schweigt, dann schauen, ob das Programm funktioniert.
Und wenn nicht, dann muss man überlegen, was die Ursache sein könnte.
Ist halt manchmal ein mühseliges und zeitraubendes Geschäft.

mfg

Michael S.

Autor: Clemens (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,

nachdem ich einige kleine Hürden beim Compilieren nehmen musste,
ließ sich der Controller schießen.
Anbei zwei Fotos.
Danke noch einmal.

Gruß

Clemens

Autor: Karl-heinz "s." (kahese)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,
Finde dein Program gut, Läuft auch ohne Problme solange ich kein 
Alarmzeit eingebe. Gebe ich eine Alarmzeit ein kommt die Uhr mit ERE:07. 
Hier mal der Ausdruck über RS232:
000000.0000000!.000000!.000000.000.00000.00000000! XTL: x 20 
11:50-s-28.04.10  # 18 code: 0x7, err: timeout, bit_cnt, parity 
11:50-s-28.04.10
slot: 01, rule: ---.---.127.---.---.---.070.003. -> switch: 70, action: 
toggle.

Vieleicht hast du einen Tip.

MFG
Karl-Heinz

Autor: Michael S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Karl-Heinz,

> Läuft auch ohne Problme solange ich kein Alarmzeit eingebe

Das ist schlecht.

> 000000.0000000!.000000!.000000.000.00000.00000000! XTL: x 20
> 11:50-s-28.04.10  # 18 code: 0x7, err: timeout, bit_cnt, parity

es wird kein DCF-Signal decodiert, die Bit-Zeiten werden nicht 
eingehalten, deswegen err:timeout.
Deswegen gibts es auch die Paritätsfehler.
Und die Uhr läuft (wenn sie denn überhaupt noch läuft) nach der 
XTAL-Zeit.

Die Anzeige 'ERE:07' läßt vermuten, dass hier Speicherbereiche 
überlaufen, auf falsche Speicherbereiche zugegriffen wird.

Ich nehme an, dass die Ursache in 'switch 70' steckt.
Denn damit müßte ein Port 7 (63 + 7 = 70) am Controller angesprochen 
werden - den hatte ICH zumindest nicht definiert.
Möglicherweise wird hier ein fehlerhaft (zu großer) Wert nicht korrekt 
abgefangen.

Setze einmal den switch auf 64 anstelle von 70.
Damit sollte dann auch ein real existierender Port am Controller 
geschaltet werden.

mfg

Michael S.

Autor: Karl-heinz "s." (kahese)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,
Danke für die schnelle Antwort.
Das mit switch 70 war ein versehen von mir. 64 u. 65 ist Rs232.
Habe jetzt mal 69 (PD.5) eingegeben.
001001.1110010!.110010!.000101.110.00100.00001000! XTL: x 20 
13:27-s-28.04.10  # 1 code: 0x7, err: timeout, bit_cnt, parity 
13:27-s-28.04.10
slot: 01, rule: ---.---.127.---.---.---.069.003. -> switch: 68, action: 
toggle.
Das gleiche ergebnis.

MfG

Karl-Heinz

Autor: Michael S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Karl-Heinz,

ich habe mal in meinem Kommentar im Quellcode nachgesehen:
Da habe ich geschrieben, dass z.Z. nur der switch #64 an PD.7 aktiviert 
ist !!

Das Problem ist, dass kein "ganzer" Port mehr für Schaltaktionen frei 
ist.
Somit muss man (ich) mühsam die switches auf die wenigen freie Portpins 
mappen.

Da ich aber in der Regel einen Portexpander via TWI nutze (also mit den 
switches 0 .. 63 arbeite), habe ich nur einen Portpin zum Testen (und 
für einen lokalen Schalter) aktiviert.
Wenn ich es recht erinnere, dann ist auch nur noch ein weiterer Portpin 
frei.

Also noch mal ein Versuch mit #64 an PD.7.

Wenn's nicht hilft, dann musst du das entstehende Problem etwas 
ausführlicher beschreiben.

Denn an der Debugging-Ausgabe erkenne ich nur, dass kein gültiges 
DCF-Signal empfangen wird.


mfg

Michael S.

Autor: Karl-heinz "s." (kahese)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,
mit #64 wird PD.7 getoogelt.ist ok. Aber trotzdem, sobalt ich die 
schaltfunktion zum 168 sende geht er auf error. Selbst wenn ich dann die 
Schlatzeiten lösche(0x08, 0xFC) bleibt der Fehler.

MfG

karl-Heinz

Autor: Karl-heinz "s." (kahese)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,
habe vergessen zu schreiben, die Schaltzeiten werden auch gelöscht.

MfG
Karl-Heinz

Autor: Karl-heinz "s." (kahese)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,
Habe noch etwas festgestellt. Beim ersten Durchlauf Steht in der 
Debugging Ausgabe DCF,
001001.1000001!.101010!.000101.110.00100.00001000! DCF: d 61 
15:41-s-28.04.10 resynch
Beim 2. Durchlauf XTL
001001.0100001!.101010!.000101.110.00100.00001000! XTL: x 20 
15:42-s-28.04.10

MfG

Karl-Heinz

Autor: Michael S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Karl-Heinz,

grundsätzlich gibt es zwei Baustellen:
1.) die DCF-Uhr mit der Synchronisation auf das DCF-77-Signal
2.) die Alarmzeiten und das Schalten der Portpins/Senden von TWI-Daten

Das hier betrifft 1.)
> 001001.1000001!.101010!.000101.110.00100.00001000! DCF: d 61
> 15:41-s-28.04.10 resynch

Die Uhr hat sich von einer fehlerhaften Zeitanzeige wieder auf die Zeit 
des DCF-77 (re)sychronisiert.
Bleibt nur die Frage, warum die Zeit vorher fehlerhaft war.

Dazu muss man sich das Protokoll der vorausgehenden Zeit ansehen.

Während der Testphase habe ich über viele Tage die Protokolle geloggt 
und anschließend versucht, die Ursachen für  aufgetretene 
Fehlermeldungen zu erklären.
Viele Fehler sind mir nur in den Log-Dateien aufgefallen.

Die richtige Umsetzung der Alarmzeiten ist das andere Thema.
Dort scheint ja der Auslöser für deine Probleme zu stecken.
Interessant sind hier im Protokoll die Ausgaben wie

> slot: 01, rule: ---.---.127.---.---.---.069.003. -> switch: 68, action: toggle.

(vermutlich liegt hier ein Tipfehler vor: 069.003 sollte zur Erlätuerung 
"switch: 69, action: toggle" führen)

An dieser Ausgabe läßt sich erkennen, ob die Schaltzeiten und 
Schaltvorgänge so erkannt wurden, wie sie gemeint waren.
Anschließend muss geprüft werden, ob auch die Umsetzung auf die Portpins 
bzw. den TWI-Bus korrekt erfolgt.

Wenn ein Fehler auftritt (wie das vermutete Überschreiten von 
Arraygrenzen), dann hat das nicht vorhersehbare Auswirkungen und kann 
z.B. nur zu falschen Zeitangaben oder aber sogar zum Absturz führen.

Theoretisch kannst du auch im Programm eine klitzekleine 'Verbesserung' 
vorgenommen haben ...

Wie du siehst, ohne systematische Tests ist für mich das Problem schwer 
eingrenzbar.

Ich will aber mein laufendes System mit deinen Daten füttern und 
schauen, ob es schlapp macht.
Wenn nicht, dann schicke ich dir den aktuellen (eigentlich seit 4 
Monaten unveränderten) Programmcode.

Dauert aber etwas.
Denn das kann ich im Büro nicht machen.

mfg

Michael S.

Autor: Karl-heinz "s." (kahese)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,
Hab noch einmal deine Zip ausgepackt und geladen. Dabei bleibt die Uhr 
stehen sobald die neue Sekunde kommt(DCF). Dann habe ich, da für die Uhr 
kein Slave vorhanden ist in der Global.h TWI_ADR_Zeitzeichen und 
Zeitzeichen abgeklemmt. Dann erkennt die Uhr die neue Minute und läuft.
sonst habe ich keine anderen änderungen gemacht.
Vielleicht mal ein Tipp wo ich sonst den Slave für die Uhr abklemmen 
kann.
 Bis wieder eine Alarmzeit geladen wird. habe mal 5 Zeilen 
mitgeschrieben.
Logging on RS232
001001.0001100!.000110!.000101.110.00100.00001000! DCF: d 61 
18:18-s-28.04.10 resynch
001001.1001100!.000110!.000101.110.00100.00001000! XTL: x 20 
18:19-s-28.04.10
001001.0000010!.000110!.000101.110.00100.00001000! XTL: d 20 
18:20-s-28.04.10
001001.1000010!.000110!.000101.110.00100.00001000! XTL: d 20 
18:21-s-28.04.10

Hier habe ich dann die Alarmzeit geladen

001001.0100010!.000110!.000101.110.00100.00001000! XTL: x 20 
18:22-s-28.04.10  # 1 code: 0x7, err: timeout, bit_cnt, parity 
18:22-s-28.04.10
slot: 01, rule: ---.---.127.---.---.---.064.003. -> switch: 64, action: 
toggle

MfG

Karl-Heinz

Autor: Karl-heinz "s." (kahese)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michae,
Der Feher mit der Alarmzeit tritt auch auf wenn ich nur Zeit_Zeichen 
abklemme.

Mfg

Karl-Heinz

Autor: Karl-heinz "s." (kahese)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,
hängt alles am Slave von der Uhr aus gesehen. ein paar Fragen hierzu.
PCF8574 oder PCF8574A, Hex adr vom Slave ist 0x10, ist das richtig?
Habe einen Logic Analyzer dran hängen. Bei mir wird von der Uhr kein 
Telegram an den Slave gesendet. deshalb bleibt er auch hängen bei 
erkannter minute. Hab noch keine Lösung.

Gruß

karl-Heinz

Autor: Karl-heinz "s." (kahese)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,
Ich ruder wieder etwas zurück. Habe jetzt einen Slave drangehängt, hatte 
vorher die Alarmzeit ins Eprom geschrieben und siehe da die Uhr läuft 
ohne Fehler. Muß dann wohl mal meinen Master überprüfen.

MfG

Karl-Heinz

Autor: Michael S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Karl-Heinz,

am gestrigen Abend habe ich meine Uhr mit deinen Daten gefüttert:
und ich konnte auch Fehlermeldungen erkennen.

Allerdings war mir nicht klar, ob nicht eine Störung des DCF-Signals die 
Fehlermeldung erzeugt.
Daher habe ich zwei Schaltzeitpunkte definiert und die Nacht über die 
Ausgabe aufgezeichnet.
Einen typischen Ausschnitt habe ich als Anhang beigefügt.

Wenn deine Fehleranalyse lauten würde:
Nach Schaltvorgängen werden (meistens, nicht immer) Fehlermeldungen 
ausgegeben,
aber das System hat keine erkennbare Funktionsstörung,
nach 2 Minuten verschwindet die Fehlermeldung (das klappt natürlich 
nicht bei togglen im Minutentakt)
dann kann ich einen korresponierenden Hinweis im Protokoll finden.

Unerwartet sind hier (das habe ich bislang ignoriert) die Ausgaben wie 
in

Zeile 29 und Zeile 43.

Hier fehlt die Ausgabe der DCF-Bits !!
Komischerweise gibt es auch keine Fehlermeldung.
Und in der nachfolgenden Minute mißlingt der Vergleich des DCF-Signals 
mit der vorangegangenen Minute.
Erst nach 2 Minuten fasst das System wieder tritt.

Beruhigend ist, dass die Uhrzeit fehlerfrei weiterläuft und dass auch 
die Schaltvorgänge offensichtlich korrekt ausgeführt werden.

Bleibt also als Ansatzpunkt der Programmteil, in dem die DCF-Bits 
ausgegeben werden (oder auch nicht).
Von da aus kann man sich weiterhangeln.

Im Augenblick habe ich dafür aber Zeit.

mfg

Michael S.

Autor: Michael S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich wollte im letzten Satz schreiben:

im Augenblick habe ich dafür aber KEINE Zeit.

mfg

Michael S.

Autor: Michael S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Karl-Heinz,

wenn ich dich richtig verstanden habe, dann treten bei dir keine Fehler 
mehr auf ??

Allerdings habe ich inzwischen die Ungereimtheiten in der 
Protokollausgabe eingekreist:
Wenn weniger als 58 Bit empfangen werden, dann erfolgt keine Ausgabe der 
DCF-Bits in der Log-Datei.

Daher habe ich direkt vor dem Löschen der DCF-Bits (der letzten Minute) 
noch eine Abfrage auf Vollständigkeit der DCF-Bits eingefügt und setzte 
ggf. ein Fehlerflag.
Nun erscheint die Fehlermeldung auch im Protokoll.

Beim Sichten der nächtlichen Protokollierung fällt mir auf, dass der 
Fehler häufig (d.h. nicht immer !!!) bei Schaltvorgängen auftritt.
Was die Fehlerfindung nicht gerade vereinfacht.

Allerdings als Trost:
die Uhrzeit läuft korrekt weiter und auch die Schaltvorgänge 
funktionieren (soweit ich es getestet habe).

Trotzdem werde ich wohl über die Ursachen des Problems nachdenken 
müssen.


mfg

Michael S.

Autor: Karl-heinz "s." (kahese)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,
Bin wieder bei der Uhr. Die Uhr läuft prima solange ich nicht mit einem 
Master drauf zugreife. Sobald ich die Uhr jede Minute auslese und auch 
die richtige Zeit zurück bekomme, geht die Uhr auf error 07. Ich 
programmiere mit MikroPascal. Habe noch eine Frage: Habe einen PCF8574 
drangehängt. Welche Hardwareadr. muß eingestellt werden.

MfG

Karl-Heinz

Autor: Michael S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Karl-Heinz,

der Error 0x07 bedeutet, dass Bits 0,1,2 im flag 'error' gesetzt sind.
In der dcf.h kannst du nachsehen, welches die Fehlerursachen sind
(ich weiss es nicht auswendig, aber ich glaube das sind Fehler aus der 
Prüfung der 58 DCF-Bits.)

Allerdings greife ich häufig mit einem Master auf die Uhr zu, etwa um 
Alarmzeiten zu programmieren oder um sie ins Eeprom zu schreiben - das 
gibt keine grundsätzlichen Probleme.

Arbeitet dein Master korrekt ? Kann es sein, dass dein Bus 'klemmt' ?
(sind SDA oder SCL nach der Sendung ständig low - mal mit einer LED 
prüfen)
Kannst du denn mit dem PCF8574 erfolgreich kommunizieren ?

Was meinst du mit minütlichem Auslesen ?
Um die Uhrzeit auszulesen, musste du die Uhr mit einer bestimmten 
Adresse (siehe read.me) ansprechen und 8 Byte auslesen.
Dann wird dir die Uhrzeit geliefert.
Also 0x08 und die Adresse senden, dann mit 0x09 8 Byte abholen.

Die andere Frage:

Die Adresse der TWI-Slaves ist frei einstellbar.
Dazu gibt es #define TWI1 64 .... TWI8 0 78 xin alarm.c (?).

Die Schalter mit der Nr. 0.. 7 werden an TWI1,
die Schalter mit der Nr. 8..15 werden an TWI2 usw. gesendet.

Wenn du den PCF8574 mit seiner Standardadresse 0x40 = 64 senden willst 
und meine Definitionen nicht verändert hast, dann sollten die Schalter 
0..7 auf Adresse 0x40 = 64 ausgegeben werden.

mfg

Michael S.

Autor: Karl-heinz "s." (kahese)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,
Danke für deine ausführliche Hilfe, bei mir läuft jetzt alles. Nur noch 
ein Problem. wenn ich mit dem Master einmal pro Minute die Zeit auslese, 
geht die Uhr auf Störung.(Er:07). Hör ich mit dem Auslasen auf, fängt 
sich die Uhr wieder. Habe jetzt mal alle 10 min ausgelesen kommt die 
Error- meldung und wird dann nach einer minute wieder zurückgenommen. 
Kann ich mit leben. Tolles Projekt.

MfG

Karl-Heinz

Autor: Michael S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Karl-Heinz,

dein Problem, dass die Uhr nach dem Auslesen von Speicherbereichen 
(genaugenommen der Uhrzeit) in der Folgeminute Fehlermeldungen wirft, 
deutet darauf hin, dass bei Lesen Veränderungen in den Daten vorgenommen 
werden.
Ich werde am Abend testen, ob das ein Problem des Programmes ist - oder 
eine "falsche" Abfrage.


Ansonsten haben deine Fragen meine Nase auf ein kleines Problem 
gestossen.
Was mir keine Ruhe gelassen hat - aber ich habe die Ursache gefunden.

Das Problem war:

durch eine unvollständige Plausibilitätsprüfung wurde in den 
Fehlermeldung bislang nicht angezeigt,
wenn weniger als 58 DCF-Bits empfangen wurde.
Dieser Fehler tauchte immer dann auf, wenn:
- die rechenintensive Sonnenstandberechnung eingeschaltet war,
- Alarmzeitpunkte erreicht waren und
- die Protokollierung über die RS232-Schnittstelle aktiv war.

Dann wurde länger als 1 Sekunde gerechnet bzw. Daten ausgegeben.
Mit dem Erfolg, dass der DCF-MInutenbeginn, der zwar per Interrupt 
empfangen wird und ein Flag setzt, nicht rechtzeitig bearbeitet wurde 
und der Index für die DCF-Bits erst in der Sekunde 1 zurückgesetzt 
wurde.
Dann fehlte in der Folgeminute ein DCF-Bit.

Da es bislang keine Fehlermeldung bei einem unvollständigen 
DCF-Bit-Datensatz gab, war mir das Problem nicht aufgefallen.
Lediglich die Tatsache, dass im Protokoll an manchen Stellen keine 
DCF-Bits ausgegeben wurden, hat mich auf die Fährte geführt.

Das Problem ist nun durch eine Aufteilung der Arbeit zu Beginn einer 
neuen
Minute gelöst:
- Am Beginn der Minute wird das Display neu aufgebaut
- am Beginn der 1. Sekunde werden die Alarmzeit getestet und ggf.
  geschaltet.
- am Beginn der 2. Sekunde werden die Sonnenstandsberechnung ausgeführt.

- am Beginn der 59. Sekunde wird geprüft, ob die DCF-Bits vollständig 
sind.

Da mir zu Beginn der Fehlersuche die Logik der DCF-Synchronisation nicht 
mehr wirklich präsent
war, habe ich - nach der Motto, 1 Bild sagt mehr als 1000 Worte - zuerst 
einmal ein
Ablaufschema der Hauptprogrammschleife aufgetragen.

Das Diagramm ist als DCF_Logik.pdf angehängt.
Es zeigt den Ablauf des akuellen Programmes !
In den bisherigen Versionen wurde die Arbeit aus Sekunde 1 und Sekunde 2 
zusätzlich zum Neuaufbau des Display am Minutenbeginn ausgeführt. Neu 
ist auch die Prüfung der Anzahl der DCF-Bits in der 59. Sekunde.

Vielleicht hilft das Schema auch anderen beim Verständnis der 
DCF-Synchronisation.

Beigefügt im zip.file ist auch noch eine Logdatei, die ein Protokoll von 
etwas mehr als 1 Stunde mit vielen Schaltvorgängen widergibt.
Die Störungen entstehen vermutlich durch ein eingeschaltetes TV.


mfg

Michael S.

Autor: Michael S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Karl-Heinz,

folgender genereller Hinweis zur Abfrage der Zeit via TWI fällt mir 
gerade noch ein:

Das Abholen der Daten erfolgt innerhalb einer ISR, das ist zunächst das 
Problem.
Aber nicht nur theoretisch kann diese Abfrage genau dann erfolgen, wenn 
das Programm gerade dabei ist, die Zeit fortzuschreiben.
Und dann bekommst du Daten geliefert, die zum einen Teil aus der alten 
und anderen Teil aus der neuen Minute bzw. Sekunde stammen.

Beispiel:

alte Zeit: 23:59:59 03.05.10
neue Zeit: 00:00:00 04.05.10

Angenommen, der TWI-Interrupt schlägt z.B. genau zwischen Minute und 
Datum zu.

Dann liest du als Datum 00:00:00 03.05.10

Das ist genau um 24 Stunden daneben.

Wenn du also (nicht nur zum Debuggen) die Zeit per TWI auslesen willst, 
dann müssen diejenigen Routinen, in denen die Daten geändert werden, 
durch Sperren / Freigeben der Interrupts atomar gemacht werden.

mfg

Michael S.

Autor: Michael S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Karl-Heinz,

als Hilfe zur Selbsthilfe zu deinem Ausleseproblem für die Uhrzeit hier 
die Frage, ob du richtig vorgegangen bist.

Dazu eine kurze Erläuterung des TWI-Slave-Moduls.

Es ist so eine Art trojanischen Pferd, das der Uhr implantiert ist.

Die DCF-Uhr weiss nichts vom TWI-Slave - und verwendet ihn auch nicht.
Das Modul arbeitet ausschließlich in der TWI-Interrupt-Routine.

Wenn der Slave mit einem "write" angesprochen wird, dann interpretiert 
er das erste Datenbyte als Speicheradresse.
Auf diese Stelle wird ein Pointer gesetzt.
Wenn weitere Bytes folgen, dann werden sie lang weg sequenziell in den 
Speicher geschrieben, egal ob's Sinn macht oder nicht.

Alarmzeiten und Uhrzeiten werden programmtechnisch nicht unterschieden, 
es sind jeweils Arrays der Länge 8 Byte.
Genaugenommen handelt es sich um ein 2-dimensionales Array, wobei der 
erste Index der "slot" ist, der zweite die Byte-Nr.

Diese Methode ermöglicht, beliebige Speicherbereiche der Uhr von aussen 
zu beschreiben und zu lesen.
Das war wunderbar zum Debuggen.
Etwa um den Übergang von Sommer- auf Winterzeit zu testen.
Da habe ich der Uhr einfach geeignete Daten untergejubelt und geschaut, 
ob richtig reagiert wird.

Aber es ist auch gefährlich, wenn das Prinzip nicht verstanden ist und 
man die Methode falsch einsetzt.
Etwa, indem man mehr Daten schreibt, als ein "slot" lang ist.
Dann überschreibt man nämlich den folgenden slot - die Folgen sind 
vorhersehbar.

Der richtige Weg zum Auslesen der Uhrzeit ist:

Zum Auslesen von Daten schreibt man zunächst genau 2 Byte:
- das 1.Byte ist die TWI-Adresse des slave + ("write")
- das 2. Byte ist die Speicheradresse des arrays, in dem die gesuchten 
Daten (etwa die Uhrzeit) steht.
Nun steht der Pointer auf dem ersten Byte dieses Arrays.

Achtung: Jedes weitere Byte, das du hier schreibst, überschreibt Daten 
der Uhrzeit !!!!
Dann gibt es konsequenterweise Fehler in der Folgeminute.

Zum Auslesen der Daten muss man nun lesend auf den Slave zugreifen - die 
Slave-Adr + ("read") senden und 8 Byte oder mehr einlesen.
Beginnend von der Stelle, auf die der Pointer zeigt, werden nun die 
Daten eingelesen und via TWI an den Master abgeschickt.
In den ersten 8 gelesenen Byte steht dann z.B. die Uhrzeit.
An dieser Stelle ist es unschädlich, wenn mehr Bytes gelesen werden - es 
werden ja keine Daten verändert.

Alles klar ? Alles richtig gemacht ?
Wenn ja, dann suche ich nach Fehlern im Programmcode.


mfg

Michael S.

Autor: Michael S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Karl-Heinz,

deine Beobachtung war richtig.
Es wird bei allen Zugriffen auf ein Zeitarray ein Fehler 0x07 
ausgegeben.

Hier steckt noch eine Zeile aus der Testphase im Programmcode, der 
darauf hinweisen sollte, dass die Uhrzeit via TWI geändert wurde.

Und leider steckt darin auch noch ein kleiner Bug - der zu einer 
falschen Fehlermeldung führt.
Das lockte natürlich auf eine falsche Fährte.

file: TWI_master_slave.c

ab Zeile 213

else if ((TWI_SLA_cmd > 0xEF) && (TWI_SLA_cmd < (0xF0 + CLK_ARRAYS)))
   {
   TWI_SLA_cmd -= 0xF0;
   ptr = &time[TWI_SLA_cmd][0];
// error |= ERR_TWI;    // diese Zeile auskommentieren
        // richtig wäre die Zeile so gewesen:
// error |= (1<<ERR_TWI);
   }

Jetzt sollte die Uhr nach dem Auslesen der Zeit ohne Fehlermeldung 
weiterlaufen.

mfg

Michael S.

Autor: Karl-heinz "s." (kahese)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,
Habe die Änderung durchgeführt und läuft alles super.
Falls ich noch etwas bemerke, melde ich mich dann wieder.

MfG

Karl-Heinz

Autor: benny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo michael,
läuft dein programm auf einem atmega8 + lcd 2x16.
ich will nur uhr + datum aus dem dcf signal anzeigen lassen.
das sollte doch problemlos möglich sein?!

mfg benny

Autor: Michael S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo benny,

am 27.03. hatte einen abgespeckten Programmcode eingestellt,
der sollte auf den atmega8 passen.

Es sind möglicherweise noch Register umzubenennen.
Dazu einfach kompilieren - die Fehlermeldung stossen dich mit der Nase 
darauf.

Und natürlich sind ggf. die Einstellungen für das LCD anzupassen.
mfg

Michael S.

Autor: hein (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo Michael S.,
ich hab den Beitrag hier mit interesse gelesen,
nu hab ich zwei Fragen an dich,
könntest du den Quellecode nochmal komplett als
zip.File einstellen wie die letzte Version ist(LCD 4stellig) und
hast du auch einen Schaltplan für das ganze zum nachbauen?

Danke für deine Mühe
Gruß Hein

Autor: Michael S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo hein,

den (fast) aktuellen Programmcode (für eine 4-zeilige LCD-Anzeige)
habe ich am 04.05. bereits bereitgestellt.
Die einzige Änderung habe ich am 05.05. beschrieben:
- es muss eine Zeile im TWI-Modul gelöscht werden.

Einen Schaltplan gibt es nicht - aber in der readme habe ich in Worten 
beschreiben, wer mit wem zu verbinden ist.

Es ist eigentlich auch ganz einfach:
- das LCD wird so angeschlossen, wie in der lcd.h definiert,
- TWI, RS232, Quarz und Power hat der Hersteller festgelegt,
- das DCF-Signal wird an INT0 und (!) INT1 angeschlossen.

mfg

Michael S.

Autor: Paul S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,
ich weiß garnicht ob du hier überhaupt noch reinschaust,
aber ich versuch es trotzdem mal.

Also ich hab da mit großer Interresse deine DCF-Uhr gelesen,
nun hab ich deinen Code vom 05.05 geladen und versucht zu
compalieren.
bei mir kommen zwei error's im bezug auf TWI_master_slave.c

- `F_CPU` undeclared (first use in this funktion)
- (Each undeclared identifier is reported only once
   for each function it appears in.)

kannst du mir oder vieleicht ja jemand anders hier einen Tip geben
was ich da falsch mache.
Warscheinlich mach ich hier nur ein dofer Fehler aber ich komm
nicht drauf.

Vielen Dank schonmal im voraus

mfg
Paul

Autor: Herbert K. (avr-herbi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ist definiert im Makefile:

#         F_CPU =  2000000
         F_CPU =  3686400
#         F_CPU =  4000000

mit C kenne ich mich aber auch nicht aus. Viel Glück.

Autor: Michael S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo allerseits,

gelegentlich benötigt man in einem Projekt lediglich eine Zeitbasis, 
ohne all die zusätzlichen Funktionen, die in der bisher vorliegenden 
DCF-Uhr implementiert sind.

Daraus ist der Gedanke entstanden, die Uhr auf die wesentlichen, 
zeitfortschreibenden Funktionen zu reduzieren, alles komplett in einem 
Modul zu kapseln und über definierte Funktionen auf das Modul 
zuzugreifen.

Der Vorteil: man muß das Modul lediglich ins eigene Projekt einbinden 
und schon stehen Uhrzeit und Datum zur Verfügung.

In der Readme.pdf sind weitere Details beschrieben, im Programmcode (in 
main.c) ist die Anwendung demonstriert.



Michael S.

Autor: Michael S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo allerseits

Hier gibt es noch einmal eine Überarbeitung des Uhrmoduls mit folgenden 
Veränderungen:

- Es wird nur noch ein einziger Interrupt und damit auch nur noch ein 
einziger Eingangspin für das DCF-Signal verwendet.

- Die Funktion DCF_New_Second() liefert nur dann ein TRUE zurück, wenn 
die Zeit wirklich fortgeschrieben werden muss (bislang konnten zum 
Minutenbeginn zwei Aufrufe erfolgen).

- Bei Empfangsproblemen kann eine neue Funktion dabei helfen, Probleme 
im Timing des DCF-Signals zu erkennen, so dass die Programmparameter an 
das Signal angepasst werden können.

Weitere Hinweise stehen in der Readme.pdf.

Michael S.

Autor: Karl-heinz "s." (kahese)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michel,
Ich bin's mal wieder. Uhr läuft super. Wollte jetzt aber mal was mit 
Sonnenauf- und untergang machen. Nur die Zeiten sind sehr ungenau. bei 
sonnenaufgang -26 min und bei SU +44 min. Meine Koordinaten, wo ich 
wohne (52,23 10,42), sind deinen ähnlich. Geht es nicht besser oder ist 
noch ein Fehler vorhanden. Gruß Karl-Heinz.

Autor: Michael S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Karl-heinz,

zum Thema Sonnenstand bzw. Sonnenaufgang/untergang fallen mir zwei 
Anmerkungen ein:

1. Es gibt verschiedene Definitionen für den Zeitpunkt des 
Sonnenuntergangs, die sich in der Definition des Winkels (Elevation) 
unterscheiden, den die Sonne unter dem Horizont stehen muss.
Den Winkel kann man im Programm beliebig definieren.
Vergleiche der Programmausgabe mit anderen Angaben setzen immer voraus, 
das unter derselben Definition (Elevation) gerechnet wird.

2. Die Berechnung des Sonnenstandes fordert den ATMega ordentlich 
heraus.
Platz für einen eigenständigen Algorithmus, der den Zeitpunkt von 
Sonnenuntergang/Aufgang berechnen kann, ist nicht mehr vorhanden.
Daher habe ich den vorhandenen Rechenweg für den Sonnenstand genutzt und 
versuche, durch "Ausprobieren" verschiedener Uhrzeiten den Zeitpunkt zu 
finden, an dem der für Sonnenuntergang/Aufgang definierte Winkel gerade 
über/unterschritten wird.

Die Berechnung wird übrigens nur 1x am Tag ausgeführt - und natürlich 
beim Programmstart .

Im Laufe der Zeit habe ich feststellen müssen, dass manchmal Fehler in 
den Zeitangaben erkennbar sind (um bis zu 1h).
Bei der Berechnung von Elevation und Azimuth sind mir keine Fehler 
aufgefallen.
Resetet man die Uhr, dann werden plausible Werte für 
Sonnenaufgang/Untergang berechnet.

Vor einigen Jahren hat einmal der Chefentwickler eines CAD-Programmmes 
zu mir gesagt:
"Ein Fehler, der nur gelegentlich auftritt, ist kein Fehler".
In seinem Sinne ist das Programm also fehlerfrei.

Naja - Scherz beiseite.
Irgendwo steckt da noch ein Bug, aber ich habe ihn nicht gefunden - und 
suche auch nicht weiter danach.
Das ganze Programm war schließlich nur als Fingerübung über den 
Jahreswechsel entstanden ...


Michael S.

Autor: Bernd Bömer (behbeh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,
schönes Programm hast Du geschrieben.
Mich interessiert, ob ich das Programm als Schaltuhr mit 3 Kanälen zu 
gebrauchen ist. Also am liebsten direkt mit den freien Portpins z.b. 
Relais schalten ohne die TWI Bausteine..(PCF8574?).
Kannst Du mir eine Tip geben, wie ich das einflechten kann in dein 
Programm.
Bischen Erfahrung in der Programmierung habe ich schon.
Ich möchte als Ergebnis eine Schaltuhr haben, die meine "dumme Schaltuhr 
aus der Heizungsanlage ersetzt. Dort ist eine 2 Kanal Uhr eingebaut,mit 
der man am Tag glaube 3 Schaltzeiten für jeden Kanal nutzen kann.
Es wird wohl reichen, wenn man für 3 Kanaäle, 7 Tage 3 Ein-Aus 
Schaltungen programmieren kann.
Ich hoffe ich bin nicht zu lästig mit meiner Frage.
Gruß Bernd

Autor: Michael S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Bernd Bömer,

natürlich kannst Du Dein Problem mit dem Programm lösen.

Schau dir in der Readme die Beschreibung zu den Slots an.

Oder - wenn das zu kompliziert klingt - geh' doch einfach an die Stelle 
im Programm, an der eine neue Minute beginnt.

Hier dann fragst Du ab, ob dies der Zeitpunkt ist, an dem Du etwas 
schalten willst.
Wenn ja, dann schaltest Du einen oder mehrere (der freien) Pins am 
Controller.

Das wars schon.


mfg

Michael S.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.