Time$ , Date$ und Timerbenutzung

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Time$ , Date$ und Timerbenutzung

      Ich habe beim Durchblättern meiner Programme in einer Präambel folgende Bemerkung gefunden.
      '* Um Time$ und Date$ auszuwerten , darf Timer0 oder Timer2 nicht *
      '* aktiviert sein.
      Es handelt sich um eine Funkuhr mit 7-Segmente-LED-Anzeige und DCF77.
      Ich schreibe normaler Weise sowas nicht aus Jux und Dallerei da rein. Ich finde aber auch keinen
      Anhaltspunkt mehr, warum. Ich habe die Bascom Hilfe und meinen Freund Goockel bemüht, bisher
      ohne Erfolg.
      Ich kann mir nur vorstellen, das es was mit den ISR zu tun haben könnte. Bin aber nicht sicher.
      Jetzt hoffe ich auf die Schwarmintelligenz des Forums.
      Vielleicht kann mir da jemand auf die a_64_3a718cae Sprünge helfen.
      Detlef
      Leichtsinn ist kein Mut, Vorsicht keine Feigheit.
    • Ich kann mir das so vorstellen: die System-Variablen, die zu dem string time$ und date$ führen werden in einer isr geändert. Wertest du die während so einer isr aus, dann könntest du Zwischenergebnisse erwischen, weil ja die isr in deine Auswertung reinplatzen kann.
      Das gilt für alle Variablen >byte, die in einer isr verändert werden. Ein Bearbeiten solcher Variablen besteht in der Regel aus mehreren Schritten und zwischen jeden Schritt kann eine isr die Bearbeitung unterbrechen und die Variable ändern. Wenn jetzt nach der isr weiter gemacht wird, dann hat man teilweise schon mit dem Vorwert gearbeitet und macht mit dem Rest der Bearbeitung mit dem neuen Wert weiter. Das das zu Fehlern führen kann, ist, glaub'ich, klar.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • @tschoeatsch
      so ähnlich hab ich mir das ja auch vorgestellt.

      Dekaman schrieb:

      Ich kann mir nur vorstellen, das es was mit den ISR zu tun haben könnte. Bin aber nicht sicher.
      Aber auf solche Ideen komme ich ja nicht selber. Muss ich irgendwo gelesen haben, muss also auch
      irgendwo stehen. Das ist es , das mich so "wuschig" macht.
      Ich kann auch, wenn es gewünscht wird, das Programm einstellen. Vielleicht ist da irgend was zu erkennen.

      Detlef
      Leichtsinn ist kein Mut, Vorsicht keine Feigheit.
    • Schau mal hier avrhelp.mcselec.com/language_fundamentals.htm unter 'bits and interrupt'
      Das ist nicht ein Problem nur mit time$ und Co, sondern ein allgemeines.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Tschoeatsch, habe ich gelesen. Wenn mich meine bescheidenen Englischkenntnisse nicht
      trügen, heißt das, bei Bitmanipulationen in einem Byte sollte kein Interrupt dazwischenfunken,
      weil es sonst zu falschen bzw. "nachträglichen" Änderungen der Bits kommen kann.
      Soweit richtig ??

      Hier das Programm.

      Quellcode

      1. '********************************************************************
      2. '* Funkuhr mit 7-Segmentanzeige und ATMega 48 -Versuch- *
      3. '* Anzeige von Uhrzeit, Datum und Wochentag(als einzel Led) *
      4. '* Uhrzeit = Stunde und Minute *
      5. '* Datum = Tag und Monat *
      6. '* Wochentag als LED-Band *
      7. '* Controller = ATMEGA48 *
      8. '* Crystal = Quarz 8MHz -Fuses anpassen - *
      9. '* Zeitquelle = DCF77-Modul (POLLIN) VCC=3.2V *
      10. '* Pulsaufbereitung mit A302 auf L-H 5V _|¯|_ *
      11. '* Zeitdecodierung mit Bascom-Befehl "Config DCF77" *
      12. '* Wochentag- und Stellenweiterschaltung mit LS138 *
      13. '* Um Time$ und Date$ auszuwerten , darf Timer0 oder Timer2 nicht *
      14. '* aktiviert sein. Das multiplexen der Anzeige muss im Hauptprog *
      15. '* erfolgen. Die Pins 3 - 5 von PortB sind für die Programmierung *
      16. '* reserviert. Die Pins 6,7 von PortB sind der Quarzanschluss . *
      17. '* Prog : LED_Funkuhr_M48_V5.bas *
      18. '* letzte Änderung 11.04. 2014 *
      19. '********************************************************************
      20. $regfile = "m48def.dat"
      21. $crystal = 8000000
      22. $swstack = 128
      23. $hwstack = 128
      24. $framesize = 128
      25. '--------------------------------------------------------------------
      26. Config Dcf77 = Pinb.5 , Timer = 1 , Timer1sec = 1 , Check = 2 , Gosub = Sectic
      27. Config Date = Dmy , Separator = .
      28. '--------------------------------------------------------------------
      29. Enable Interrupts
      30. '--------------------------------------------------------------------
      31. Ddrd = &B11111111 'Segmente a-g
      32. Portd = &B11111111 'alle Segmente aus '
      33. '--------------------------------------------------------------------
      34. Ddrc = &B00001111 'C.0-2 Stellencount
      35. Portc = &B00000000 'C.3 Sekundentakt
      36. '--------------------------------------------------------------------
      37. Ddrb = &B00000111 'Wochentagcounter
      38. Portb = &B00000000
      39. '--------------------------------------------------------------------
      40. Segment Alias Portd '7-Seg. Code
      41. Wotag Alias Portb 'Wochentag 0-6(Mo=0)
      42. '--------------------------------------------------------------------
      43. Dim Zeit As String * 8
      44. Dim Datum As String * 8
      45. Dim Term As String * 1
      46. Dim Bild(10) As Byte
      47. Dim Zbild As Byte
      48. Dim Zahl As Byte
      49. Dim Stelle As Byte
      50. '--------------------------------------------------------------------
      51. Zahl = 0 'Stellenzahl(4*Zeit,4*Datum)
      52. ' pgfedcba
      53. Bild(1) = &B11000000 '"-0-"
      54. Bild(2) = &B11111001 '"-1-"
      55. Bild(3) = &B10100100 '"-2-"
      56. Bild(4) = &B10110000 '"-3-"
      57. Bild(5) = &B10011001 '"-4-"
      58. Bild(6) = &B10010010 '"-5-"
      59. Bild(7) = &B10000010 '"-6-"
      60. Bild(8) = &B11111000 '"-7-"
      61. Bild(9) = &B10000000 '"-8-"
      62. Bild(10) = &B10010000 '"-9-"
      63. '--------------------------------------------------------------------
      64. Do
      65. Gosub Stellenbild
      66. Waitms 3
      67. Incr Zahl
      68. If Zahl > 7 Then
      69. Zahl = 0
      70. End If
      71. Loop
      72. '--------------------------------------------------------------------
      73. End
      74. '--------------------------------------------------------------------
      75. Stellenbild: 'Ziffer der Stelle zuweisen
      76. Select Case Zahl
      77. Case 0
      78. Term = Mid(zeit , 1 , 1)
      79. Zbild = Val(term)
      80. Stelle = 0
      81. Gosub Anzeige
      82. Case 1
      83. Term = Mid(zeit , 2 , 1)
      84. Zbild = Val(term)
      85. Stelle = 1
      86. Gosub Anzeige
      87. Case 2
      88. Term = Mid(zeit , 4 , 1)
      89. Zbild = Val(term)
      90. Stelle = 2
      91. Gosub Anzeige
      92. Case 3
      93. Term = Mid(zeit , 5 , 1)
      94. Zbild = Val(term)
      95. Stelle = 3
      96. Gosub Anzeige
      97. Case 4
      98. Term = Mid(datum , 1 , 1)
      99. Zbild = Val(term)
      100. Stelle = 4
      101. Gosub Anzeige
      102. Case 5
      103. Term = Mid(datum , 2 , 1)
      104. Zbild = Val(term)
      105. Stelle = 5
      106. Gosub Anzeige
      107. Case 6
      108. Term = Mid(datum , 4 , 1)
      109. Zbild = Val(term)
      110. Stelle = 6
      111. Gosub Anzeige
      112. Case 7
      113. Term = Mid(datum , 5 , 1)
      114. Zbild = Val(term)
      115. Stelle = 7
      116. Gosub Anzeige
      117. Case Else
      118. Segment = &B11111111
      119. Zahl = 0
      120. End Select
      121. Return
      122. '--------------------------------------------------------------------
      123. Anzeige: 'Ziffer anzeigen
      124. Incr Zbild 'Arrey beginnt mit 1,Ziffer mit 0!
      125. Segment = Bild(zbild) '7-Seg.BCD-code in PortD
      126. Portc.0 = Stelle.0
      127. Portc.1 = Stelle.1
      128. Portc.2 = Stelle.2
      129. Return
      130. '--------------------------------------------------------------------
      131. Sectic: 'jede Sekunde
      132. Zeit = Time$
      133. Datum = Date$
      134. Wotag = Dayofweek() 'Wochentag Led
      135. Toggle Portc.3 'Sekundenblink
      136. Return
      137. '--------------------------------------------------------------------
      Alles anzeigen
      Ich muss dazusagen, es lief mal. Ist aber über bestückte LP nicht hinausgekommen.
      Der Grund für den Bau der Uhr war dann nicht mehr gegeben. So fristet sie ein bescheidenes
      Dasein im "Hat mal funktioniert"-Container.
      Aber vielleicht erblickt sie ja doch noch mal das elektrische Licht der Welt.
      Man weiß ja nie.

      Detlef
      Leichtsinn ist kein Mut, Vorsicht keine Feigheit.
    • Ich sehe keinen Grund für die Angabe mit Timer0 oder Timer2.
      Nebenbei: Warum überhaupt dem Umweg über die Wandling nach String und die Rückwandlung nach Zahl?
      Die gewünschten Werte liegen durch die Einrichtung der Uhr mit Config DCF77 doch schon vor als _hour und _min usw.
      Zbild = _hour / 10
      Stelle = 0
      Gosub Anzeige
      ...
      Zbild = _hour Mod 10
      Stelle = 1
      Gosub Anzeige
      usw.

      Stelle = Zahl und Gosub Anzeige könntest du auch nach dem Select-Case schreiben
    • Michael schrieb:

      Warum überhaupt dem Umweg über die Wandling nach String und die Rückwandlung nach Zahl?
      Die Frage ist berechtigt. Aber hast du mal aufs Datum geschaut?
      Das waren damals die ersten Versuche, mit Bascom so ein Problem anzugehen.
      Und glaube mir, ich war richtig stolz, als Zeit, Datum und Tag richtig angezeigt wurden.
      So lange arbeite ich ja noch nicht mit MIcrocontrollern und Bascom.
      Heute würde ich vieles anders machen. Aber an dem Programm drehe ich nichts mehr. a_217_27b18bee
      Detlef
      Leichtsinn ist kein Mut, Vorsicht keine Feigheit.
    • @Dekaman "heißt das, bei Bitmanipulationen in einem Byte sollte kein Interrupt dazwischenfunken," ich würde das erweitern, nicht nur Bitmanipulationen. Ich beschäftige mich nicht mit Assembler, drum kann ich jetzt keine g'scheiten Beispiele bringen, aber im Prinzip kann der interrupt zwischen jedem Assemblerbefehl dazwischen kommen und den weiteren Ablauf unterbrechen um den interrupt abzuarbeiten. Ein 'a=b' benötigt weniger Assemblerbefehle als string1=time$. Und wenn jetzt b oder time$ in der isr gesetzt werden, ist es wahrscheinlicher, das string1 durch einen interrupt einen falschen Wert bekommt, als a, weil einfach die Möglichkeiten bei time$ größer sind.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • @Dekaman wenn du wieder mal 'wuschig' wirst, dann empfehle ich dir einen Sprutz aus 'Wolke 7'
      shop.em-chiemgau.de/produkt/wolke-7/

      Hm, ob das zu dem Preis wirklich was taugt? a_27_b277ca12
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Dekaman schrieb:

      Ich habe beim Durchblättern meiner Programme in einer Präambel folgende Bemerkung gefunden.
      '* Um Time$ und Date$ auszuwerten , darf Timer0 oder Timer2 nicht *
      '* aktiviert sein.
      Hallo,
      Antworten OK. Bist ja auch zufrieden damit.
      Nun erlaube ich mir noch ein Kommentar zur direkten Anfrage.
      Bemerkung in der Präambel ist zu 100% okay aber nur für diesen Code.
      Gilt aber auch nur wenn wie schon erwähnt die Bitmanipulationen in Do-Loop
      für die 7-Segmente-LED-Anzeige benötigt wird.
      Somit könnte die Anzeige falsch sein aber die synchronisierten Zeiten stimmen auch so.
      Allgemein ist die Bemerkung als falsch zu betrachten im besonderen wohl nicht.
      Sonst hätte es wohl nicht funktionieren können(kein Kommentar meinerseits)
      Auch Timer0 oder Timer2 können aktiv im Hintergrund arbeiten müssen doch nicht immer
      ein Interrupt auslösen.
      Für Zeitübernahme jede DCF77- Sekunde in ein ISR zu springen erzeugt das Problem.
      Sectic:
      Zeit = Time$
      Datum = Date$
      Wotag = Dayofweek()
      Toggle Portc.3'Sekundenblink
      Return

      Richtig, als Beispiel:
      ' Auf die Synchronisierung der Uhrzeit mit dem DCF77 Zeitsignal warten
      While Dcf_status.7 = 0
      ' Dcf_status.7 wird auf 1 gesetzt sobald die Zeit erfolgreich synchronisiert wurde
      ' aktuelle Zeiten (intern und DCF) sowie den Status zum Terminal ausgeben
      Print "Uhr: " ; Time$ ; "" ; Date$ ; "" ; "DCF: " ; Time(dcf_sec) ; "" ;Date(dcf_day) ; "" ; Dcf_status.7
      Wait 1
      Wend

      Mit freundlichen Grüßen

      P.S.@tschoeatsch ich sehe nichts von eingebundene Assemblerbefehle im Code.
      Bascomcompiler setzt ASM immer auf höchste Priorität(direkter Registerzugriff) nun ist es schon sportlich mit Basic
      auch in eine kleine Assemblerroutine "dazwischen zu springen".
      Soll nur ein bescheidener Hinweis für berechtigte Überlegung deinerseits sein.
      Klar ein Kurzschluss geht immer.
    • Hi Fred, hier wurde rein in basic programmiert, aber das wird ja durch das Kompilieren in Maschinensprache (ich hab' das jetzt salop 'Assembler' benannt) übersetzt und somit erhält der basic-Befehl (nur als Beispiel!) string=time$ eine Vielzahl von möglichen Unterbrechungspunkten durch einen Interrupt. Und wenn dieser die Variable time$ bearbeitet, können halt komische Effekte entstehen. Mein Beitrag war ja auch eher allgemein, gehalten.
      Die sectic erzeugt aus meiner Sicht kein Problem, die wird ja erst aufgerufen, wenn die Sekunde empfangen wurde, also alle Zeitvariablen auf dem aktuellen Stand gebracht wurden. Das wird zeitlich mit dem Setzen des dcf_status.7 sehr nahe beieinander sein (ich kann das aber jetzt nicht beweisen, aber in der sectic ist ein gesetztes bit7 schon erkennbar).
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • @fredred
      ich habe deinen Kommentar gelesen, sehr schwer zu lesen, als Roman würde ich
      den nicht kaufen. Aber ist ja auch kein Deutschunterricht ;)
      Was mir aber noch nicht klar ist, wo sollte ich das einbauen

      fredred schrieb:

      ' Auf die Synchronisierung der Uhrzeit mit dem DCF77 Zeitsignal warten
      While Dcf_status.7 = 0
      ' Dcf_status.7 wird auf 1 gesetzt sobald die Zeit erfolgreich synchronisiert wurde
      ' aktuelle Zeiten (intern und DCF) sowie den Status zum Terminal ausgeben
      Print "Uhr: " ; Time$ ; "" ; Date$ ; "" ; "DCF: " ; Time(dcf_sec) ; "" ;Date(dcf_day) ; "" ; Dcf_status.7
      Wait 1
      Wend
      abgesehen davon, ich will's ja nicht auf ein Terminal anzeigen. Wenn ich das jetzt richtig interpretiere,
      Solange der DCF-Status.7 null ist (kein gültiger Zeitstempel) ,werden die Daten ausgegeben. Dann 1 sekunde
      warten, und wenn Status.7 immer noch null ist, alles von vorn. Ist aber Status.7=1 (gültiger Zeitstempel),
      dann keine Datenausgabe, weil Print...... übersprungen wird ??


      tschoeatsch schrieb:

      Die sectic erzeugt aus meiner Sicht kein Problem, die wird ja erst aufgerufen, wenn die Sekunde empfangen wurde

      tschoeatsch schrieb:

      aber in der sectic ist ein gesetztes bit7 schon erkennbar
      Ich dachte , das Statusbit 7 wird erst gesetzt, wenn der Zeitstempel als gültig erkannt wurde. Also erst nach
      einer Minute?
      Oder habe ich die Aussagen jetzt falsch interpretiert?

      Detlef
      Leichtsinn ist kein Mut, Vorsicht keine Feigheit.
    • Genau, bit7 wird am Ende der Minute gesetzt, wenn die Prüfung eine gültige Zeit erkannt hat und die Systemvariablen mit dieser Zeit gesetzt wurden. Dann wird sectic aufgerufen und da könnte man das gesetzte bit erkennen. Wenn man, wie du es gemacht hast, jetzt mit Time$ hantiert, muss man jetzt nicht mit einer interrupt-Störung rechnen, meine ich.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • @tschoeatsch
      Danke für die Antwort. Aber zurück zur eigentlichen Frage.
      Ich denke mal, Timer1 hat zu tun mit der Bereitstellung der Zeiten zur Decodierung
      des Zeitdiagramms (100ms , 200ms) und wahrscheinlich auch mit der Sekunde sectic.
      Das, kann ich mir vorstellen,"verursacht" auch Interrupts, die Timer1 auslöst.
      Lass ich jetzt durch den Timer0 bzw. Timer2 auch noch Interrupts erzeugen, könnten
      diese mit den Interrupts des Timer1 kollidieren, und dabei "Datensalat" erzeugen.
      Wahrscheinlich ist das Ruhigstellen von Timer0 bzw. Timer2 eine Vorsichtsmaßnahme
      um den Timer1 "in Ruhe" seine Arbeit verrichten zu lassen. a_56_df238249

      Detlef
      Leichtsinn ist kein Mut, Vorsicht keine Feigheit.
    • Es gibt Prioritäten bei der Ausführung von interrupts. Wird einer gerade ausgeführt und 2 weitere 'Quellen' lösen jetzt auch jeweils einen aus, dann wird erst einmal gewartet, bis der laufende interrupt abgearbeitet ist und dann gemäß der Priorität die anstehenden interrupts nacheinander abgearbeitet. Datensalat gibt's nicht. Bei mir gibt's Wurstsalat.
      Deswegen sollen ja die interruptroutinen so kurz wie möglich sein, dass ein Abarbeiten mehrerer interrupts das Hauptprogramm nicht lähmt. Der timer1 wird auch mit seiner isr nicht 100 bzw 200msec brauchen. In der alternativen dcf-lib von RN wird der timer1 alle 20msec aufgerufen (was ich so im Gedächtnis hab') und es bleibt für das Hauptprogramm immer noch viel Zeit übrig.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Hallo , danke an alle, die sich bisher an diesem Thema beteiligt haben.

      Michael schrieb:

      Ich sehe keinen Grund für die Angabe mit Timer0 oder Timer2.
      und

      fredred schrieb:

      Bemerkung in der Präambel ist zu 100% okay aber nur für diesen Code.

      fredred schrieb:

      Somit könnte die Anzeige falsch sein aber die synchronisierten Zeiten stimmen auch so.
      Die meisten Erklärungsversuche hat Meister Hora gemacht.

      Ich denke, wir beenden dieses Thema jetzt. Bis auf ein paar Spekulationen ist nicht viel bei
      rum gekommen.
      Zu der Zeit, als ich das Programm geschrieben habe, habe ich mich noch bei Microcontroller-Net
      rumgetrieben. Erst als man mir dort unmissversständlich gesagt hatte, das Bascom ja keine richtige
      Programmiersprache sei, es müßte zumindest C sein, bin ich auf das Bascom - Forum gestoßen.
      Und da bin ich jetzt noch.
      Damals, als dieses Programm entstand,ich war noch neu auf diesem Gebiet, habe ich alles
      eingesogen, was ich an Infos kriegen konnte. Habe damals noch nicht die Hintergründe kapiert.

      Also, beenden wir dieses Thema und stellen neue Fragen.

      Detlef
      Leichtsinn ist kein Mut, Vorsicht keine Feigheit.