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