Hallo Leute,
ich möchte zwei LPC2468_Boards von Embedded Artists für UART Aufnahmen
benutzen, das besondere daran ist, dass die beiden Boards einen gleichen
Zeitbasis haben müssen um ihre serielle Daten mit einem identischen
Zeitstempel zu versehen, was mir ermöglicht, die Daten mit einander
vergleichen zu können, d.h. die Boards müssen unter sich
synchronisieren.
Ich habe es mir so überlegt:das erste Board toggelt einen Pin alle 500
ms, dieser Pin ist mit einem Capture-Pin von dem zweiten Board verbunden
und bei jedem Event setzt das zweite Board seinen Zeitstempel-Timer
zurück, der mit einer Auflösung von 100ns läuft.
Gesagt getan, nun gibt es einen Jitter von bis zu 3,5us,
woher..? weiss ich nicht.
Der Pin vom ersten Board ist direkt mit dem von zweitem verbunden, und
der FIQ-Interrupt braucht 28 Taktzyklen in worst-case(laut ARM Reference
Manual) in meinem Fall sind das ca. 500ns bis er in die ISR eintritt und
da wird der Millisekunden Counter inkrementiert und der Timer Counter
von dem Zeitstempel-Timer zurückgesetzt, wo vergehen denn die ganze 3us?
Im Anhang sind die Code-Stücke zu finden, die das Problem betriffen.
Eure Meinungen sind mir sehr wichtig.
Vielen Dank!
Kannst du für beide uCs ein Taktsignal erzeugen und damit einen internen
Timer hochzählen lassen? Die müssten dann auf beiden uCs den selben Wert
haben.
Ist nur ein genereller Gedanke, kenne deine uCs nicht.
Was du meinst geht auch, aber dann habe ich Werte, die ich nicht
miteinander vergleichen kann, da die beiden uC's mit verschiedenen
Taktquellen betrieben werden.
Danke trotzdem für deine Antwort, die mir Hoffnung gegeben hat.
Die Datei wurde 5 mal heruntergeladen, und nur eine Antwort bekommen,
das ist echt deprimierend!
Leute ich habe mir richtig viel mühe gegeben um das Problem
darzustellen, ich hoffe das es umsonst war?
Kann niemand z.B. nachschauen, ob die Timer richtig initialisiert sind?
dann könnte ich das zumindest ausschliessen!
Ich hab das anders gemeint. Zum Synchronisieren wird eine gemeinsame
Quelle benötigt, egal wie diese Quelle aussieht.
Das muss nicht HCLK sein.
Alles andere wird asynchron, wie du schon selbst gemerkt hast.
Ohne Quarz variiert der Takt der uCs um ca. 3%. Das kann bei dir
im Extramfall einen Taktunterschied von 6% ausmachen.
3us könnte die Zeit sein, die dein uC braucht, bis er auf einen
IRQ reagiert.
@Tilo,
3% Ungenauigkeit ohne Quartz? Du sprichst definitiv von einem anderen
Micro!
@Rifman,
Dein Code muss den Capture Wert und den aktuellen Timer Wert vergleichen
und diese Zeit als Korrektur verwenden um den Jitter auszugeleichen.
Besteht in deinem Programm die Moeglichkeit bei einem Capture den Timer
zurueckzusetzen? D.h. bei einem Capture Event kann der Timer mit einem
vorgegebenen Wert geladen werden, der koennte auch 0 sein. Dann laeuft
der Timer einfach weiter und was immer in dem Timer steht wenn du ihn
ausliest ist die Zeit, die vergangen ist seit das externe Capture Signal
aufgetaucht ist.
Noch ein paar Tips:
Den Vorteiler fuer diesen Timer auf 1 setzen, damit die maximale
Genauigkeit erreicht wird.
MAMTIM ist evtl. noch im Default Zustand, mal auf 3 setzen (siehe
Manual), der Micro laeuft schneller -> weniger Zeitverzug
hth, Robert
@Robert Teufel.
Vielen Dank für deine Antwort und deine Tips. Da sind aber ein Paar
Punkte, die ich nicht verstehe:
>Dein Code muss den Capture Wert und den aktuellen Timer Wert vergleichen>und diese Zeit als Korrektur verwenden um den Jitter auszugeleichen.
Welcher Timer Wert meinst du denn? Vom Taktgeber(1.uC) oder der Ns-Timer
im (2.uC).Wenn du das erste meinst warum denn? Es sind ja 500ms.
>Besteht in deinem Programm die Moeglichkeit bei einem Capture den Timer>zurueckzusetzen? D.h. bei einem Capture Event kann der Timer mit einem>vorgegebenen Wert geladen werden, der koennte auch 0 sein. Dann laeuft>der Timer einfach weiter und was immer in dem Timer steht wenn du ihn>ausliest ist die Zeit, die vergangen ist seit das externe Capture Signal>aufgetaucht ist.
Meinst du vielleicht, dass ich das ganze mit einem Timer realisieren
kann?
>MAMTIM ist evtl. noch im Default Zustand, mal auf 3 setzen (siehe>Manual), der Micro laeuft schneller -> weniger Zeitverzug
Ich habe die MAM-Initialisiereung von einem anderen Projekt übernommen,
und ist schaut wie folgt aus:
1
voidInitMAM(void)
2
{
3
MAMCR=0x00;/* Off */
4
MAMTIM=0x04;/* 4 Fetch cycles, gives better result than 3 */
5
MAMCR=0x02;/* Fully enabled */
6
7
MEMMAP=0x01;/* Uses interrupts vectors in flash */
8
}
Was meist du soll ich MAMTIM trotzdem ändern?
Vielen Dank!
Noch was, ich will dich noch darauf aufmerksam machen(falls du das
übersehen hast), dass die Code-Segmente, die das Problem betreffen, im
ersten thread zu finden ist.
