Hallo zusammen,
kennt jemand eine clevere Methode ein Servosignal eines Modellbauservos
auszumessen ohne 16Bit Timer und InputCapture? Zumindest eine cleverere
als von mir unten beschriebene...
Hintergrund ist, ich würde für ein einfaches Vorhaben gerne einen
AtTiny13 benutzten, weil es den im 8 Pin DIP Gehäuse gibt und er das
klassische ISP Interface hat. Dafür hat er keinen 16Bit Timer mit ICP.
Ich habe natürlich schon selbst etwas versucht.
1.)
Einmal einfach den Timer "schnelle" Interrupts zu erzeugen und den
Signalpin einfach abfragen => geringe Auflösung + "ein gewisses Jittern"
2.)
Einen externen Interrupt getriggert durch das Servosignal. Bei
Signalbegin Timer und Variable "TIMER" nullen und bei Signalende TIMER =
TCNT2,
Im Overflow eine Variable A inkrementieren.
Gesamtzeit ergibt sich dann zu TIME = A * 256 + TIMER
=> Zueinander asynchrone Ereignisse dadurch Jitter
Grützi
Skinner schrieb:> kennt jemand eine clevere Methode ein Servosignal eines Modellbauservos> auszumessen ohne 16Bit Timer und InputCapture? Zumindest eine cleverere> als von mir unten beschriebene...
Wird nicht so das Problem sein. Eher die Messung mit dem zu kombinieren,
daß der Tiny sonst noch machen soll.
Was soll denn noch außer der Messung laufen?
ext Int konfigurieren auf steigende Flanke
(steigende Flanke)
Int löst aus -> Flanke auf fallend setzen -> Timer starten
(Fallende Flanke)
Int löst aus -> Flanke auf steigend setzen -> Timer stoppen
und den Rest ausserhalb der ISR vorkonfigurieren wie löschen der
Variablen usw usf
Skinner schrieb:> Dafür hat er keinen 16Bit Timer mit ICP.
Der hat auch vieles andere für die Aufgabe nützliche nicht, insbesondere
keine Taktbasis mit hinreichender Genauigkeit für die Meßaufgabe...
Also einfach dem Tiny13 adé sagen und eine Nummer größer nehmen, also
Tiny25. Ebenfalls in DIL8 erhältlich, aber kann einen Quarz als
Taktbasis betreiben. Er hat zwar ebenfalls nur einen 8Bit-Timer, aber
dafür zusätzlich ein USI, was man wahlweise als "Hilfstimer" oder als
"CaptureDevice" verwenden kann.
Übrigens: Wie willst du eigentlich deine Meßergebnisse aus dem Tiny
wieder rausbekommen? Weil: ansonsten sind sie nutzlos, selbst wenn sie
noch so gut sind...
Normal wäre eine Zeitmessung mit z.B. INT0, weil die Art des Interrupts
bzw. der Flanke eingestellt werden kann. Aber mit einem 8-bit timer und
PCINT funktioniert das genauso gut. Ob für die Zeitmessung ein 16-bit
timer oder ein 8-bit-timer zur Verfügung steht ist unerheblich. Bei
längeren Zeitmessungen benötigt man auch beim 16-bit timer einen
overflow. Zu beachten mit PCINT ist, dass wirklich nur die Zeit zwischen
steigender und fallender Flanke gemessen wird.
Skinner schrieb:> Im Overflow eine Variable A inkrementieren.> Gesamtzeit ergibt sich dann zu TIME = A * 256 + TIMER> => Zueinander asynchrone Ereignisse dadurch Jitter
Ohne Jitter:
Beitrag "AVR Timer mit 32 Bit"
Hallo und danke für die Antworten.
Ich denke der Tip mit dem Tiny25 wird´s bringen. Der hat ja sogar 2 (!)
8Bit Timer, auf beiden OC'n' Ausgänge und wie gesagt wurde, lässt sich
mit dem USI ein 12Bit Timer bauen.
Firma dankt!!
Skinner schrieb:> Hintergrund ist, ich würde für ein einfaches Vorhaben gerne einen> AtTiny13 benutzten, weil es den im 8 Pin DIP Gehäuse gibt und er das> klassische ISP Interface hat. Dafür hat er keinen 16Bit Timer mit ICP.
Auf den Tiny85 trifft das auch alles zu und der ist nicht Asbach Uralt,
hat mehr Timer, ist besser, schneller, schöner, höher, weiter usw.
Chefkoch schrieb:> lässt sich> mit dem USI ein 12Bit Timer bauen.
Da Du die 12Bit aber nicht atomar lesen kannst, ist es das gleiche
Problem, wie bei Erweiterung mit dem Overflow-Interrupt.
Du mußt daher auch eine ähnliche Lösung verwenden.
Stimmt, ich kann die 12 Bit micht atomar lesen - ABER (wer hätts
gedacht^^)
Der Timer 0 würde dann ohnehin mit nem Prescaler von 8 laufen, wodruch
sicher der absolute Jitter reduziert.
Vorallem aber brauche ich nur noch den Interrupt on PinChange und nicht
mehr zusätzlich den Overflowinetrrupt. Wenn die sich überlagern entsteht
ja der Jitter, da es sich um zueinander asynchrone Ereignisse handelt.
Da ich bei den EINEM Interrupt eine ziemlich konstante Einstiegszeit
haben werde, habe ich einen Offset in der Messung und keinen dynamischen
Jitter.
Steigende Flanke => Timer0 nullen / USI => warten => warten => noch mehr
warten => Fallende Flanke => Timer0 lesen/USI lesen => Ergebnis =
USI*256+Timer0
Chefkoch schrieb:> Vorallem aber brauche ich nur noch den Interrupt on PinChange und nicht> mehr zusätzlich den Overflowinetrrupt. Wenn die sich überlagern entsteht> ja der Jitter, da es sich um zueinander asynchrone Ereignisse handelt.
Was mir nicht eingeht:
Ja, natürlich hast du da einen Jitter. Aber in Relation zu der Länge
eines Servopulses ist der so minimal, dass ich mir nicht vorstellen
kann, das sich der bemerkbar macht. So genau können doch Servos als
mechanisches System gar nicht positionieren.
Karl Heinz schrieb:> Jitter. Aber in Relation zu der Länge> eines Servopulses ist der so minimal
Genau das. Ebenso sind die 16bit Auflösung total überzogen.
Vor vielen Jahren entwickelte ich mal einen Servosteller mit 9bit, also
8bit Timer + 1bit in Software. Das war vollkommen ausreichend und fand
für viele Jahre etliche zufriedene Käufer. Ganz grob überschlagen machen
9bit ca. 0,2° Auflösung am Servo, da kommt die Mechanik nicht mit.
Nachtrag: Wow. Ich sehe gerade das Teil wird noch immer verkauft, das
ist ja schon nicht mehr wahr...
Micha H. schrieb:> Genau das. Ebenso sind die 16bit Auflösung total überzogen.> Vor vielen Jahren entwickelte ich mal einen Servosteller mit 9bit, also> 8bit Timer + 1bit in Software. Das war vollkommen ausreichend und fand> für viele Jahre etliche zufriedene Käufer. Ganz grob überschlagen machen> 9bit ca. 0,2° Auflösung am Servo, da kommt die Mechanik nicht mit.
Ich finde, daß da noch irgendwie eine Zeiteinhit zum Bit gehört. So, wie
das da steht, eröffnet es mehr Fragen als Antworten. :(
kürtler schrieb:> Ich finde, daß da noch irgendwie eine Zeiteinhit zum Bit gehört.
Da hast Du recht. Ich maß nur den High-Puls, also das was sich zwischen
1 und 2ms abspielt, oder wenn man großzügig ist 0,8-2,5ms.
Die Low-Zeit ist ja eh unkritisch, bzw. ist durch das Eingangssignal
vorgegeben.
Also nochmal großzügig gerundet 3ms / 500 = 6µs pro Bit.
