DCF77 und RTC mit ATmega unter BASCOM

[Markus]

Hallo zusammen,

möchte Euch heute ein weiteres spannendes Thema vorstellen. Nämlich den DCF77 Funkuhrempfang mit einem ATmega128 sowie die Unterstützung einer Real-Time-Clock DS1307 unter BASCOM.

Dazu ist vorab zu sagen, das BASCOM einem die Arbeit durch die vorhandene Bibliothek weitgehend abnimmt. Das ganze besteht in BASCOM im wesentlichen aus dem CONFIG DCF77 Statement. Dahinter verbirgt sich die komplette Abtastung des DCF77 Funkuhrsignals, eine komplette SoftClock mit automatischer Synchronisation und die Generierung eines Sekundentakts. Total genial, einfach und simpel.

Zum Einsatz kommt das DCF77 Funkuhrmodul der Firma Conrad. Es hat sich bzgl. der Empfangsqualität bestens bewährt. Darüber hinaus bietet es einen invertierten und einen nicht-invertierten Ausgang.
Zur Signalaufbereitung fahre ich in meinem Beispiel noch über einen NAND-Schmitt-Trigger. Das gefällt dem ATmega ganz gut

Hintergrund:
Ich suchte nach einer Lösung eine SoftClock via DCF77 zu synchronisieren. Bei erfolgter Synchronisation werden die Zeit und Datumsinformationen in der RTC DS1307 abgelegt die mit einer Stützbatterie gepuffert ist.
Auf diesem Weg ist es möglich - falls man gerade keinen DCF77 Empfang hat - oder bei Systemstart gleich mit realen Zeitwerten aus der RTC zu starten.
Außerdem kann man zur Entlastung des Systems die DCF77 so konfigurieren, das man nur jede Stunde oder einem in 24 Stunden neu synchronisiert. Die restliche Zeit holt man sich ggf. die Zeitwerte aus der RTC.
Der Code und die Zeitauswertung ist von mir bewußt so realisiert, das ich grundsätzlich auf den Variablen der SoftClock arbeite.

Ressourcen:
Eigentlich werden nur der Timer 1 und ein beliebiger Eingangspin als Ressourcen zum Betrieb benötigt.
Möchte man den RTC noch verwenden so benötigt man für das HW TWI-Interface die freien PINs für SCL und SDA.
Mittels SW TWI-Interface kann man zwei beliebige PINs verwenden.

Also, was gibts zu sehen:
- Beispielcode für die DCF77 Anbindung unter BASCOM
- Beispielcode für die Anbindung der RTC DS1307 an den ATmega über TWI-Interface
- Schaltbild für die Anbindung der DCF77 von Conrad
- Schaltbild für die Anbindung der RTC
- Bilder der Prototypen

In Betrieb genommen habe ich das ganze mit dem STK500 und STK501 mit einem ATmega128 16Mhz extern.

Zur Funktion:
Die Routinen für DCF77 und RTC sind wie üblich in ausreichend kommentiertem Code und Test-/Beispielsequenzen eingepackt.
Bei Systemstart wird die SoftClock einmalig mit den aktuellen Zeitwerten der RTC geladen.
Die DCF77 Routinen beginnen sofort mit ihrer Arbeit und dem Dekodieren des Zeitsignals. Das meiste davon übernimmt die DCF77 Lib von BASCOM. Denkbar einfach also.
Wenn die Zeit- und Datumsinformationen ganzheitlich empfangen wurden und BASCOM die eigene SoftClock synchronisiert (Auswertung eines Sync-Bits) wird auch die RTC gestellt.
Darüber hinaus gibt es in der Konfiguration noch eine "CallBack-Routine" welche sectic heißt und welche pro Sekunde durch die SoftClock einmal aufgerufen wird. Mit dieser Routine ist es möglich einen Sekunden-Systemtakt zu erzeugen oder Ausgaben zu machen oder einen einfache Time-Scheduler für bestimmte Aufgaben aufzuziehen. Der Fantasie sind hier keine Grenzen gesetzt.

Zur LCD-Ausgabe:
Neben den Zeit- und Datumsinformationen gebe ich auf dem LCD-Display noch den binären dcf_status und die dcf_bits aus. Damit kann man ganz gut die Funktion überrüfen.
Mit einem Stern kennzeichne ich den Zeitpunkt zu dem erstmalig gesynct wird und mit einem Zähler (unter dem Stern) gebe ich die Anzahl der von Systemstart an erfolgten Synchronisationen an.

Ist ein ziemlich spannendes Thema. Schaut es Euch einfach mal an, probiert es aus und wenn es Fragen gibt dann meldet Euch!

Grüße,
Markus

 

[NorbertG]

DCF-Uhr

Hallo,
Toll, genau das, was ich suche!
ich würde gerne die Uhr 'standlone' (nicht mit den STK-Boards) nachbauen.
Hast Du das schon realisiert?
Gruss,

 

[Markus]

Hallo NorbertG,

dein Wunsch ist prinzipiell kein Problem und auch sehr einfach umsetzbar weil:

- mein Code prinzipiell auf jedem ATmega funktionieren sollte.
- Du den ganzen Overhead für Test und Traces rausschmeißen kannst.
- die wichtigen Routinen frei konfigurierbar und anpassbar sind.

Ich würde sagen, mit ein bissle probieren kannst Du 90% so lassen wie der Code ohnehin schon ist. Du musst eigentlich nur die Konfiguration für die PIN's und ggf. den Treiber für ein anderes LCD-Displax einsetzen.

Das STK500 verwende ich in diesem Fall eigentlich nur als "Aufnahme" für meinen ATmega128, als Spannungsversorgung und als RS232-Schnittstelle für den Trace-Output. Ansonsten hängen die einzelnen Komponenten direkt am Mega.

Das zum Prinzip, also probiers einfach mal aus


Noch einige präzisere Antworten zu Deiner Frage:

Nein, ich habe die SW bisher nur auf dem STK500 am laufen aber sie ist vom STK500 völlig unabhängig. Mein Ziel ist es auch die SW auf einem eigenen Target zum laufen zu bekommen. Hintergrund was ich hier so treibe ist der Bau einer Wintergartensteuerung mit ner ganzen Menge Teilfunktionen und Features.
Bisher bin ich über das Prototypen-Stadium noch nicht hinaus da ich erst noch eine Tastaturmatrix und LED-Matrix zum Laufen bekommen möchte.

Als nächstes werde ich ein ATmega128 Standalone-Board umsetzen was die wichtigsten Funktionen wie RS232, ISP, JTAG, Rauschreduktion für ADC usw. beinhaltet und über dessen Ports ich dann meine ganzen Einzelfunktionen von denen ich einen großen Teil hier im Forum schon als Einzelthemen veröffentlicht habe anbinde.
Mein Ziel ist es zum Schluss alles auf einer PCB zu haben die ich dann von Leiton professionel fertigen lassen möchte.

So, weiter bin ich noch nicht aber der Schaltplan für ein Standalone-ATmega128 ohne STK500 findest Du im Anhang. Der Schaltplan ist aber ohne Gewähr da er bisher nur in meinem Kopf und auf Papier existiert und noch nicht ausprobiert ist. Es kann sein das ich hier noch Fehler drin habe oder Dinge übersehen habe. Prinzipiell handelt es sich aber um Basisbeschaltungsteile welche auch auf andere ATmegas anwendbar sind.

Prinzipiell ist es bei meinem DCF77 Code egal ob Du auf dem STK500 sitzt oder auf einem anderen EVA-Board oder auf einem ATmega8 den Du in eine Lochraster-PCB genagelt hast. Einfach Ports umkonfigurieren, den für Dich überflüssigen Code rausschmeißen und los.
Du hast das Glück das ich versuche meine Sourcen immer sauber zu kommentieren, ergo dürftest Du Dich schnell zurecht finden. Wenn noch Fragen sind melde Dich einfach!

Viel Spaß dabei und gutes Gelingen,

Markus

 

[brutzler]

Hallo Markus,

habe auch gerade ein Conrad DCF an meinen Mega664 gehängt um mal die Zeit auszulesen. Bei dem schlechten Wetter ein schönes WE-Projekt.

Bin allerdings kein Profi auf Bascom

Wenn ich deinen, von mir, abgespeckten Code überprüfen oder compilieren will, dann bekomme ich immer Fehlermeldungen, wenns um die DCF-Routinen geht.
Anscheinen fehlt mir da irgendeine Link zur Bibliothek.
Muss da noch ein $include oder $lib in den Code oder wo haperts da bei mir???

Ach ja: die dcf77.lib find ich nirgends; nur die dcf77.lbx.
Habe Bascom 1.11.8.7


Nachtrag.
Habs auch mal mit der test_dcf77.bas von Bascom probiert. Da gehts mir auch nicht besser.
Compiler mault schon beim CONFIG rum.

 

[Markus]

Hi, guten Abend!

Verwendest Du eine BASCOM Demo Version in der Version 1.11.8.7 oder hast Du eine vollständig Lizenz? Also mal kurz zum Abgleich: Ich verwende schon seit langem die Version 1.11.9.0 als vollständige Lizenz. Seit einigen Tagen ist auf der MSC Homepage auch schon die Version 1.11.9.1 zu haben. Ich würde Dir empfehlen auf jeden Fall ein Update zu machen.

So, dann zu Deinem Problem:

Normalerweise lädt BASCOM die Library automatisch wenn er das Statement "Config DCF77" findet. In meinem Beispielcode lade ich die dcf77.lib auch nicht explizit mit dem $lib Kommando. Zur Sicherheit kannst Du ja mal die Lib im Programmkopf mit

$lib "dcf77.lbx"

von Hand laden.

Dass Du in den Verzeichnissen von Bascom aber nur die LBX findest ist nicht ganz plausibel. Da kann ich nix zu sagen. Ich selbst habe im Verzeichnis
C:\....\MCS Electronics\BASCOM-AVR\LIB beide Dateien. Sowohl die dcf77.lbx als auch die dcf77.lib. Beide Dateien stammen vom April 2007 und sollten eigentlich bei der 1.11.8.7 auch vorhanden sein.
Es gibt aber von BASCOM-Version zu BASCOM-Version teilweise größere Unterschiede und in den letzten Versionen sind einige Bugfixes und Ergänzungen eingeflossen.

Würde sagen, probiert erst mal Punkt 1, dann Punkt 2 und dann teile mir Deine Erfahrungen mit.

Grüße,
Markus

 

[brutzler]

Hallo und danke für die Antwort.

Ich hab nur die Demo. 80 Euro sind viel Geld für einen Studenten. Und bis jetzt hat mir die Demo immer gereicht.

Was ich nicht verstehe: Die Demo ist doch nur von der Codegröße begrenzt, (dachte ich)
Und jetzt muss ich wohl feststellen, daß da doch mehr Unterschiede sind???

Ich jedenfalls finde keine DCF77.lib in meinem \lib Verzeichnis

 

[Markus]

Ich kann nicht mit Bestimmtheit sagen das der Unterschied zwischen Demo und Vollversion herrührt. Jedenfalls gibt es die 1.11.9.1 auch als Demo soweit ich weiß. Ich würde mir zumindest mal die aktuelle Demo holen und sehen ob DCF77 damit "besser" funktioniert!

 

[brutzler]

Hallo

Gerade getestet. Keine dcf77.lib dabei

 

[Markus]

Hmmmmmm,
Ratlosigkeit macht sich bei mir breit

Schick mir mal Deinen "abgespeckten" Code. Möchte ihn bei mir mal kurz compilieren und ausprobieren. Dann kann ich Dir vielleicht mehr sagen.

 

[brutzler]

Puhhhh,

hab die Demo jetzt nochmal installiert, vorher die alte Demo deinstalliert. Das ganze 2-3mal und dann liefs auf einmal.


Und jetzt gehen die Probleme erst richtig los.....

Ich hab dir mal den Code angehängt. Hab ihn gekürzt, bis er fast wie das Testprogramm von Bascom aussieht. Angepasst an mein AVR, an mein 2-zeiliges LCD und meine (einzige) serielle Schnittstelle.
Irgendwas krieg ich auch über den Empfänger rein. Aber ob das eine Zeit/Datum ist. Hab mir schon den Kopf kaputtgerechnet mit BCD hin und her, aber was vernünftiges kam nicht bei raus.

Angeschlossen hab ich den DCF-Empfänger wie bei http://www.wolfgang-back.com/PDF/DCF77.pdf
Seite 2.
Da ich die gesamte Kiste über meinen USB-Programmierer (von myAVR) versorge hab ich nur 4,6V. Ja ich weiss, das sind keine 5V.....

Ich hab mal ein Terminal-Log drangehängt. Ist das Schrott was rauskommt, oder ist das gut? Wenn Schrott...hast du mal ein Log wie es aussehen soll?


Danke schon mal für deine Hilfe.

 

[brutzler]

Hab jetzt mal "inverted = 1" gesetzt.

Ich nehm ja den invertierten Pin vom DCF.

Aber der Wurf wars auch nicht.
--> Neues Log im Anhang

 

[brutzler]

Ei guck....

jetzt hab ichs...

lag wohl etwas am Empfang

Und........... "Inverted =1" muss sein!!!!


Jetzt kann ich beruhigt schlafen gehen.

 

[brutzler]

Moin,

noch ne Frage:
----------------------- SCHNIPP ------------------------
' Die Impulslänge sollte zwischen 2 und 8 liegen
' Die Pausenlänge sollte zwischen 70 und 90 liegen
----------------------- SCHNAPP ------------------------
Sieht bei mir aber etwas anders aus (und geht trotzdem)

Impulslänge ist so in dem angesprochenen Bereich.
Aber die Pausenlänge ist meistens zwischen 30 und 35. Ausser in der Sekunde, in der er synchronisiert. Dann liegt die bei ca. 70.


Spricht eigentlich etwas dagegen, den Programmteil aus der Hauptschleife in die Sectic-Routine zu verfrachten? Natürlich ohne die beiden Schleifenzähler.
Ich will ja mit dem AVR noch etwas anderes machen. Und die Zeitgeschichte soll im Hintergrund laufen.

 

[Markus]

Hi, Glückwunsch!!!!

Jetzt bin ich mal ein Tag nicht online bzw. habe keine Zeit auf offene Fragen zu antworten und dann beißen sich die Leute plötzlich selber durch technische Probleme.

Die Idee mit dem Empfang und mit dem Inverted / Nichtinverted hatte ich heute morgen schon. In meinem Beispiel hatte ich in der Beschaltung zur "Normierung" des Signals noch einen Schmitt-Trigger zwischen drin. Aus diesem Grund war IST nicht gleich SOLL.
Du bist selber drauf gekommen und der Lerneffekt war damit MAXIMAL! Ich freu mich für Dich!

Ja, der Empfang ist teilweise schon ein wenig kitzelig. Ich habe in meinem Büro am Schreibtisch auch immer wieder Probleme mit dem Empfang so dass ich die Antenne etwas verlagern muss. Lauter 1sen bei den DCF77 Bits deuten prinzipiell immer auf ein Empfangsproblem des Signals hin.
Übrigens, habe mal bei mir aktuell nachgesehen und meine Zeit liegt auch so zwischen 30 und 40. Aktuell erreiche ich auch die 70-90 nicht.

Weiter zu Deiner Frage mit dem sectic. Ich beziehe mich bei meinen Aussagen auf meinen Original-Code.
Prinzipiell kannst Du dort drinne reinpacken was Du möchtest. Der Code (auch das Beispiel von BASCOM) bieten ja nur einen groben Rahmen der zum experimentieren einladen soll.
Die Routinen in der Main-Loop dienen größtenteils auch nur dem Test und können sogar ganz entfallen.

Es ist allerdings so, dass die Main-Loop-Routine prinzipiell so aufgebaut ist, dass auf jeden Fall ein Output erzeugt wird. Wenn der Timer nicht mehr laufen sollte (aus welchem Grund auch immer) oder wenn garkein DCF77-Update erfolgt. Schau Dir dazu meinen Kommentar im Original-Code an. Wenn Du nun den Codeteil aus der Main-Loop raus nimmst und in den sectic packst dann kann es sein dass Du bei einem Programmfehler wo der Timer steht garkeinen Output mehr bekommst.

Dann synchronisiere ich ja auch noch in der Main-Loop. Prinzipiell kann man das in der Routine sectic machen, wieso nicht, geht schon.

Eine passende Antwort kann ich eigentlich auf Deine Frage nicht geben da das Beispiel zum "Spielen" einladen soll. Probiers einfach aus und bau das Programm so um, das es zu dem UseCase passt den Du realisieren möchtest.

Eine Uhrzeit hast Du ja jetzt schon mal und das finde ich gut!

So, dann schlaf mal gut und hab weiter Spass beim "Basteln".

Grüße,
Markus

 

[mashpeak]

Hallo Markus,
ich bin heute über dieses Projekt gestolpert und möchte es ausprobieren. Nun meine Frage: Funktioniert es auch ohne den 74HCT14 oder ist er zwingend für die Signalaufbereitung notwendig?

Viele Grüße mashpeak

 

[Markus]

Hi mashpeak,

bin mir sicher, dass es auch ohne HCT14 funktioniert. Du musst in diesem Fall nur den anderen Ausgang am Modul verwenden oder in der Konfiguration für die DCF77 die Invertierung drehen da der HCT invertiert.

Ich selbst habe in meinem Projekt "kontaminierte" Umgebung da ein Dimmer noch werkelt und ich 230V-Dampf auf Leitungen habe. Deshalb habe ich das Ding mit einem Schmitttrigger aufbereitet.

Zwingend ist er nicht!

Grüße,
Markus

 

[mashpeak]

Hallo Markus,
danke für die schnelle Antwort.
Gruss mashpeak

 

[Topuser]

Hallo Markus,
bin vor ein paar Tagen auf dein Projekt gestoßen, hab sowas schon lange gesucht.
Ich habe mir ein Testboard mit einem Mega 32 zusammengenagelt, was ausgezeichnet funktioniert. Die abgespeckte Version von brutzler habe ich angepasst und geladen... voila, läuft prächtig!

Leider läuft deine Originalsoftware nicht und produziert haufenweise Fehlermeldungen (Anpassungen wie bei brutzler).
Der compiler meckert mich an, dass der Mega32 nur eine UART hat... o.k., das darf er.
Nehme ich jedoch die entsprechenden Softwareteile heraus (nur noch COM1 ist aktiv), bekomme ich haufenweise Fehlermeldungen (Code 61 und 221). Bin an der Stelle etwas ratlos... hast du eine Idee oder sehe ich vor lauter Bäumen den Wald nicht mehr?
Schonmal Danke bis hierhin.
Gruß
topuser

 

[Markus]

Hallo Topuser,

ja, der Mega16/32 hat nur eine einzige RS232 Schnittstelle. Ist aber nicht weiter schlimm! Was etwas schlimmer ist, das ich aus der Ferne nicht genau sagen kann was Ihr aus meinem Code rausgeschmissen und was Ihr umgebaut habt. Deswegen kann ich nicht genau sagen was in Deinem Code falsch läuft und mit den Fehlernummern allein lässt sich nix anfangen.

Also, prinzipiell sollte jeder der Probleme hat den Code entweder in einem Code-Fenster einfügen oder als Datei anhängen. Dann kann man nämlich in BASCOm das Ding mal versuchen zu kompilieren und "mann" kommt dann schon schneller auf den Fehler.

Ist leider in Deinem Fall nicht probiert, ich stehe auf dem Schlauch! Aber probieren wir es mal durch reines Überlegen und mit Trockenübungen

Also, Meda16 und Mega32 haben nur eine RS232, der Mega128 von mir hat aber 2 -> OK! In meinem Code verwende ich die COM2 lediglich um in der Service-Routine des SECTIC ein "*" auf der COM2 auszugeben, als Testzeichen quasi "jawohl ich lebe und pinge jede Sekunde ein *" Darauf kannst Du gerne un getrost verzichten.

Also, das einfachste hier mal aufzuräumen ist, die Initialisierung von COM1 und COM2 rauszuschmeißen. Nämlich:

' Com1 und Com2 für Trace-Output konfigurieren
Config Com1 = 38400 , Synchrone = 0 , Parity = None , Stopbits = 1 , Databits = 8 , Clockpol = 0
Config Com2 = 38400 , Synchrone = 0 , Parity = None , Stopbits = 1 , Databits = 8 , Clockpol = 0

Open "com1:" For Binary As #1                               ' Sitzt auf PE0 und PE1
Open "com2:" For Binary As #2                               ' Sitzt auf PD2 und PD3

Als nächstes solltest Du alle

Print #1 , "laber laber" oder
Print #2 , "laber laber"

durch reine

Print "laber laber" oder
Print "laber laber"

ersetzen.

Nun hast Du die Initialisierung über ein Device COM1 und COM2 völlig entkoppelt und das ist gut so. Wenn man nur eine COM hat dann bietet BASCOM den Standardweg. Der sieht für die Initialisierung der Schnittstelle wie folgt aus (als Beispiel):

$regfile = "m128def.dat"
$crystal = 16000000
$hwstack = 32
$swstack = 32
$framesize = 30

$baud = 38400

Relevant dabei ist nur der Befehl "$baud = 38400" für die richtige Baudrate die Du haben möchtest. Der Rest macht BASCOM allein. Verwende dann überall zur Ausgabe nur noch den reinen Print wie z.B.

Print "- finished -"
Print
Print value
Print BIN(value)

Das ist alles und wirklich kein Hexenwerk. Solltest Du dann immer noch Fehlermeldungen bekommen, hast Du zu viel rausgeschmissen, umgebaut oder Du hast noch irgendwo ein #1 usw. übersehen über das das jeweilige COM_Device angezigen wird.

Ach ja, übrigens solltest Du dann des CLOSE auch noch rausschmeißen, also raus damit mit:

' Offene Devices COM1 und COM2 schließen
Close #2
Close #1

Wenn's ned funzt dann bitte dringend Code zur Verfügung stellen damit wir wirklich explizit reinschauen können.

Viel Spass und viel Glück,

Markus

 

[Topuser]

Hallo, Markus,

du bist ein Held;-)

Genau dort, nämlich der Ausgabe #2 auf der COM2, lag der Fehler. Hab´s inzwischen bereinigt und läuft klasse.

Danke nochmal.

Zum HCT14 nochwas.
Mit dem Conrad-Modul läuft die Sache problemlos - auch ohne den HCT14.... man muss halt nur "invertet" richtig setzen;-)
Gruß
Topuser