Forum: Mikrocontroller und Digitale Elektronik zeitversatz trotz identischer Hardware


von alex (Gast)


Lesenswert?

Hallo,

ich habe folgende Frage. Ich habe zwei ATMEL644 mit angeschlossender RTC 
(32kHz) an Timer2 (asynchroner Mode, Prescaler 64). Aller 500ms wird ein 
Overflow Interrupt ausgelöst, der ein Port toggelt (und später noch 
andere Sachen machen soll, momentan nur testweise). Beide Controller 
laufen mit dem gleichen Quarz (nicht mit dem selben!) und sind über ein 
Interruptfähiges Pin mit einer Sync-Leitung verbunden. Wenn ich einen 
Schalter betätige passiert auf beiden Controllern in der ISR genau das:

ISR(INT1_vect) {
 if(done.calib) {
  PORTA &= ~(1<<PA5);
  EICRA &= ~(1<<ISC11) & ~(1<<ISC10);  //switch off ext. interrupt1 
source
  EIMSK &= ~(1<<INT1);      //disable ext. interrupt1
  TCCR2B &= ~(1<<CS22) & ~(1<<CS20);  //timer2 off
  while(!(ASSR & (1<<TCR2BUB)));
  TCNT2 = 0;        //clear timer register
  while(!(ASSR & (1<<TCN2UB)));
  TCCR2B |= (1<<CS22) | (1<<CS20);  //timer2 on
  while(!(ASSR & (1<<TCR2BUB)));
  time.stamp = 0;
  time.sync = 0;
  done.sync = 0;
  LED_OFF;
  led_toggle(200, LED_GREEN);  //switch on LED toggling every 200ms
 }
}

beide Controller hängen am selben Taster und trotzdem habe ich nach der 
ISR einen Zeitversatz von 1,7ms.

kann mir da jemand weiterhelfen. Ein paar us wegen der Quarztoleranz 
kann ich mir ja vorstellen, aber 1,7ms finde ich etwas merkwürdig.

zur Ergänzung: der ext. Interrupt, an dem der Taster hängt wird erst 
nach vier sekunden wieder freigegeben. Prellen ist also ausgeschlossen.

Gruß, Alex

von Peter D. (peda)


Lesenswert?

alex wrote:

> beide Controller hängen am selben Taster und trotzdem habe ich nach der
> ISR einen Zeitversatz von 1,7ms.

Ein 32khz Quarz kann mehrere Sekunden benötigen zum Anschwingen.
1,7ms Unterschied sind da garnichts.


> zur Ergänzung: der ext. Interrupt, an dem der Taster hängt wird erst
> nach vier sekunden wieder freigegeben. Prellen ist also ausgeschlossen.

Man kann Prellen unterdrücken, aber so nicht.
Dem Interrupt-Pending-Flag ist es vollkommen wurscht, ob der Interupt 
freigegeben ist.
Der Preller wartet die 4s geduldig ab und schlägt dann zu.


Und die 200ms Zeitvernichtung im Interrupt werden Dir irgendwann große 
Probleme bereiten.


Peter

von Teplotaxl X. (t3plot4x1)


Lesenswert?

>Und die 200ms Zeitvernichtung im Interrupt werden Dir irgendwann große
>Probleme bereiten.

Wer sagte da mal so schön, dass sich Conrad Zuse dabei mit 10000 rpm im 
Grabe umdrehen würde :D

von alex (Gast)


Lesenswert?

kurze korrektur:  die RTC, die den Timer taktet läuft permanent. Ich 
lösche ja nur das Zählerregister.
zur Entprellung: nach vier sekunden lösche ich das Interruptflag des 
externen Interrupts und gebe diesen wieder frei. Bis dahin sollte die 
Taste doch fertig sein mit prellen.

welche 200ms Zeitvernichtung? led_toggle? Damit setzte ich nur eine 
Variable, damit mir dann der Timer1 Interrupt, den ich für verschiedene 
Zeitvariblen nutze, das Lämpchen an- und ausschaltet.

So richtig kann ich mir den Zeitversatz trotzdem nicht erklären.

            danke, und gruß Alex

von Falk B. (falk)


Lesenswert?

@ alex (Gast)

>kann mir da jemand weiterhelfen. Ein paar us wegen der Quarztoleranz
>kann ich mir ja vorstellen, aber 1,7ms finde ich etwas merkwürdig.

Naja, was erwartest du, wenn du den Timer erstmal anhältst? lass ihn 
laufen! Und setz ihn einfach neu. Das passt. Du musst dann auch nicht in 
der ISR auf das Ende des Updates warten.

Wenn du einen Sleep Mode verwendest, kann dir die Aufwachzeit die 
Petersilie verhageln.

Und dein Versatz wird zuverlässig nicht nicht kleiner als ~30us zu 
kriegen sein, nämlich einen 32K Takt. Und die Phasendifferenz wird auch 
mit der Zeit weglaufen, schaus dir mal ne Weile auf dem Oszi an.

MFG
Falk

von alex (Gast)


Lesenswert?

30 us wären super, die drift ist auch akzeptabel, habe ich schon mit dem 
oszi begutachtet, hat das datenblatt bestätigt. das passt soweit und 
liegt alles im rahmen. wundere mich eben nur, warum der unterschied so 
groß ist, wenn alles identisch ist.dass ich imer einen phasenversatz 
haben ist klar. werde es mal versuchen ohne den timer zu stoppen.
danke für den tipp. eine frage noch. warum ist es so ungünstig, den 
timer anzuhalten? ich meine, einschwingen muss ja nix, weil alles schon 
läuft.

gruß, alex

von Falk B. (falk)


Lesenswert?

@ alex (Gast)

>danke für den tipp. eine frage noch. warum ist es so ungünstig, den
>timer anzuhalten? ich meine, einschwingen muss ja nix, weil alles schon
>läuft.

Irrtum mein Freund! Wenn das Ding deaktiviert wird, wird er angehalten!
Probiers aus, ohne Stop/Start.

MFG
Falk

von alex (Gast)


Lesenswert?

der fängt also nicht einfach nur an zu zählen, wenn ich ihn aktiviere, 
sonder muss einschwingen, auch wenn draußen ein gepufferter takt mit ttl 
pegel anliegt? na wieder was gelernt.

danke, alex

von Falk B. (falk)


Lesenswert?

@  alex (Gast)

>sonder muss einschwingen, auch wenn draußen ein gepufferter takt mit ttl
>pegel anliegt?

NEIN! Dann natürlich nicht! Du schriebst aber

> Beide Controller laufen mit dem gleichen Quarz (nicht mit dem selben!)"

Das sin ZWEI Quarze, mit nominal gleicher, real aber geringfügig 
verschiedener Frequenz.

> na wieder was gelernt.

Naja . . . mal nachdenken oder so . .

von Peter D. (peda)


Lesenswert?

Vielleicht solltest Du mal den kompletten Code und Schaltplan 
reinstellen (als Anhang!), damit man weiß, was Du eigentlich meinst und 
wie Du es mißt.


Die andere Frage, wozu willst Du es wissen?

In der Regel machen verschiedene MCs ja verschiedene Sachen, d.h. sie 
laufen eh nie Zyklus-synchron.


Will man 2 MCs synchronisieren, geht das am einfachsten über den 
CAN-Bus. Die CAN-Hardware kann den Zeitstempel einer Nachricht auslesen 
und den sendet man dann als nächste Nachricht zu dem anderen Teilnehmer. 
Der kann dann die Differenz zum Zeitstempel der Sync-Nachricht ermitteln 
und damit seinen Timer justieren.


Peter

von alex (Gast)


Lesenswert?

ich werde mal etwas ausholen, offensichlich habe ich mich etwas schlecht 
ausgedrückt.
zur hardware: zwei controller mit quarz (selbe frequenz) und RTC mit 
32khz ttl am timer2, diese clockt nur den timer2, sonst nix und läuft 
permanent. am controller hängt jeweils ein funkmodul an der uart. es 
werden permanent messdaten gesendet, die zur späteren synchronisation im 
pc mit einem zeitstempel versehen werden, der aller 500ms im timer2 
generiert werden soll. ich möchte also nicht die controller synchron 
haben, sondern nur die timer2. das mit dem gleichen quarz habe ich 
vorhin nur geschrieben, damit nicht die frage danach kommt, 
prophylaktisch quasi.
vielleicht noch ein par worte zur firmware.

timer1 ist als 1 ms uhr konfiguriert, für wartefunktion und verschiedene 
zeitbasen usw.
timer2 s.o.
das bischen daten auslesen und senden gschieht in der mainloop.

ich hoffe, jetzt ist es etwas verständlicher.
quelltext kann ich morgen ml posten, wenn erwünscht.

danke, alex

von Falk B. (falk)


Lesenswert?

@ alex (Gast)

>generiert werden soll. ich möchte also nicht die controller synchron
>haben, sondern nur die timer2.

Dann müssen sie aus EINER Taktquelle gespeist werden.
Warum eigentlich zwei AVRs? haben die Sooooo viel zu tun?

>timer1 ist als 1 ms uhr konfiguriert, für wartefunktion und verschiedene
>zeitbasen usw.

AHA! Und wie verhinderst du, dass während deines Tastendrucks nicht 
zufällig eine andere ISR aktiv ist und damit deine Synchronisation 
verzögert?

MFg
Falk

von alex (Gast)


Lesenswert?

>Warum eigentlich zwei AVRs? haben die Sooooo viel zu tun?

weil es am ende zwei geräte sind, die räumlich voneinander getrennt 
sind.

>Dann müssen sie aus EINER Taktquelle gespeist werden.

da das aus oben genanntem grund nicht möglich ist, dachte ich, ich nehme 
zwei rtc mit geringer ungenauigkeit. die verwendete (ds3234) hat eine 
frequenzabweichung von 2ppm. das passt auch für meine zwecke, da die 
zeitstempel nur für eine gewisse zeit einen bestimmten zetversatz nicht 
überschreiten sollen.

>AHA! Und wie verhinderst du, dass während deines Tastendrucks nicht
>zufällig eine andere ISR aktiv ist und damit deine Synchronisation
>verzögert?

im moment noch gar nicht, aber danke für den tipp. hatte das wohl etwas 
außer acht gelassen bzw. das als nicht ganz so wichtig erachtet, was 
vielleicht ein fahler war. allerdings habe ich festgestellt, dass der 
versatz immer ziemlich gleich ist, etwa 1,7ms, wie schon erwähnt. das 
spräche ja gegen einen zufällig dazwischenfunkenden interrupt. ich werd 
das aber morgen mal testen. vielleicht sollte ich noch eine zusätzlich 
leitung einführen zwischen den controllern, für eine art handshake, so 
nach dem motto. ich bin bereit, ich auch, na dann NULL. ich hatte 
gehofft, das vermeiden zu können.

für weitere anregungen und tips bin ich euch dankbar

danke alex

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
Noch kein Account? Hier anmelden.