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.
"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/thclock/index.htm Peter
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.
@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
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
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.
>[..] >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...
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
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.
Hm, sorry, hab nicht in die header geguckt...ich habe darin die Prototypen vermutet! Aber das ist noch schlimmer g Gruß, Patrick...
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.
@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
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.
Da hat der liebe Kollege an unserem Internetanschluss seine ID hinterlassen... Das kam von mir. e.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.