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
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
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
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
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
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
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.
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
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
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
