Timer1 als Gesamtlaufzeit-Zähler möglich?

[PsiQ]

Mahlzeit!
Kurze Frage. Bei den Pic16Fxxx gibt es ja den Timer0 (0..255+1) und den Timer1 (65535 +1).
Kann ich den Timer 1 somit als Laufzeitspeicher verwenden?

Ich benötige für eine Stoppuhr mit 10mS Schritten eine Zeit die "im Hintergrund" immer weiterläuft,
Bei einem Stoppsignal soll der aktuelle Zeitwert seit "Start" auf dem LCD dargestellt werden.
Beim nächten Stoppsignal wieder die GESAMTzeit seit dem "Start" (nicht die Zeit seit dem letzten Stopp).

Daher die Frage ob ich den Timer1 als Gesamt-Laufzeit-Zähler nutzen kann.
Die benötigte GesamtMess-Zeit liegt dabei unter 1h, eigentlich sogar unter 100 Sekunden,
ich brauche aber eine Auflösung von 10mS Schritten, also 00,01 Sekunden.

Ob der Timer1 dann ab "Startsignal" läuft oder ab "Reset" ist ja egal, da eh nach Ende jeder Messung einmal Reset erfolgt.

Danke!

(PS.: Bin auf diese Idee gekommen weil ich beim Arduione gelesen habe, das dieser einen Laufzeit-seit-Start Timer hat.
Da dieser immer im Hintergrund mitläuft und wohl bis zu 30 Tage messen kann, kann man über diesen den Start/Ersten
und Stop/zweiten Wert vergleichen und damit die Differenz = vergangene Zeit ermitteln)

[oberallgeier]

Hallo Jürgen

... Bei den Pic16Fxxx gibt es ... und den Timer1 (65535 +1). Kann ich den Timer 1 somit als Laufzeitspeicher verwenden ...

Ohne dass ich jemals mit nem Pic Erfahrungen machte, behaupte ich : ja. Bei meinem Atmels habe ich praktisch immer einen interruptgetriebenen Heartbeat (im Prinzip egal welcher Timer), der mit 20kHz eine kurze ISR aufruft. Darin wird eine 16bittige Variable von 19 999 runtergezählt - dann wieder von oben anfangen. Beim Nulldurchgang wird eine weitere 16bittige Variable "Isecundn" hochgezählt. Als unsigned Variable (eine Laufzeit kann nie negativ werden) komme ich also auf über 18 Stunden Laufdauer bis zum Überlauf. WENN Dir das nicht reicht, dann kannst Du natürlich nen Stundencounter (if (Isecundn == 3600)...) einbauen und wochenlang die Zeit messen.

[RoboHolIC]

@Jürgen
Wenn die Stoppuhrfunktion die Kernaufgabe des Controllers ist, kannst du den Timer 1 als Speicher dafür verwenden. Die Zeitbasis von 10ms schreit aber eigentlich danach, das von oberallgeier beschriebene Verfahren anzuwenden; andernfalls ist man doch sehr beschränkt in der HW-seitigen Konfigurierbarkeit (Prescaler-Einstellungen) des Zähltaktes und der Zeit bis zum Überlauf von Timer1. In Software kaskadiert man zwei, drei, vier, ... Bytes und gut is. Die Ausführungszeit dafür ist bei einem 10ms-Interrupt nicht der Rede wert.

[PsiQ]

Nachdem ich jetzt nach einem Tag rumgefluche meinen Programmierer wieder hinbekommen habe,
werde ich jetzt endlich meine Platine zusammenbraten.

Also LCD ran, 3 Taster (Start, Stop, Reset), 4096mhz Quarz, und mal ein fertiges Programm von Sprut draufbrennen.

Dann stimmt zwar der Timer/Zähler überhaupt nicht, aber wenn das dann irgendwas tut,
werde ich nach und nach versuchen das von 1Sekunden auf 10mS Schritte passend zu modden..
und wenn das ging dann das
Reset; Start=>LCD Uhr läuft mit , Stop=>Zeit1 auf LCD steht , Stop=Zeit2 auf LCD , Stop=Zeit3 auf LCD steht.
irgendwie hinbiegen. ... ... ...Hoffentlich!

Im Sprut Beispiel wird der Timer 0 verwendet, der nach 255+1 überläuft, um den Zeitgeber mit 32khz quarz in Sekundenschritten zu machen/weiterzuzählen.*
Ich dachte an eine Kombination aus Timer 1 mit Vorteiler:4 und Timer 0 als Überlauf-Mitzähler. Wären dann 65535 x4(Teiler) x 255 Werte die im Hintergrund mitlaufen können.

Haarig wirds dann für mich mehrere Zeiten zu speichern/auszugeben.


*@RoboHolic: Ich denke das ist das was du mit kaskadieren meinst. Sprut zählt die EinerSekunden bis 9, bei 10 erfolgt der reset und der übertrag um 1 auf das nächste bit (ZehnerSekunden),
und dort dann bei 5+1 der übertrag von 60sekunden = 1 Minute .. dann 60min = 1h .. bis 23:59+1 => 00:00:00

Ich habe nur Sorge, dass ich nachher fürs LCD ausgeben/beschreiben und den Rest drumrum nicht genug Zeit habe um die 10mS genau genug zu halten/messen.
Wenn ich das im timer 1 "laufenlassen" könnte und nur kurz den wert auslese und damit von mS auf [ss]:[mS][mS] rechnen kann reicht mir das.
Brauche gar keine Minuten, es würde auch 999Sekunden,[mS][mS] reichen, was ja bei einem 10mS Grundzähler

Eine einfache Division oder sogar eine direkte darstellung möglich macht...
30.025 in Timer 0 wären dann 30.025x10mS = 300.250mS also 300,250 Sekunden.
Darstellbar aufm LCD als 300[Sek]:250[mSek].

(wobei die letzte 1mS Stelle egal ist.)

.. Genug geredet, los gehts an den Lötkolben!

[RoboHolIC]

Ein 4096MHz-Quarz ist schon mal sehr komfortabel, weil damit das Timer-Preload-Verfahren zur Einstellung der Zykluszeit wegfällt (siehe die Errata sheets zum Timer0-Fehler).
Willst du ebenfalls diesen 32.768kHz-Quarz verwenden? Der Sinn des vor Dir erwähnten Sprut'schen Konstrukts ist mir nicht klar.
Willst du Timer 0 selbst inkrementieren, wenn Timer 1 überläuft? Das macht nicht viel Sinn und der Chip gibt dergleichen auch nicht her. Dazu verwendet man sinnvollerweise die in ausreichender Zahl vorhandenen Speicherbytes des SRAM.
Die Idee, gleich alle Ziffern für die Anzeige passend durch einzelne Zähler(überläufe) zu implementieren ist recht gut; benötigt zwar in der ISR etwas mehr Zeit, spart dafür aber die aufwendige nachträgliche Zerlegung. Das ist das eine. Das andere ist die Differenzbildung in der ziffernorientierten Darstellung, das klingt für mich ohne Hardwareunterstützung für BCD-Arithmetik etwas heikel.

Das mit dem Kaskadieren hatte ich allerdings anders gemeint: Nämlich bei jedem Timerinterrupt das inkrementieren des niederwertigsten Bytes und bei auftreten des carry-Flags inkrementieren des nächst-höherwertigen Zählerbytes und bei auftreten des carry ........ Das ist deine binäre Uhr. Die Differenzbildung über mehrere Bytes (ich vermute mal Assembler) kann man sich aus dem Netz holen oder selbst ausdenken. Es gibt auch Application Notes für die PIC16-Familie, da wird so etwas beschrieben. (In C wäre das ja kein Thema).
Der Vorgang des Zeitnehmens ist schlicht das Anfertigen von Kopien aller Zähler-Bytes.

Die Ausgabe aufs LCD ist wirklich Aufgabe des Hauptprogramms, allein die Übergabe der Datenhappen an das LC-Modul sollte man entweder der ISR selbst aufbürden oder durch ein von der ISR gesetztes "Neue-Zeitscheibe"-Flag synchronisieren.

Das alles genau zu beschreiben fällt mir allerdings schwer. Es ist schon wichtig, dass du eine klare Vorstellung von solchen zeitgesteuerten Mechanismen zwischen Hauptprogramm und ISR entwickelst. Da scheint auch jeder seine eigene Vorliebe zu entwickeln, wie er das genau umsetzt.

[PsiQ]

Ich habe den 4096er Quarz bestellt weil Sprut in seinen Beispielen explizit sagt,
dass mit dem 32khz uhrenquarz eine 100mS oder 10mS Uhr nicht möglich ist, da mit seiner vorgehensweise der kleinste passende Teiler eben der 1 Sekunden Schritt ist.
Habe mich da in die 3 Programmbeispiele die er hat versucht etwas einzulesen:
Zitat Sprut bei 32khz LCd Uhr:

Weiterführende Gedanken
Kann man auf dieser Basis auch eine Stoppuhr mit 1/10 und 1/100 Sekunden-Anzeige bauen???
Nein! es gibt keine Möglichkeit, aus einem 32768-Hz-Takt durch Teilung ein 10Hz oder 100Hz-Signal abzuleiten. Folglich müssen Stoppuhren mit ganz anderen Quarzen bestückt sein.

Und bei 4.096 : 4 : 256 wäre man bei => 4000 überläufen pro Sekunde .. wenn ich die dann
durch 4 (Vorteiler) Teile habe ich beim Originalprogramm von Sprut eine um 1000fach höhrere Messzeit, also 1mS statt 1s.

gegenüber
32768 : 4 : 256 => 32 Überläufe pro Sekunde .. die teilt Sprut dann durch 32 (Vorteiler) und hat seinen Überlauf im Sekundentakt.


"Theroetisch", muss ich im Originalprogramm also nur die Pausenzeiten/Loops anpassen um den Faktor 1000x und die LCD Wartezeiten an mein großes LCD anpassen,
dann läuft die Uhr schon mit mS. Ist aber halt noch keine Stoppuhr.

--------------
Sprut speichert die Zahlenwerte direkt in die auszugebenden Zeichen (ES ist ein vorher definiertes Speicher Bit), soweit ich das richtig sehe,
wobei er dann eben gleich die entsprechenden Überläufe zur nächsten Stelle mit macht, z.B: bei 59+1sek = 1min. ( siehe code bei clrfs ES)
So sieht das Unterprogramm dafür aus, das für jeden Sekundenüberlauf/Interrupt abgearbeitet wird.

Int_1
    bsf    neu

    incf    ES, f        ; 1 Sekunden erhöhen
    movlw    D'10'
    subwf    ES, w
    btfss    STATUS, Z    
    goto    Int_end        ; 1 Sekunden <> 10    

    clrf    ES
    incf    ZS, f        ; 10 Sekunden erhöhen
    movlw    D'6'
    subwf    ZS, w
    btfss    STATUS, Z    
    goto    Int_end        ; 10 Sekunden <> 6    

    clrf    ZS
    incf    EM, f        ; 1 Minuten erhöhen
    movlw    D'10'
    subwf    EM, w
    btfss    STATUS, Z    
    goto    Int_end        ;  1 Minuten <> 10

    clrf    EM
    incf    ZM, f        ; 10 Minuten erhöhen
    movlw    D'6'
    subwf    ZM, w
    btfss    STATUS, Z    
    goto    Int_end        ; 10 Minuten <> 6

    clrf    ZM
    incf    EH, f        ; 1 Stunden erhöhen
    movlw    D'10'
    subwf    EH, w
    btfss    STATUS, Z    
    goto    Test24        ; 1 Stunden <> 10

    clrf    EH
    incf    ZH, f        ; 10 Stunden erhöhen
    goto    Int_end

Da Sprut nur eine Uhr und keine Stoppzeiten benötigt, zeigt er diese Stellen [ZM][EM]:[ZS][ES] direkt auf dem LCD an.

Vom Prinzip her würde es also reichen im Fall von "STOPP" Werte der laufenden Uhr zu kopieren und anzuzeigen.
Beim 2 zeiligen Display wäre es also möglich in der 1. Zeile immer die laufende Uhr zu zeigen
und in der 2. Zeile die im Moment vom letzten "Stopp" rauskopierten Werte.
Ich weiß nur nicht ob das schnell genug geht (unter 10mS) dass ich nicht beim Auslesen von hinten nach vorne
einen Überlauf ins nächsthöhere Bit verpasse und quasi noch paar mS weiterzähle.

Daher der Gedanke "nach" dem 255+1 Timer den 65535er Timer1 zu verwenden (zu beschreiben) und in diesem die verstrichene Gesamtzeit zu zählen,
damit ich nur diesen einzelnen Wert auslesen und anschließend "umrechnen" muss,
und nicht alle 5 Stellen einzeln kopieren.


Ich versuche mal meinen Gedanken weiterzuführen/zu erläutern:
Ich lasse den Timer0 255+1 mit den Teilern 4096/4 :4 laufen.
Ich habe also 1000 überläufe pro sekunde.

Das schreib ich in ein Byte, was jeweils nach 9+1 überläuft.
Ich komme also von 1mS Schritt damit auf 10mS. (Dieser Zwischenwert interssiert mich nicht wirklich beim auslesen,
da mich der 1mS Stand nicht interessiert. Falls genug Luft bleibt kann ich den ja aber immer noch auslesen)

Diesen 9+1mS Überlauf zähle ich dannn in Timer1 mit.
Timer 1 kann dann 65535 x 10mS zählen (=655350mS), also eine Gesamtzeit von 655 Sekunden
- was über 10 Minuten sind und völlig ausreichend.

Im Fall von "Stopp" lese ich dann den Wert von Timer1 zu diesem Zeitpunkt aus,
und kann den gespeicherten Wert dann "ganz in Ruhe" langsam auf dem LCD darstellen,
was dann auch länger dauern darf, da der Timer ja im Hintergund mit seiner Interruptroutine ungestört weiterläuft.

Die vermeintlichen Grundlagen dazu hab ich da gelesen:
http://www.sprut.de/electronic/pic/g...mer.htm#timer0


Mit ISR, meinst du die "Interrupt gesteuerte Routine", also das zeitkritische Programm was
das LCD-Anzeige/UmrechenHauptprogramm unterbricht und danach wieder zurückspringt, korrekt ?


...
Nunja. Soviel zu dem wie ich mir das theoretisch überlegt habe. Leider fehlen mir noch die Fachbegriffe und Zuordnungen, wie was wo..

Aber erstmal muss ich meine Platine zum Laufen bekommen, die zeigt nämlich nur 2 schwarze Balken aufm LCD und tut sonst nichts.
Ich habe das 10Mhz Programm mit dem 4096er Quarz verwenden wollen zum Testen meiner Platine, das läuft halt dann nur auf 40% Speed.
=> http://www.sprut.de/electronic/pic/p...hr/lcduhr.html

Leider tut sich nichts. Werde die Schaltung nochmal prüfen, wobei ich einen Fehler beim Compilieren vor dem Brennen vermute, da muss ich mal etwas rumspielen
und werde dann die Fehlercodes posten wenns unter 10 geworden sind
Mit dem fertigen *.hex und der passend Konfig (high voltage aktiv) beim Brennen hats leider auch nicht geklappt.