PWM-Signal messen / Latenzzeiten

[cheaker10]

µC: Arduino Mega Board mit dem ATMEGA1280
IDE: Eclipse; Programmiersprache C

Um die Echtzeitfähigkeit von einem Raspberry zu testen, soll auf verschiedenen Distributionen die Interrupt-Latenz-zeit bei verschiedenen Belastungszuständen
gemessen werden. Grössere Abweichungen bei den Interrupt-Latenzzeiten werden oft erst sichtbar, wenn man das Verhalten eines Systems über einen grösseren
Zeitraum (z.B. 10 bis 20 min) beobachtet. Diese Messung will ich nun mit dem Arduino Mega1280 durchführen.

Als IDE verwende ich Eclipse, jedoch bin ich noch sehr unerfahren was die µC- Programmierung angeht. Was ich jetzt schon herausgefunden habe ist das ich aufjedenfall die Input Capture Unit veerwenden muss.
Das dürfte beim ATMEGA1280 an ICP4 und ICP5 möglich sein. Was ich auch schon gefunden habe ist die Applicaion Note von Atmel: http://www.atmel.com/images/doc8014.pdf

Mich würde interessieren ob jemand von euch so etwas schon programmieert hat und/ oder mir etwas helfen könnte.
Oder vielleicht hat jemand auch schon Beispielcode für mich...
Werde die nächsten Tage meinen Code mal posten so bald ich angefangen habe.

Danke schonmal für eure Hilfe.

 

[LotadaC]

Irgendwie wird mir nicht so recht klar, wie Dein Versuchsaufbau sein soll...
Der RasPi läuft irgendwie mehr oder weniger belastet vor sich hin, dann erzeugt irgendwas (also zB der AVR) externe IRQs?
Und Du willst jetzt den RasPi im IRQ wiederum irgendwas "antworten" lassen, und die Zeit messen?

In welcher Dimension spielen sich denn die erwarteten Zeiten ab?

Im Prinzip brauchst Du das IC-Unit nicht unbedingt, da Du das Timing des AVR nahezu vorhersagen kannst. Aber mit IC-Unit sollte es eigentlich so gehen:

• Du läßt den Timer 'n fastPWM erzeugen (nicht invertierend), die fallende Flanke soll dann der IRQ für den RasPi sein (fastPWM bedeutet daß der Output bei jedem Überlauf high geht, und nach einstellbar vielen Takten (innerhalb von16bit) wieder runter - dadurch hat der AVR hier selbst keine Latenz zwischen Output setzen und Timer synchronisieren/starten/etc (obwohl man das ausrechnen könnte).
• Die Antwort des RasPi löst das Capture Event des Timers aus, wodurch automatisch der "Zählerstand" in das Input Capture Register übertragen wird, aus dem Du es auslesen kannst.

konkreter:

• Timer mit geeignetem Prescaler in den fastPWM, den Output als nicht invertierend, Timer aber noch nicht starten
• IC-Unit auf entsprechende Flanke einstellen, und den IC-IRQ scharfschalten
• Um 'ne Messung zu starten, jetzt einfach den Timer starten.
• In der ISR des IC-Eventes kannst Du das Ergebnis auslesen und der weiteren Verabeitung zuleiten, den Timer anhalten.

Etwas schwieriger wird es, den eventuell erfolgten Überlauf des Timers sicher zu erkennen, da wir für das PWM selbst ja den Überlauf brauchen. Obwohl... Man verwende den Interrupt des OutputCompareUnits, und mache dort den TOV-IRQ scharf nachdem das ggf gesetzte Flag gelöscht wurde. Im IRQ des IC-Events wird er wieder entschärft. Treten beide Events (also OC und IC) im gleichen Timertakt auf, hat der OC die höhere Priorität -> also wird der TOV erst scharf, und dann sofort entschärft, paßt also...
Tritt ein TOV IRQ ein, weißt Du, daß der Timer zwischen OC-Event (dein Signal an den Raspi) und IC-Event (Antwort vom Raspi) der Timer mindestens(!) einmal übergelaufen sein muß, das Ergebnis nicht mehr verwertbar ist.

Warum Du dafür jetzt so' Mordsbrocken einsetzen willst, ist mir nicht ganz klar...

P.S.: Willkommen im Forum, und sag bitte, daß Du wenigstens Ansatzweise mein Funktionsprinzip verstanden hast...
P.P.S.: Tritt der TOV-IRQ ein, weißt Du, daß eine "Latenz" des Raspi größer als die (so mit diesem Prescaler) mögliche Erfassungszeit des Algorithmus ist, UND jetzt bereits der nächste "Request" an den RasPi gesendet wurde...

 

[TommyB]

Nur zum Thema "Echtzeitfähigkeit":
Die hat kein PC. Weder Windows-PC noch Mac, noch Linux, noch RasPi. Das liegt in der Natur des Systems (Stichwort Multitasking). Irgendein Interrupt wird dir immer mal dazwischen funken.

Allerdings scheint es möglich zu sein beim RasPi die Interrupts generell zu deaktivieren. Es funktioniert denn zwar nichts mehr außer der Routine die grade läuft, aber die läuft denn ohne Unterbrechungen. Zumindest scheint es so wenn man sich mal dieses Projekt anschaut:
http://www.raspberrypi.org/forums/viewtopic.php?f=37&t=7696

Getestet habe ich es aber noch nicht.

 

[cheaker10]

Hey danke schon mal für die Antworten.
Also nochmal zum Versuchsaufbau:

Der Raspberry Pi gibt das PWM Signal aus, dies erfolgt unter verschieden Belastungen der CPU und unter verschieden Distributionen. Je nach Belastung kann es ja dann zu Verzögerungen oder Verschiebungen des PWM- Signals kommen.
Und dieses Signal will ich dann auf den Arduino Mega1280 geben an Pin ICP 4. Und dieses Signal soll dann vom Arduino Mega1280 vermessen und analysiert werden.

 

[LotadaC]

Hmm... dann mußt Du eigentlich nur jede halbphase zählen lassen. den Timer da mit draufzusynchronisieren ist wohl eher unnötig...
einfach den Timer laufen lassen. Schlägt der IC-IRQ zu, kannst Du aus dem letzten und dem aktuellen Wert des ICR (unter Berücksichtigung des TOV-Flags) die verstrichenen Timertakte berechnen.

Der RasPi hat diesbezüglich keine separate Hardware (Timer etc...)?

Du willst dann weiter die High-/low-/Periodenzeiten irgendwie auswerten? Durchschnitt, Extrema, Standardabweichung, Präzision, Richtigkeit,... oder wie?

 

[TommyB]

Der RasPi hat diesbezüglich keine separate Hardware (Timer etc...)?

Soweit ich gelesen habe hat der RasPi 4 Timer, wovon einer unbenutzt ist (einer ist für Linux, zwei für GPU)
Vielleicht relevanter Lesestoff zu diesem Topic: http://www.raspberrypi.org/forums/viewtopic.php?f=72&t=9882

 

[cheaker10]

mm... dann mußt Du eigentlich nur jede halbphase zählen lassen. den Timer da mit draufzusynchronisieren ist wohl eher unnötig...
einfach den Timer laufen lassen. Schlägt der IC-IRQ zu, kannst Du aus dem letzten und dem aktuellen Wert des ICR (unter Berücksichtigung des TOV-Flags) die verstrichenen Timertakte berechnen.

Der RasPi hat diesbezüglich keine separate Hardware (Timer etc...)?

Du willst dann weiter die High-/low-/Periodenzeiten irgendwie auswerten? Durchschnitt, Extrema, Standardabweichung, Präzision, Richtigkeit,... oder wie?

Ja genau bestimmen möchte ich die Zeiten ähnlich der Grafik:



ich poste heute Abend mal die ersten paar code Zeilen habe jetzt den Timer fast fertig konfiguriert.

 

[LotadaC]

Thomas hat ja schon einen Hinweis auf einen existenten und verfügbaren Timer gegeben - welcher scheinbar laut dem link im Mikrosekundentakt inkrementiert. Und einmal pro überlauf (wo?, wieviele Bit breit?) bzw in einem compare-event erzeugt der dann einen IRQ, oder wie? Und daraus bastelst Du Dir dann einen Soft-PWM?

Ich kenne mich mit dem RasPi nicht aus, erklär mal genauer.

Kann man das nicht sogar den Raspi mit dem freien Timer selbst messen lassen? Also wenn man weiß, daß der Timer IRQ bei Zählerstand=x erfolgt (da so eingestellt, und berücksichtigt, wielange der eigentliche IRQ-Einsprung dauert (beim AVR 7 Takte oder so), kann man doch in der Timer ISR einfach flott den Zählerstand selbst auslesen, x und die Einsprungzeit (und die Zeit die die ISR bis dahin selbst braucht) abziehen, und hat die Latenz.

Oder sind beim RasPi in der Timer-ISR andere IRQs freigegeben?
Oder ist dieser mysteriöse Timer kein Hardware-Timer?

 

[TommyB]

Wie ich das verstanden habe ist der Timer ein Hardware-Timer.
Aber man findet auch etwas widersprüchliches im Netz...

Ich kenne mich mit dem RasPi nicht aus, erklär mal genauer.

Würde ich gerne machen, aber ich habe damit noch nie etwas gemacht. Ich wage auch zu bezweifeln dass man aus Python heraus direkt auf die ISR's zugreifen kann (da Interpreter). In ASM / C hab ich auf dem RasPi noch nie was gemacht. Gerüchten zufolge (ich weiß nicht ob es stimmt, kann es mir aber vorstellen) müsste man dafür auch den Kernel anpassen und neu kompilieren, und das wäre mir definitiv zu hoch.