das mit dem "TOV auslesen/setzen" ist in Bascom der Befehl "ON TIMERX ISR_TIMERX"
also "bei TIMERX -Überlauf die ISR dazu ausführen" !? DAs kann ich doch dann nutzen ?
Nein, nicht ganz.
Bleib nicht an dem Timer-Interrupt kleben...
Kleiner Exkurs Interrupts:
Die meisten periphären Hardwaremodule besitzen die Möglichkeit, das laufende Programm zu unterbrechen (interrupt). Dazu gibt es meist ein ... Flag, ein Fähnchen, das in irgendeiner Weise das Event erstmal anzeigt. Das kann unabhängig davon geschehen, ob der Interrupt überhaupt aktiviert ist. Jedesmal, wenn der Timer überläuft, wird das TOV-Flag (auf "1") gesetzt. War er vorher schon gesetzt, bleibt es gesetzt.
Aktiviert wird jeder Interrupt für sich mit einem eigenen Interrupt-Enable-Bit. Außerdem müssen die Interrupts global aktiviert sein.
Wenn also der TOV-IRQ enabled ist (und die Interrupts global), löst das ein gesetztes TOV-Flag einen Interrupt aus. Dabei wird der aktuelle (Maschinencode-) Befehl abgearbeitet/beendet, die Adresse des nächsten Befehls abgespeichert (Rücksprungadresse), Danach wird eine spezielle Adresse am Anfang des Programmspeichers angesprungen - der Interruptvektor (des konkreten TOV-IRQs). Außerdem werden die Interrupts global gesperrt.
In der Interruptvektortabelle muß jetzt die weitere Behandlung des Interruptes erfolgen, üblicherweise ein Sprung in eine entsprechende Interrupt Service Routine (ISR). "On Timerx Isr_timerx" macht nichts anderes, als in der Interruptvektortabelle (IVT) beim TOV-Vektor einen Sprung zu der genannten Routine einzutragen. Mit "On Int0 Routinenname" hast Du dasselbe mit dem externen Interrupt gemacht.
Am Ende der ISR erfolgt dann ein Return (genauer: ein Return from Interrupt), dabei wird die abgespeicherte Adresse im Programmspeicher wieder geladen (da gehts weiter), und die Interrupts global wieder freigegeben.
Mein Vorschlag war nicht, den Überlaufsinterrupt des Timers zu verwenden, sondern nur das Überlaufsflag auszuwerten, welches automatisch bei jedem Überlauf gesetzt wird. Ohne den Interrupt zu aktivieren. Ohne dafür 'ne ISR zu implementieren. Ohne einen Sprung in die IVT schreiben zu lassen (On Timerx...).
Klar?
dann habe ich aber das Problem, dass der bei 8-14ms Pause nicht überläuft, weil er ja bis 65.536 zählt.[...]also müsste ich ihn preloaden
Nicht unbedingt preloaden - Du kannst Ihn auch "oben abschneiden", also die Reichweite begrenzen. Den Punkt, wo er überläuft. Üblicherweise kann man einen 16bit-Timer, zumindest im PWM/fastPWM (man muß die OutputsCompares ja nicht nutzen) auch auf 8, 9 oder 10 Bit vorgeben. Außerdem gibt es oft die Möglichkeit, den Überlauf durch den Vergleich (automatisch bei jedem Timerinkrement) mit einem bestimmten Register Durchzuführen. Oft das CaptureUnit A, wenn vorhanden das Input Capture Register, einige Timer bieten auch ein extra-Register für sowas an (der Tiny25/45/85 hat zB bei Timer1 ein drittes Capture Unit (C) ohne PWM-Output dafür). Die entsprechenden Timermodi heißen dann CTC (Clear Timer on Compare Match) oder frequenzkorrigiert.
Allerdings hat der vorgeschlagene Tiny25/45/85 nur zwei 8bit-Timer. Laut meiner Übersicht hätte der Tiny24/44/84 einen achter und einen sechzehner, der ist aber auch schon größer. Wie's mit dem Tiny102 aussieht, weiß ich grad nicht aus dem Kopf, aber der wird eh schwerer zu beschaffen sein, der kleine XTiny wird noch gar nicht auf dem Markt sein (muß die Übersicht irgendwann mal weitermachen).
wie dem auch sei...
Da meine PWM-Motor-Routine mit Werten von 0-255 (für jede Richtung) arbeitet, wäre es ja sinnvoll, wenn mir die Impuls-Auslese-Routine Werte bis 510 +/- liefert, damit ich das gut verarbeiten kann.
Du wirst eh rechnen lassen müssen, da die erste ms ja auch immer mitgezählt wird.
Die Frage ist also auch, welche Auflösung Du hier haben willst.
Man könnte beim Tiny85 zB für die Pulslängenerfassung Timer1 mit Prescaler=128 am 8MHz-Systemtakt wählen. Der ist dann nach 1ms bei 63, nach 1,5ms bei 94, nach 2ms bei 125. Nach gut 4ms kommt das TOV, wenn der Timer nicht vorher zurückgesetzt wurde.
Wären 31 Schritte pro Richtung.
Mit Prescaler 64 wäre es überall das doppelte.
Die Werte landen also in dem Array, Du ziehst vom Ergebnis den Null-wert (94 bzw 188) ab. Anhand des Vorzeichens kannst Du die Richtung (also den PWM-Kanal) festlegen; die negative Zahl machst Du danach positiv (Komplement). Anschließend mit 8 multiplizieren (viermal linksschieben, bei Prescaler=64 nur mit 4 multiplizieren, also zweimal linksschieben). Damit kämest Du von 0..248 was in das korrespondierende Compare-Register zu schreiben wäre. Alles mit einfacher Bitpopelei...
Bei den beiden Kanälen mußt Du sicherstellen, daß immer nur ein Kanal gleichzeitig aktiv ist. Bei Phasenkorrekten Modi scheint es zu genügen, den Compare-wert auf "0" zu setzen, sicher bist Du immer, wenn Du den Compare Output Mode des anderen Kanales abschaltest.
Klar könnte man das auch sauber bis 255 hochmultiplizieren, oder mit etwas Bitgeschubse schummeln...
Wenn Du das mit den PWM-Frequenzen bei der PWM-Ausgabe fertig getestet hast (gehen die 60Hz nun?), würde ich erstmal ein Testprogramm für die Pulslängenerfassung testen. Du nutzt für die Tests einen Mega16 und da insbesondere auch den UART?