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
Die Idee mit einem Soundkarten Oszi werde ich mal versuchen. Finde aber noch kein passendes Programm. Dirk
>Das Design ist für die Aufgabe schon genial, der Prozessor ist nur total >überfordert. Klasse :-)
Tja, die Personen die die Hardware aussuchen, sind halt nicht immer die das ganze dann umsetzen dürfen. Leider! 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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.