Forum: Mikrocontroller und Digitale Elektronik Timer kontrolle mit was?


von Dirk (Gast)


Lesenswert?

Hallo.
Ich habe ein Signalgeber (AVR mit Timer0) 1ms -xms und muss dem zur 
Laufzeit überprüfen.
Also der soll im 1ms Takt vor sich hinlaufen, das macht er aber nicht 
sauber (SIO 19200 tx & rx  AD  externe ints).
So nun will ich aber wissen wie groß die maximale Abweichung ist.
Ich habe es auf dem OSZI schon gesehen das es mal 1,07ms waren, aber 
einmal gesehen ist keine sichere Aussage, es könnte ja sogar ein 
Interrupt verschluckt werden.

Darum suche ich eine einfache Methode (ohne viel basteln) das Maximum zu 
erfassen.
Hat von Euch jemand eine Idee dazu?
Viele Grüsse, Dirk

von Peter D. (peda)


Lesenswert?

Dirk wrote:
> Hallo.
> Ich habe ein Signalgeber (AVR mit Timer0) 1ms -xms und muss dem zur
> Laufzeit überprüfen.
> Also der soll im 1ms Takt vor sich hinlaufen, das macht er aber nicht
> sauber (SIO 19200 tx & rx  AD  externe ints).

Du brauchst nichts zur Laufzeit überprüfen.
Software hat den Vorteil, daß man sie simulieren kann, um den 
Softwarefehler zu finden.

Natürlich sollte zuerst sichergestellt sein, daß der CPU-Takt stimmt.
D.h. für genaue Zeiten ist der interne RC-Oszillator tabu, da muß man 
nen Quarz ranpinnen.

Für sehr hohe Anforderungen erzeugt man den Takt mit nem Compare-output, 
das ist dann auf den CPU-Zyklus genau (+/-50ns bei 20MHz).
Für weniger hohe Anforderungen nimmt man nen Compareinterrupt und hat 
dann einen der Interruptlatenz entsprechenden (nicht akkumulierenden) 
Jitter.


Peter

von Dirk (Gast)


Lesenswert?

Das muss leider zur Laufzeit geprüft werden, denn im Simulator ist immer 
alles sauber und macht genau das was es soll. Aber im zusammen spiel der 
Interrupts kommt es zu zeit Verschiebungen und da muss ich den Maximal 
wert bestimmen.
Viele Grüsse, Dirk

von Peter D. (peda)


Lesenswert?

Dirk wrote:
> Aber im zusammen spiel der
> Interrupts kommt es zu zeit Verschiebungen und da muss ich den Maximal
> wert bestimmen.

Den solltest Du besser anhand des Assemblerlistings bestimmen.
Der worst Case ist, daß alle Interrupts gleichzeitig auftreten und den 
wirst Du auch zur Laufzeit sehr selten sehen. Daher ist das Berechnen 
aus den Instruktionen der einzig sichere Weg.

Beliebte Interruptproblemmacher sind Unterfunktion, float oder Delays in 
Interrupts, dann brennts.

Oftmals ist das Problem aber garnicht der Interrupt, sondern das 
Zuschlagen an der ungünstigsten Stelle.
16Bit Zugriffe sind z.B nicht atomar und dabei kann es gewaltig krachen. 
CLI+SEI-Klammerung hilft dann.


Peter

von Dirk (Gast)


Lesenswert?

Sorry aber ich will wirklich nur messen, berechnen kann man das kaum.
Und wenn dann mit viel zu viel Aufwand. Ich will das ganze heute noch 
fertig haben und kann nicht alle Interrupts einzeln durch Messen. Die 
können dann auch mehrfach aufgerufen werden und verzögern sich womöglich 
dann gegeneinander. Da ist messen einfach schneller ist nur die Frage 
mit was kann man das messen. Ohne sich erst ein Messgerät zubauen.
Dirk

von Oliver (Gast)


Lesenswert?

Gar nicht. Du wirst den worst case nicht treffen.

>Ohne sich erst ein Messgerät zubauen.
Halt einen Finger dran, dann kann man es fühlen...

Nimm einen zweiten AVR, und pack da ein Progrämmchen drauf, daß die 
maximale Zeitspanne des Timers auf dem ersten AVR ermittelt. Dann lass 
das 10min laufen, und bete, daß da ein ungünstiger Fall dabei war. Die 
Chancen sind nicht groß.

Wenn du die maximalen Werte nicht durch Analyse der Software ermitteln 
kannst, ist das Softwaredesign fürn' Arxxx, und passt nicht zu deinen 
Anforderungen.

So oder so, ich fürchte mal, heute wird das nicht fertig.

Oliver

von Gast (Gast)


Lesenswert?

Das einfachste was mir spontan einfällt: Häng den AVR mit seinem Pin 
über einen Spannungsteiler an die Soundkarte. Im Web gibt es genug 
Soundkarten-Oszi-Programme, irgendwo müsste eines dabei sein, mit dem 
man die Impulslängen bestimmen kann.

von Dirk (Gast)


Lesenswert?

In der Software wird einfach zu viel getrickst. Das Design ist für die 
Aufgabe schon genial, der Prozessor ist nur total überfordert.
Es musste aber unbedingt ein AVR sein, dabei brauche ich nur 10 
Serialschnittstellen und 12 AD Wandler. Das ganze mit ein wenig 
Ablaufsteuerung die von einem Timer gesteuert wird. In diesem Timer wird 
alle 100ms ein WD (125ms) getriggert und das ist der Harken der kommt 
nicht immer Rechtzeitig. 250ms reichen aber ich muss den Maxwert kennen.
Der Killer Tackt kommt regelmäßig also auch wenn ich nicht 100% Max 
finde ist 95% auch OK.
Dirk

von Dirk (Gast)


Lesenswert?

Die Idee mit einem Soundkarten Oszi werde ich mal versuchen.
Finde aber noch kein passendes Programm.
Dirk

von Gast (Gast)


Lesenswert?

>Das Design ist für die Aufgabe schon genial, der Prozessor ist nur total
>überfordert.

Klasse :-)

von Dirk (Gast)


Lesenswert?

Tja, die Personen die die Hardware aussuchen, sind halt nicht immer die 
das ganze dann umsetzen dürfen. Leider!

Dirk

von Peter D. (peda)


Lesenswert?

Dirk wrote:
> Sorry aber ich will wirklich nur messen, berechnen kann man das kaum.

Wenn die Interrupthandler wirklich dermaßen groß und lang sind, daß man 
nicht die paar Zyklen abzählen kann, dann hast Du in der Tat ein 
Problem.
Vielleicht solltest Du dann den Programmablaufplan nochmal überdenken.


Die Idee von Oliver ist doch ganz gut, einfach nen 2. AVR (ATtiny2313) 
als Pulslängenzähler nehmen und über UART oder LCD ausgeben. Sowas ist 
fix mit Inputcapture gemacht.

Allerdings solltest Du dann für jeden Interupthandler separat die 
Laufzeit ermitteln und dann alle addieren, sonst kriegst Du den 
Worst-Case nie gebacken.
Dazu nen Portpin beim Eintritt setzen und am Ende rücksetzen.
Und zu den einzelnen Zeiten noch etwa 50 Zyklen PUSH/POP-Orgie zuzählen.


Peter

von Peter D. (peda)


Lesenswert?

Dirk wrote:
> In der Software wird einfach zu viel getrickst. Das Design ist für die
> Aufgabe schon genial, der Prozessor ist nur total überfordert.

Sei mir nicht böse, aber "genial" und "überfordert" ist ein Widerspruch 
in sich.

Es ist mir auch schon oft passiert, daß ich dachte, das schafft die CPU 
nie. Aber dann habe ich durch Umstellung des Programmablaufs immer eine 
Lösung gefunden, wo die CPU sogar noch Däumchen drehen konnte.
Ich bin daher immer sehr mißtrauisch, wenn jemand behauptet, die CPU sei 
überfordert. Oftmals macht sie nur einfach unwichtige Dinge zu oft.


Peter

Bitte 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
Noch kein Account? Hier anmelden.