Wieder mal DCF

[Pontius P. (pontiuspilatus)]

Und mal wieder zum DCF,
Es geht immer noch um den Wordclock aus der CT'Hacks.
Anscheinend ist die Implemation des DCF weggelassen wegen Störungen vom 
Led-Matrix. Trotzdem ist auf der Platine eine Anschluss vorhanden und 
wir möchten diese jetzt gerne benutzen.

Das ganze Teil lauft mit ein DS1307 RTC.
Nun sollte die Dcf-Treiber die RTC mit einen Callback-Prozedure 
synchronisieren.
Jetzt habe ich seit mehr als drei Wochen das Standard-Treiber-Handbuch 
studiert, aber komme ehrlich nicht raus was ich da noch eingeben soll.
Wenn der Treiber importiert ist (das ganze wird mit AVRco gemacht) soll 
er jeder Minute den RTC Synchronisieren, macht er aber nicht. Signal ist 
ganz klar voirhanden.
Kann uns vielleicht jemand sagen was oder wie wo noch fehlt in dieser 
Code?

[Karl H. (kbuchegg)]

Ich kenn zwar das Modula System da nicht, aber

> Nun sollte die Dcf-Treiber die RTC mit einen Callback-Prozedure synchronisieren.

kann das der DCF Teil überhaupt?
Unterstützt der sowas wie einen Callback?

[Pontius P. (pontiuspilatus)]

naja, das sollte doch der AVR machen, oder? Ist ja so in Treiberhandbuch 
beschrieben.

[Karl H. (kbuchegg)]

Karl Heinz schrieb:
> Ich kenn zwar das Modula System da nicht, aber
>
>> Nun sollte die Dcf-Treiber die RTC mit einen Callback-Prozedure 
synchronisieren.
>
> kann das der DCF Teil überhaupt?
> Unterstützt der sowas wie einen Callback?

Edit:
Denn so wie ich das sehe, ist das doch mit Kanonen auf Spatzen

Das Programm kommt hier

    if MinuteSema then
      //Blinkenlights:= true;
      BlinkTimer:= 10;
      MinuteSema:= false;
      minute:= DS1307getMinute;
      hour:= DS1307getHour;

...

offenbar jede Minute rein.
Vom DS1307 (wozu braucht ihr dann noch DCF? der DS1307 zählt doch 
ohnehin selber die Zeit weiter) wird die Zeit geholt und die RTC damit 
synchronisiert.
Da kann man natürlich auch noch die DCF mit einbinden. Die wird ja wohl 
irgendwelche Funktionen haben, mit der man sie nach der zuletzt 
empfangenen Stunde und Minute befragen kann und ob es einen gültigen 
EMpfang gab.

Aber ganz ehrlich. SO ganz seh ich den Sinn dahinter noch nicht. Der 
DS1307 implementiert doch schon eine Uhr, die auf lange Zeit gesehen 
zuverlässig läuft.

[Karl H. (kbuchegg)]

Pontius Pilatus schrieb:
> naja, das sollte doch der AVR machen, oder? Ist ja so in Treiberhandbuch
> beschrieben.

Ah, alles klar.
Ich bin raus.

[Pontius P. (pontiuspilatus)]

Ja, ds1307 lauft einigermasse zuverlassig, trotzdemm wollen wir das das 
Dcf funktioniert.

[Pontius P. (pontiuspilatus)]

Ah, alles klar, nein, eben nicht klar. Wenn mann das handbuch zur AVRco 
liest sieht mann als dritte Möglichkeit die Synchronisation mit einem 
RTC.
Und das geh eben automatisch mit einen "Callback-prozedure"
Wenn für dich alles klar ist dann sag mal wo das Problem ist?

[Karl H. (kbuchegg)]

Muss mich korrigieren. Das ist anscheinend Oberon und nicht Modula.

Viel Glück bei dem Versuch dafür einen Programmierer ausserhalb der 
ETH-Zürich zu finden, der sich mit Oberon UND AVR auskennt.

[Hagger (Gast)]

Das ist weder Modula noch Oberon noch Titania, das ist Pascal.

[Karl H. (kbuchegg)]

seit wann ist ...

Import SysTick, TWImaster, RTClock, TickTimer;
 Import DCFclock;

From System Import LongWord, Random;

... Pascal

Was auch immer. Viel Glück

[Pontius P. (pontiuspilatus)]

Was solls den sonst sein?
Das ist das Originalprogramm, daran ist nichts geandert und das lauft 
auch so. Es geht nur um das DCF.

[Pontius P. (pontiuspilatus)]

Nochmal; es geht hier um AVRco und das ist doch wircklich Pascal.

[oszi40 (Gast)]

Sorry, hab jetzt nicht auf die Einzelheiten geachtet. Seit 2006 hat sich 
jedoch das Impulstelegramm des DCF etwas geändert (Wetter/Alarm). Nun 
fragt sich, ob Dein Programm schon Jahre älter ist. 
http://de.wikipedia.org/wiki/DCF77#Bit-Struktur_DCF77-Alarmsignal_des_Feldversuches

[spess53 (Gast)]

Hi

>Sorry, hab jetzt nicht auf die Einzelheiten geachtet. Seit 2006 hat sich
>jedoch das Impulstelegramm des DCF etwas geändert (Wetter/Alarm). Nun
>fragt sich, ob Dein Programm schon Jahre älter ist.

Ein vernünftiges Programm sollte eigentlich die Bits vor den 
eigentlichen Zeitinfomationen schon immer ignorieren.

MfG Spess

[Pontius P. (pontiuspilatus)]

>Sorry, hab jetzt nicht auf die Einzelheiten geachtet. Seit 2006 hat sich
>jedoch das Impulstelegramm des DCF etwas geändert (Wetter/Alarm). Nun
>fragt sich, ob Dein Programm schon Jahre älter ist.

ja, ein monat alt....

Rest vonm Topic auch gelesen?

[Pontius P. (pontiuspilatus)]

Pascal ist hier wohl nicht sehr beliebt, was?

[elektromann (Gast)]

OK,

dann versuche ich es mal hier...

Ich habe mich mal bemüht, eine callback Prozedur zu schreiben. Hier mein 
Vorschlag:

procedure DCFupdate;
begin
   DS1307setSecond(DCF_SECOND);
   DS1307setMinute(DCF_MINUTE);
   DS1307setHour(DCF_HOUR);
end;

Die Prozedur habe ich vor InitPorts eingefügt - soweit ich mich an 
pascal erinnern kann, ist die Platzierung des Code relevant. Die 
Änderung lässt sich ohne weiteres compilieren und flashen, die Uhr 
funktioniert genau wie vorher. Ja, genau wie vorher, ohne DCF-Reaktion. 
Einen Versuch wars wohl wert.

Hat jemand vielleicht eine Ahnung, wie man bezüglich Fehlersuche 
vorgehen kann? Ich finde nicht mal den eingebundenen Quellcode zwecks 
analyse.

EM

[holger (Gast)]

>Pascal ist hier wohl nicht sehr beliebt, was?

Ich würde sogar so weit gehen zu behaupten das das noch untertrieben 
ist;)

[Pontius P. (pontiuspilatus)]

Tja, ist doch schade. Ich bin ja sicher nicht der Einzige..

[Uwe (Gast)]

Hi,
vorweg,0-Ahnung von Pas

>DCFupdate;
und das rufst du auch im Hp mal irgendwie auf?

duck und wech und viel Erfolg, Uwe

[Pontius P. (pontiuspilatus)]

Ja, wird so einfach nicht gehen, sonst hätten wir das schon hinbekommen.
Man muss da irgendwo eine bestimmte calbackprozedure einbinden. ist aber 
alles ziemlich kompliziert.
Normalerweise nimmt mann bei Dcf die interne Uhr, ist nicht sehr genau, 
aber da er ja immer synchronisiert werd ist das kein Problem.
Die Ct hat da aber eine externe RTC angeklebt, (warscheinlich zum 
schnell fertig sein)
Mann muss die ganze Uhr erst umstellen auf die interne RTC und die wird 
dann automatisch mit dem DCF synchronisiert sobald der DCF ein richtiges 
Signal bekommen hat.
Mir ist auch immer noch ein Ratsel wieso der CT für solche eigentlich 
einfache Sachen der AVRco benutzt und das ganze in Pascal entwickelt.
Irgendwie haben die wie Elektor ein tallent dafür sehr einfache Sachen 
sehr kompliziert zu machen und das ganze nachher auf drei Platinen zu 
verteilen.

[elektromann (Gast)]

Hallo Pontius Pilatus,

mein Verständnis der Softwarestruktur war folgendermaßen: Die callback 
funktion wird - sofern vorhanden - direkt von dem Treiber oder wie auch 
immer das bei Pascal heisst aufgerufen. Hier noch der passende 
Ausschnitt aus dem Handbuch:

Der Punkt 3 (Uhren Chip) wird durch eine CallBack Prozedur unterstützt. 
Ist diese Prozedur vorhanden, wird sie bei jeder vollen Minute vom 
Treiber aufgerufen, wenn die Zeit fehlerfreie empfangen wurde. Die 
CallBack Prozedur, die der Programmierer bereitstellen muss, kann jetzt 
das Uhrenchip stellen, indem die jeweiligen Speicherstellen der DCF77 in 
das Chip geschrieben wird.

Soweit ist das verständlich. Aber den folgenden Satz verstehe ich nicht 
(nächster Satz im Handbuch):
Diese Prozedur wird aus dem SysTick heraus aufgerufen. Hierbei ist die 
Register Rettung zu beachten, weiterhin sollte die Prozedur sehr schnell 
sein, um den hier gesperrten globalen Interrupt nicht zu lange zu 
sperren.

SysTick? Retten von Registern ist mir schon geläufig, aber bei der 
eingesetzten Hochsprache?
Ich würde wirklich gerne mal den eingebundenen Quellcode sehen. So 
bleibt wohl nur ein "PIN-debugging". Mühsam, sowas.

Wollen wir das versuchen gemeinsam anzugehen?

EM

[Pontius P. (pontiuspilatus)]

Glaub mir, ich kenne die Handbucher mittlerweile auswendig.
Meiner Meinung nach sollte man die Uhr erst umstellen auf der interne 
Uhr und dann wäre die DCF automatisch eingenbunden wenn mann die treiber 
importiert.

[elektromann (Gast)]

Aha... und wie stellt man das um?

EM

[Pontius P. (pontiuspilatus)]

Ja, das ist ein bischen langere Geschichte.

[Pontius P. (pontiuspilatus)]

Kurz gesagt; man musste das ganze Programm neu schreiben.

[Peter D. (peda)]

Pontius Pilatus schrieb:
> Pascal ist hier wohl nicht sehr beliebt, was?

Es ist einfach nicht verbreitet genug.

C ist für jeden MC-Typ verfügbar, daher wird es bevorzugt. Und es läßt 
sich einfach portieren, z.B. vom AVR auf den Cortex-M3.

Allgemein ist das Synchronisieren zweier Zeitgeber nicht trivial. 
Schnell hat mal einen ungewollten Versatz oder einen Übertrag.

Wie es scheint, hast Du DCF nicht als Code vorliegen, sondern nur als 
Lego-Steinchen.
Dann mußt Du erstmal genauestens die Doku zu diesem Legosteinchen 
durcharbeiten, wie es einzusetzen ist, welche Ressourcen es belegt und 
welche Seiteneffekte es hat. In der Doku müßte es eigentlich auch 
Codebeispiele geben, wie es zu verwenden ist.

Nur wenn Du DCF als Code vorliegen hättest, könnte Dir auch jemand 
helfen, der AVRco nicht benutzt.

[Pontius P. (pontiuspilatus)]

Also, ich probiers nochmal, auch wenn ich euch langsam auf den Wecker 
gehe mit meinen Dcf...

Das hier stammt aus das Handbuch;
Die DCF77 Uhr ist jedoch keine Echtzeit Uhr im herkömmlichen Sinn. Sie 
muss immer in Verbindung mit
einer anderen Uhr gesehen werden. Das AVRco System bietet hier drei 
Möglichkeiten:
1.  DCF77 steuert die RTC einer AVR CPU. Hierzu ist der RTC Treiber zu 
importieren
2.    DCF77 steuert die RTC, welche vom SysTick angetrieben wird.
3,   DCF77 steuert einen externen Uhren Chip
Die Punkte 1 und 2 sind aus der Sicht des DCF77 Treibers identisch. Wird 
eine fehlerfreie Zeit empfangen,
so wird bei jeder vollen Minute die RTC neu gestellt. Das geschieht 
automatisch ohne weiteres Zutun. Der
DCF77 Treiber erkennt die RTC und handelt entsprechend."

Also, geht alles automatisch laut Handbuch... Nur leider im reales Leben 
nicht. Irgendwie uberschreibt der DS1307 alles via der TWI.

Sowie ich das verstehe (ich gebe zu, ist nicht gerade viel im moment) 
steuert der 1307 der RTC vom Atmega8. Der sollte dann doch wieder vom 
DCF uberschrieben worden?

[Harald W. (wilhelms)]

Pontius Pilatus schrieb:

> Die DCF77 Uhr ist jedoch keine Echtzeit Uhr im herkömmlichen Sinn. Sie
> muss immer in Verbindung mit einer anderen Uhr gesehen werden.

Das kann man zwar so machen, aber vor ca 40 Jahren hat man auch DCF-
Echtzeit-Uhren ganz ohne Computer nur mit Schieberegistern gebaut.
Gruss
Harald

[Pontius P. (pontiuspilatus)]

Das bezieht sich auf der DCF uhr im AVRco, aber das hast du ja sicher 
alles gelesen oben im Topic, oder?

[elektromann (Gast)]

Hallo Pontius Pilatus,

nur um Dich vor einer weiteren Sackgasse zu bewahren:
Ich hatte noch die Idee die interne RTC abzuschalten - laut Handbuch ein 
Szenario "Typ 3". Das hat leider auch nicht funktioniert.

Ohne eine Möglichkeit für vernünftiges trouble shooting komme ich hier 
nicht weiter. Ich werde mir nochmal die debugging-Funktionen der IDE 
ansehen, vielleicht geht da noch was.

Grüße EM

[Pontius P. (pontiuspilatus)]

Alles schon probiert..
Irgendwie uberschreibt die TWI-interface mit den DS1307 alles. Von 
andere Seite kann mann die Uhr stellen mit die beide Taster, also gibt 
es doch ein Kommunikation in beide richtungen mit die DS1307.
Ich weiss im moment auch nicht weiter, mir ist es ein Rätsel wieso die 
so ein projekt in Pascal schreiben. Ich habe das vor 22 Jahren in die 
Schule gehabt mit einen Intel 68000 und damals gehorte das eigentlich 
schon ins museum..
Ich habe gelesen das der Entwickler dieses Projekt, Carsten Meyer vom 
CT, seine projekte noch macht auf einen Mac G4, das erklärt vielleicht 
einiges...
Ein flotte Programmierer schreibt das ganze heutzutage in wenige Minuten 
in C, oder wenigstens in Bascom, da bin ich mir sicher. Es ist ja nur 
ein Uhr und ein Ledmatrix.
leider fehlt mir da auch die nötige Basis.
Mir ist das ganze DCF auch irgendwie Würst, der DS1307 lauft ja gut. Und 
die Uhr liegt sowieso schon wieder in eine Ecke. Ich kann es nur nicht 
leidn as ich das mit dem Dcf nicht hinkriege.

[oszi40 (Gast)]

Pontius Pilatus schrieb:
> Irgendwie uberschreibt die TWI-interface mit den DS1307 alles.

Es wäre nicht das erste Programm was tut, was man NICHT möchte.

Fragt sich, ob diese Daten vorher überhaupt ausreichend auf 
Plausibilität geprüft werden bevor sie irgendwo ans Interface geliefert 
werden? Normalerweise ist der Empfang des DCF-Impulstelegramms oft 
gestört und diese kaputten Pakete sollten niiie ans Interface gelangen. 
Baue ein paar Prüfpunkte ein und schau Dir an, was da so ankommt. Wenn 
Du den Punkt gefunden hast kannst Du wohl überlegt das Interface 
blockieren wenn z.B. Pakte zu sehr von der vorherigen Zeit abweichen. 
Statt 12:37 Uhr hatte  ich auch Werte wie 1B:78 empfangen, die dann in 
der weiteren Verarbeitung vie Schaden anrichteten.

[Pontius P. (pontiuspilatus)]

Signal ist Lupenrein, bis in den Traurigkeit kontroliert.

[Pontius P. (pontiuspilatus)]

Der DCF treiber vom Avrco gebt sowieso nur erst ein signal wenn 
uberhaupt ein richtiges DCFsignal empfangen wurde.

[Hans Ulli K. (Gast)]

Man man man man ....

HAST du dir mal mal die Doku durchgelesen ???

In deinem Code ist nur der Eingangspin definiert.
Von Benutzung des Treibers keine Spur.

Zitat:
Procedure
DCFupdate;
// Callback Procedure
Findet der DCF77 Treiber den Import der RT
C nicht, so ruft er jede Minute die Prozedur „DCFupdate“ auf,
falls diese vorhanden ist. Diese Prozedur kann jetzt z.B. ein externes 
Uhrenchip beschreiben. Dazu können
die Speicherstellen/Variablen
DCF_ SECOND, DCF_MINUTE, DCF_HOUR, DCF_DAY, DCF_MONT
H, DCF_YEAR, DCF_WEEKDAY
benutzt werden. Hierbei ist unbedingt zu beachten, dass der Aufruf 
dieser Funktion aus dem SysTick heraus
erfolgt. Evtl. benutzte Register retten. Möglichst sehr schnellen 
Assembler Code verwenden.

Und auch wichtig :
Function
DCFready : boolean;
Das Ergebnis der Funktion wird wahr, wenn der DCF77 Treiber zum ersten 
mal ein komplettes Telegramm
erhalten hat und im Falle der RTC
-
Implementation
, die RTC komplett initialisiert hat. Ab diesem Moment
kann man davon ausgehen, dass die Daten der RTC absolut stimmen. Dieser 
Vorgang dauert nach dem
Einschalten mindestens 1 Minute und wenn der Empfang ok ist, maximal 2 
Minuten, ansonsten kann es
mehrere
Minuten dauern.

Also sollt das in etwa so laufen

procedure DCFupdate;
begin
  if DCFready then
  // Setze RTC mit Werten aus DCF_ SECOND, DCF_MINUTE, DCF_HOUR
  // DCF_DAY, DCF_MONT H, DCF_YEAR, DCF_WEEKDAY
  endif
end;

Siehe im DocuStdDriver.pdf Seite 190

[Andreas H. (ahz)]

Pontius Pilatus schrieb:
> Signal ist Lupenrein, bis in den Traurigkeit kontroliert.

Pontius Pilatus schrieb:
> Der DCF treiber vom Avrco gebt sowieso nur erst ein signal wenn
> uberhaupt ein richtiges DCFsignal empfangen wurde.

Ich finde in Deinem Code nirgends eine Stelle, wo Du das überprüfst.
Also z.B. mit DCFready, bzw. DCFfield (Kapitel 3.39.1 im AVRco Standard 
Treiber Handbuch).

Hast Du Dir mal die DCF Demo angesehen, die mit AVRco mitgeliefert wird 
(..\E-Lab\AVRco\Demos\DCF77) ?

Hast Du mal versucht den RTC chip über DCFupdate zu programmieren ?

Grüße
Andreas

[Pontius P. (pontiuspilatus)]

Ich hab das jetzt am laufen gekriegt, allerdings noch mit ein Problem 
und ich weiss nicht was ich da falsch gemacht habe.
Ich habe einfach das hier eingefügt;

if MinuteSema then
      //Blinkenlights:= true;
      if DCFready then
       RTCsetHour(DCF_hour);
       RTCsetMinute(DCF_minute);
       RTCsetSecond(DCF_second);
     endif;
     
      BlinkTimer:= 10;
      MinuteSema:= false;
      minute:= DS1307getMinute;
      hour:= DS1307getHour;
      time_to_letters(hour, minute,false);
      LEDupdateRequest:= true;
    endif;

Also die vier Zeilen mit DCF rein. Auch wenn hier jetzt warscheinlich 
die Programierer vom Stuhl fallen, es funktioniert.
NUR: wenn es einmal kein gutes DCF-Signal gibt springt die Uhr wieder 
auf zwölf uhr nachts. Mache ich da etwas falsch mit "if DCFready then"?
Wenn das signal nicht gut ist sollte er doch eigentlich nichts machen?

[Pontius P. (pontiuspilatus)]

Ich habs jetzt mit DCFfield>180 gemacht, das scheint besser zu 
funktionieren.

[Pontius P. (pontiuspilatus)]

Doch nicht, gibt das gleiche Problem. Zwischendurch immer mal wieder 
zwölf Uhr nachts....

[Hans Ulli K. (Gast)]

Hmmm,

ich würde beide Werte nehmen,

if DCFready then
    if DCFfield > 180 then

ggf. auch noch ein "Flag", da es ja im Allgemeinen reicht einmal pro Tag 
den RTC zu setzen.

Wennst du noch ganz paranoid bist ggf. noch die Minuten mit dem dem 
"alten" Wert verleichen ...

[Pontius P. (pontiuspilatus)]

Vorne weg, bin kein Programmierer, ich spiele nur herum mit der gegebene 
Code.
Flag? keine Ahnung was das ist.
Das Problem sind aber nicht die voraussetzungen, die werden schon 
erfullt.
Aber sowie ich das verstehe bleiben die Werten Stehen. Also wenn 
DCFready einmal "true" ist bleibt das so und das gleiche wenn 
DCFfield>180 ist.

Ich bin jetzt dabei erstmal den ganzen DS1307 rauszuschmeissen und 
erstal das ganze nur mit den RTC am laufen zu bringen. Das lauft jetzt 
eigentlich schon seit eine Stunde. Dann sollte der DCF einfacher 
einzubinden sein.

[Hans Ulli K. (Gast)]

Pontius Pilatus schrieb:
> Vorne weg, bin kein Programmierer, ich spiele nur herum mit der gegebene
> Code.

Bin, ich ja auch nicht.
Mache da nur als Hobby ;-), aber schon etwas länger

> Flag? keine Ahnung was das ist.

Flag -> Status

DCFReady ist hier ein "Flag", das die Datenwörter DCF_Hour usw. gültig 
sind.

> Aber sowie ich das verstehe bleiben die Werten Stehen. Also wenn
> DCFready einmal "true" ist bleibt das so und das gleiche wenn
> DCFfield>180 ist.
>

seltsam.
Aber die Doku ist es auch.
Es steht nichts drin wenn das Signal mal verloren geht ...

Als Debug Option kannst du ja auch DCFReady auf einen nicht benutzten 
Ausgang legen


> Ich bin jetzt dabei erstmal den ganzen DS1307 rauszuschmeissen und
> erstal das ganze nur mit den RTC am laufen zu bringen. Das lauft jetzt
> eigentlich schon seit eine Stunde. Dann sollte der DCF einfacher
> einzubinden sein.

[Pontius P. (pontiuspilatus)]

Ich habe das vorher gemacht durch einfach;
If DCFready then
Blinkenlights = True;

In das Programm zu machen.
Das funktioniert auch, nach ein paar Minuten blinkt alles. Nur ab dann 
flakkert die Anzeige den ganzen Zeit, weil er das bei jeden 
Programmablauf machen will, weil das DCFready eben stehen bleibt.
So wie es aussieht passiert bei DCFfield das gleiche. Der maximumwert 
ist 255, aber ich glaube er geht nie zuruck auf 0.

Was ich auch nicht verstehe: wenn er ein paar minuten richtig mit DCF 
lauft und ich schalte hier eine Lampe ein damit das Signal gestört werd, 
springt er auf zwölf uhr nachts. Von wo kommt diese zwölf uhr??? Es wird 
doch nichts gereset? Und noch komischer ist das er dann schon normal 
weiter lauft, also nicht jede Minute zuruck auf zwölf uhr springt, 
obwohl das Signal immer noch gestört ist.

Alle sagen immer das das im Handbuch so gut beschrieben ist, dann bin 
ich wohl zu blöd das zu verstehen...

[Pontius P. (pontiuspilatus)]

Also, mit dieser Hex-Datei lauft die Uhr mit Dcf. Allerdings musste ich 
der Ds1307 rausnehmen. Das heisst das jetzt bei Stromunterbruch es 
wieder zwölf Uhr nachts ist bis er wieder ein richtiges DCF-signal 
bekommt.
Dcf und DS1307 zusammen wird sicher gehen, aber das wird der nachste 
Schritt. Irgendwie stören die zwei einander.