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
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
>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
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
@ 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
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
@ 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
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
@ 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 . .
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
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
@ 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
>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
