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 | void InitMAM(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.
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.