www.mikrocontroller.net

Forum: Projekte & Code DCF77, Stoppuhr 1/1000sec, RC5-Dekoder, Rom-Only Menuesystem


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

Bewertung
0 lesenswert
nicht lesenswert
Da ich ab dieser neuen Version die Tastaturabfrage so geändert habe,
dass es mit allen Standard-RC5-Fernbedienungen funktionieren müsste,
ist das Ganze nun vielleicht auch für diejenigen interessant, die sich
nicht mit einer Anpassung herumschlagen wollten. Daher auch der neue
Thread.

Im Anhang gibt es u.a. auch eine README-Datei, die man sich anschauen
sollte.

Im Programm ist eine History erfasst, aus der alle alten und neuen
Features hervorgehen. Dort steht auch, welcher Compiler, welche
Hardware etc. etc.

Der DCF77-Dekoder ist jetzt SEHR gesprächig:

Es wird zu jedem Bit angezeigt, WAS da dekodiert wird (natürlich immer
nur eine Sekunde lang...)

Ganz links oben wird (beginnend mit Nr. 0) die Bitnummer der gerade
dekodierten Entität angezeigt. z.B. ist die Minute in 7 Bit codiert,
der Wochentag in 3 Bit. Beim Wochentag wird also nacheinander B0, B1
und B2 angezeigt.

Dahinter steht die Wertigkeit des betreffenden Bits, also 1, 2, 4, 8,
10, 20 usw.

Rechts oben stehen die Dekodervariablen fuer Stunde, Minute, Sekunde.
Minute wird erst ab Bit 21 angezeigt, die Stunde erst ab Bit 29 (ist ja
auch logisch), und zwar immer der Wert, den die jeweilige Variable in
diesem Moment (also z.B. in der 31.ten Sekunde) hat.

In der zweiten Zeile steht jeweils im Klartext, WAS da gerade dekodiert
wird (also z.B. MIN oder STD). Waehrend der Bits 15-19 wird ausserdem
im Klartext beschrieben, was diese Einzel-Bits bedeuten, und welchen
Wert sie haben, z.B: "Winterzeit: JA", auch jeweils immer für eine
Sekunde.

Waehrend der Datenbits zwischen 21 und 58 wird ausserdem die Reihe an
Nullen und Einsen, wie sie empfangen werden, fuer die jeweiligen
Entitäten angezeigt. Dahinter steht die Neu-Berechnung des aktuellen
Wertes. D.h, dass z.B. für die Bits 21-17 (Minuteninformation) in der
Minute 44 (!) dort folgendes auftaucht:

Displaypos: ----+----1----+-
Bit: 21     MIN 1          1
     22     MIN 01       + 0 = 1   << "+ 0" wird nach 0,5 Sek.
     23     MIN 101      + 4 = 5            überschrieben durch "= 1"

     24     MIN 0101     + 0 = 5
     25     MIN 00101    + 0 = 5
     26     MIN 000101   + 0 = 5
     27     MIN 1000101  +40 =45

Dabei wird die Information "+ 5" nach einer halben Sekunde durch das
Ergebnis "=45" überschrieben.

Warum "45" statt "44"? Weil IMMER DIE KOMMENDE ZEIT UEBERTRAGEN
WIRD. Also die, die ab der nachsten 0-Sekunde gueltig ist. Und genau so
waere das Ganze auch in einem System zu verwenden: übertragen aller
Dekoderinformationen an die Systemuhr in der Sekunde 59.

Für Tag/Monat/Jahr/Wochentag war zwar dediziert kein Platz mehr auf dem
Display, jedoch werden auch diese Werte logischerweise in der zweiten
Displayzeile "zu angemessener Zeit" angezeigt (ab BitNr. 36),

Auch die Paritätsinformationen (Bit 28, 35 und 58) werden natürlich
korrekt ausgewertet und angezeigt:

Displaypos: ----+----1----+-
            Paritaet: OK
oder        Paritaet: FEHLER

Die DCF77-Dekodierung ist sicher das Schmankerl an diesem Programm.
Aber auch die Stoppuhr oder die RC5-Dekodierung sind nuetzlich. Es gibt
6 Zeitbasen zwischen 500us und 10 Sek (2000 Hz bis 0,1Hz), und alle
sfunktioniert gleichzeitig, parallel und wild durcheinander. Es wurde
dabei nur ein einziger Timer verwendet, sonst nichts.

Kritik ist immer willkommen.

e.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Die DCF77-Dekodierung ist sicher das Schmankerl an diesem Programm."

Kann ich überhaupt nicht finden. Deine Routine ist bestenfalls nur die
halbe Miete.
Es interessiert doch nicht die Bohne, wann welches Bit reinkommt und
ich will auch nicht im Kopf immer eine Minute abziehen müssen.

Der Benutzer will einfach, daß immer die richtige Zeit sekundengenau
angezeigt wird, auch wenn der Empfang mal ne Weile gestört ist.
Und das geht viel besser so:

http://www.specs.de/users/danni/appl/soft/c51/thcl...


Peter

Autor: emax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit so wenig Übersicht habe ich nun wirklich nicht gerechnet.

Das ist hier keine "Anwendungsammlung" sondern eine "Codesammlung".
Ich denke da an weniger geniale Menschen wie Dich, die tatsächlich auch
mal was zur Veranschaulichung haben möchten, und nicht vor Genialität
die Arme nicht mehr an den Leib bringen.

Warum Du deine Superlösungen nicht hier rein stellst, versteh ich auch
nicht. Wenn ich da irgendwas jenseits Deiner Pissmarken veranstaltet
haben sollte, dann sorry, ich wollte ich Dich nicht verunsichern.

Nochmal sicherheitshalber: Du bist der Groesste.

e.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Emax

Daß Du Dich gleich auf den Schlips gepißt fühlst, damit habe ich nun
wirklich nicht gerechnet.

Aber wenn Du schon etwas als "Schmankerl" bezeichnest, dann must Du
Dir auch gefallen lassen, daß das jemand ernst nimmt.

Und ein "Schmankerl" ist nun wirklich erst dann was, wenn es auch
komplett in Sack und Tüten ist, und nicht nur ein kleiner Codefetzen
davon.


Klar habe ich überhaupt nichts dagegen, wenn man auch Teillösungen in
die Codesammlung stellt. Aber dann bitte nicht großkotzig als
"Schmankerl" titulieren.


Peter

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
P.S.:

Ich finde es gar nicht schön, wenn jemand erstmal scheinheilig
Kommentare wünscht:

"Kritik ist immer willkommen."

Und dann aber auf freundliche Hinweise, daß dem Programm noch einige
entscheidende Verbesserungen gut stehen würden, gleich aber sowas von
ausfallend wird :-(


Peter

Autor: emax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Deutsche Sprache, schwere Sprache...

"Und ein "Schmankerl" ist nun wirklich erst dann was, wenn es auch
komplett in Sack und Tüten ist, und nicht nur ein kleiner Codefetzen
davon."

Das Wort "Schmankerl", lieber Peter, stammt aus dem Österreichischen
und heisst soviel wie "leckere Kleinigkeit". Und genau das habe ich
gemeint: eine "Kleinigkeit".

Was die Kritik anbelangt: formulier die doch mal, das einzige, was ich
bis jetzt von Dir gelesen habe war etwas von "entscheidenden
Verbesserungen", die Du aber nicht weiter beschreibst, und das Du mich
als grosskotzig bezeichnest.

Die spannende Frage ist also: was meinst Du bloss mit den
entscheidenden Verbesserungen?

Was das Thema "auch wenn der Empfang mal ne Weile gestört ist.", so
hast Du wohl irgendwie nicht kapiert, um was es eigentlich geht: Das,
was da angezeigt wird, ist keine Uhr, sondern die Visualisierung des
DCF77-Protokolls und des Dekoderzustandes.

Ich fass' noch mal für Dich zusammen: Das Schmankerl sollte nur auf
eine nette Kleinigkeit hinweisen, und die konstruktive Kritik konnte
ich bisher nicht entdecken. Sie ist aber nach wie vor willkommen.

Und zum Thema Grosskotzigkeit ist das hier:

"Und das geht viel besser so:..."

wohl die neue Art von Bescheidenheit oder was?

Liebe Gruesse,
Dein Emax.

Autor: OldBug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>[..]
>idiotischer Weise ist das Protokoll mehrfach redundant
>[..]

Das hört sich so an, als wäre das alles überflüssig.
Dann hast Du versucht, die Prototypen auszulagern, packst aber den
ganzen code wieder in ein File (main.c). Das finde ich nicht sehr
übersichtlich.
An ein paar Stellen fehlen wichtige kommentare...

Ansonsten ganz ok...

Ich hoffe, das war jetzt "konstruktiv" genug!

Gruß,
Patrick...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Deutsche Sprache, schwere Sprache...

"leckere Kleinigkeit" würde ich in Bezug auf Software etwas nennen,
was auch rund ist.

Z.B. wenn ich ein Softwarebeispiel zur AD-Wandlung machen würde, dann
ist es nicht damit getan, die Wandlung zu starten und den Hex-Wert
auszulesen. Die meisten Leute haben damit keine Schwierigkeiten, jedoch
damit, daraus z.B. einen Wert 0..5V zu basteln.

Analog dazu sehe ich eben das Hauptproblem beim DCF-77 eine stimmende
sekundensynchrone Zeitinformation zu bekommen.

Ich bin halt Praktiker und gehe immer davon aus, daß irgendwie auch was
praktisch nutzbares dabei rauskommen soll. Wenn das in Deinen Augen ein
Fehler ist, dann gebe ich ihn zu.


"Und das geht viel besser so:..."

War wohl etwas mißverständlich. Ich meinte damit nicht die
programmtechnische Umsetzung sondern das praktisch nutzbare Ergebnis,
als die stimmende sekundensynchrone Zeitinformation.


Peter

Autor: emax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fuer die, die nicht ins Programm gesehen haben, das hier
>[..]
>idiotischer Weise ist das Protokoll mehrfach redundant
>[..]
habe ich in der Source verzapft.

"Das hört sich so an, als wäre das alles überflüssig."

Nicht alles. Aber die Wertigkeiten 1,2,4,8,10,20, etc. sind nun mal
nicht ideal für die Verarbeitung. Der Wert "10" beispielsweise ist
redundant, denn er kann auch als '2+8', also in zwei Bit, statt in
einem dargestellt werden. Aber wem erzähl ich das. Fest steht
jedenfalls, das DIESE Art Redundanz wirklich überflüssig ist, weil sie
nur bei manchen Bits gegeben ist, bei anderen aber nicht. Und sowas is
t im Grunde Unsinn. Die Paritätsbits dagegen sind äusserst nützlich,
besonders in kritischen Anwendungen.

Hätte man die Wertigkeiten nicht mit 10,20 etc. versehen, sondern mit
16,32 usw, so haette man sogar ein paar Bit einsparen, und dafür höhere
Paritätsanforderungen implementieren können.

Ich werde die Sache mal mit Herrn Prof. Hilberg diskutieren, er hat
dieses Protokoll erfunden und wohnt keine eine Strasse unterhalb von
mir.

"Dann hast Du versucht, die Prototypen auszulagern,"

Stimmt nicht. Es gibt keine Prototypen. Die Funktionen sind so von oben
nach unten angelegt, dass das nicht nötig war,

Wenn doch, dann sag mir wo.

"packst aber den ganzen code wieder in ein File (main.c). Das finde
ich nicht sehr übersichtlich."

D'accord, sehe ich auch so. So mache ich das in meinen eigenen
Projekten auch nicht. Da gibt es für jede Funktion ein eigenes
(!)Sourcefile, eine Angewohnheit aus dem Bibliotheksbau. Allerdings
habe ich das hier bewusst anders gemacht. Wenn ich so sehe, was für
Probleme manche Zeitgenossen mit einem simplen Makefile fuer EINE
Sourcedatei haben, dann denke ich mir, werden einige das Ganze in
verschiedenen Sourcefiles erst recht nicht gebaut kriegen. Deshalb
alles in einer Datei. Gefällt mir selber nicht.

Übrigens vermute ich in der Codesammlung auch eine Suchecke fuer viele
Einsteiger. Und genau für die ist ein dickes main.c in Sachen make etc.
vermutlich am Einfachsten zu handhaben. Und die Profis zerpflücken sich
das eh' so wie sie's brauchen.

"An ein paar Stellen fehlen wichtige kommentare..."

HmHm. Wahrscheinlich hast Du recht. Was man selber schreibt, ist einem
selber halt auch immer irgendwie ganz klar. Wenn Du mir da Konkretes
sagst, dann hole ich es gerne nach.

"Ansonsten ganz ok..." thnx.

@peter
"Ich bin halt Praktiker und gehe immer davon aus, daß irgendwie auch
was praktisch nutzbares dabei rauskommen soll"

Da haben wir eine Menge gemeinsam. Aber Du musst schon auch mal lesen,
was ich ganz oben geschrieben habe, ich zitiere nochmal:

"Und genau so waere das Ganze auch in einem System zu verwenden:
übertragen aller Dekoderinformationen an die Systemuhr in der Sekunde
59."

Das kann nicht so ein grosses Problem sein, als das man das extra
ausprogrammieren müsste.

Es gibt immer zwei Wege, eine Sache zu lösen: ich krieg was fertig
nutzbares, und verwende es, oder ich kapiere das Problem und löse es.

Im ersten Fall ist alles solange gut und schön, bis was schiefgeht,
Dann steh ich da mit der vorgekauten Lösung.

Im zweiten Fall kann ich mir selber helfen. Genau dahin zielt meine
Spielerei (als das empfinde ich es): Visualisierung des Protokolls und
des Dekoders.

Es war viel aufwendiger, den ganzen Zirkus auf dem Display zu
veranstalten, als schlicht die Systemuhr einmal in der Minute zu
synchronisieren. Deshalb habe ich nicht im Ernst angenommen, jemand
könne das für die fertige Lösung einer genauen Systemuhrzeit halten.

Wenn Du das Ganze mal im Zusammenhang mit der gezeigten Stoppuhr und
den implementierten Zwischenzeiten siehst, müsste erst recht klar sein,
dass man mit den gebotenen Beispielen locker in der Lage sein müsste.
hieraus eine korrekte Systemzeit zu bekommen. Dafuer ist es gedacht,
und nicht als vorverdaute Plug and Play Lösung für all die Überflieger,
die sich mit Grundsätzlichem gar nicht auseinandersetzen wollen, und
dann hier so intelligente Fragen stellen wie: "mein Code geht nicht,
woran kann das liegen", die hab ich nämlich am allerliebsten.

Und damit meine ich nicht Dich, ich habe Deine Arbeiten z.T. ja schon
gesehen, und weiss, dass sie professionell sind.

Veilleicht haben wir überdies noch zwei sehr unterschiedliche Motive in
dem was wir tun. Ich für meinen Teil bin jedenfalls sehr verspielt, und
deshalb kommt bei meinen Bemühung auch oft Spielzeug heraus. So what?

Gestern Abend habe ich im fernsehen einen Bericht über Artur Fischer
gesehen, der Mann mit den Dübeln.

Seine Fischertechnik, mit der heutzutage Tausende von Ingenieuren Ihre
Simulationen und Modell-Protoypen bauen, entstand nur, weil Artur
Fischer eigentlich Spielzeug für die Kinder seiner besten Kunden
konstruieren wollte.

Ich bin sicher nicht Artur Fischer. Aber auch wenn ich was Verspieltes
mache, dem es vielleicht am Deutschen Ingenieurs-Ernst mangelt, so
kanns doch trotzdem eine Leistung sein, und trotzdem gute Lösungen
aufzeigen.

Finde ich jedenfalls.

e.

Autor: OldBug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, sorry, hab nicht in die header geguckt...ich habe darin die
Prototypen vermutet!

Aber das ist noch schlimmer g

Gruß,
Patrick...

Autor: emax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jajaja, eigentlich gehören die da rein, ich weiss.

Aber bis jetzt war noch keine Zeit, und da die Funktionen z.Zt. so
angelegt sind, dass es keine Prototypen braucht, hatte das noch keine
Priorität.

Hab' ja geschrieben, dass das normalerweise bei mir auch anders
aussieht.

Ok, werde ich mir für eine der nächsten Änderungen vormerken.
e.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Emax

"Wenn Du das Ganze mal im Zusammenhang mit der gezeigten Stoppuhr und
den implementierten Zwischenzeiten siehst, müsste erst recht klar
sein,
dass man mit den gebotenen Beispielen locker in der Lage sein müsste.
hieraus eine korrekte Systemzeit zu bekommen."


Du hast natürlich recht, voll implementierte Lösungen verleiten nicht
gerade dazu, sie auch verstehen zu wollen.

Aber manchmal steckt der Teufel im Detail:

Ich habe z.B. lange gegrübelt, wie ich die interne Uhr, die ja zur
Überbrückung von Empfangsstörungen unbedingt notwendig ist, am besten
mit dem DCF-77 synchronisiere.
Z.B. hatte ich ab und zu mal den Effekt, daß die Anzeige eine Minute
lang eine Sekunde vorging.
Des Rätsels Lösung war, daß der DCF-77 Impuls ganz kurz vor dem
internen Überlauf kam (die laufen ja nie 100% synchron).
D.h. das DCF-77 Signal stellte die Uhr, gleichzeitg lief der
Sekundeninterrupt über und zählte noch eine Sekunde dazu
(57->58->59->01).

Deshalb habe ich extra die Funktion syn_sec() eingeführt, die sowohl
den Vorteiler rücksetzt als auch einen eventuellen überzähligen
Sekundenimpuls.


Peter

Autor: Gero Deister (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist in der Tat ein Problem, dass ich für mich selber noch als
ungelöst betrachtet hatte. Ich werd mir deine syn_sec Funktion mal
anschauen.

Es gibt aber auch einen faulen Trick: man lässt die Uhren
(DCF+Systemuhr) einfach 2-3 Zehntel ungenau gehen, die Systemuhr geht
also schlicht 2-3 Zehntel falsch. Mit dieser Sicherheitsreserve entgeht
man dem von Dir geschilderten Problem.

Natürlich ist das ein "fauler" Trick. Aber wenn Du mal bei den
Bahnhofsuhren schaust, dann ist es dort noch extremer (so war's
jedenfalls früher): die Sekundenzeiger der Bahnhofsuhren liefen immer
viel zu schnell, so dass sie bereits 2-3 Sekunden vor der Realzeit bei
60 Sekunden "angekommen" waren.  Dort "warteten" sie dann auf ihren
T+N Trigger, und liefen dann weiter. Auf diese Art hatte der
Sekundenzeiger zwar einen Fehlgang von fast 5%, aber insgesamt gingen
die Uhren doch nie falscher als etwa 2-3 Sekunden. Wahrscheinlich
hatten die für den Fall, das T+N nicht funktionierte, einen
Ersatz-Trigger, vielleich sogar sowas simples wie ein R/C-Glied).

Übrigens sind die Quarze erschreckend ungenau: Meine Systemuhr ging
(ohne DCF) nach 24 Stunden ungefähr 18 Sekunden vor!! Das ist etwa ein
halbes Prozent, durchaus schon signifikant sogar für ganz normale
Küchenuhren. Und die 1/1000 Stoppuhr (eben auch eine Spielerei) geht
schon nach 3 Sekunden um 1 Digit falsch...

Das ist überhaupt der Grund, warum ich mit der DCF-Geschichte
angefangen habe.

Laut OSZI ist der DCF-Impuls an der steigenden Flanke wirklich 100%
genau, (also davon muss man ja wohl auch ausgehen können ...),
jedenfalls genauer als ich mit meinem Tektronix messen kann

Wenn man nun diese Flanke auf einen Interrupt legt, könnte man
wunderbar messen, wie genau oder ungenau der eigene Quarz ist.

So etwa 100 oder 1000 Sekunden abwarten, und dann einen Timer auslesen
und mit dem Sollwert vergleichen.

Vielleicht mach ich das mal, oder wenns ein anderer macht, noch besser,
(ich hab' nämlich im Moment genug ge-DCF-t).

bis denne
e.

PS: man kann sich durchaus mal hauen, aber ich finds schon gut, wenns
dann wieder ruhiger wird.

Autor: emax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da hat der liebe Kollege an unserem Internetanschluss seine ID
hinterlassen...
Das kam von mir.

e.

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.