Guten Abend zusammen, ich bastel gerade an einem Projekt, bei dem zwei Prozessoren (Atmel SAM V71 @ 300Mhz) parallel in etwas Entfernung arbeiten, aber ständig synchronisiert werden müssen, damit die gesammelten Daten an beiden Enden entsprechend übereinstimmen. Ich dachte nun an eine Time-Sync Leitung á la "Beim nächsten Ton ist es 12 Uhr. PIEP!", über die der Taktgeber (Master) beim Slave einen Interrupt auslöst und ihn damit regelmäßig mit der eigenen Zeit synchronisiert. Eine weitere Bedingung wäre ebenfalls, dass die beiden auch die Rollen tauschen können. Nun wird die Leitung wohl so um die 10 Meter lang, ich dachte also an ein BNC-Kabel mit entsprechender Schirmung und richtiger Terminierung am Ende, sodass keine bösen Reflexionen entstehen. Nun meine Frage: Wie händle ich die Terminierung, wenn die Richtung bei Bedarf auch umgekehrt sein darf? Serienterminierung an beiden Enden? Ich durchstöbere jetzt schon eine ganze Weile das zugehörige Datenblatt zum Prozessor, finde dort aber leider keine Angaben zum Flankenanstieg/-abfall. Höchstens auf S. 2085 wird mal erwähnt, wo die Maximalfrequenz und Mindestpulslänge der GPIOs liegen. Aber daraus werde ich nicht schlau, wo ist hier die Flankengeschwindigkeit?? Auch egal, ein Treiber mit schön langsamen Flanken ist hier sowieso sinnvoller, als die Pins direkt anzuhängen. Aber die Frage mit der Terminierung an beiden Enden bleibt. Link zum Datenblatt (Achtung, groß!): http://ww1.microchip.com/downloads/en/DeviceDoc/SAM-E70S70V70V71-Family-DataSheet-DS60001527C.pdf
Wie Einstein schon festgestellt hat, ist das mit der Gleichzeitigkeit so eine Sache. Wie genau müssen die Prozessoren synchronisiert sein? Bei 300MHz entsprechen 10m schon 10 Wellenlängen im Vakuum, auf einem Kabel noch mehr. Jan W. schrieb: > Link zum Datenblatt (Achtung, groß!): > http://ww1.microchip.com/downloads/en/DeviceDoc/SAM-E70S70V70V71-Family-DataSheet-DS60001527C.pdf Du meintest sicher "relativ groß" - aber in Bezug auf was? ;-)
Warum nicht Ethernet oder IPoverSerial und dann 802.1as, das ist genau dafür gebaut. Du kannst auch den Kern von 802.1as über was anderes senden als Ethernet, aber das macht es einfacher. Zur not tuts auch ein NTP Server und Client. Die Kompensierung ist drinnen und die Zeit bekommst du auch noch. Warum was neues Erfingen, wenn es sowas schon gibt. Deswegen der Fingerpoint auf 802.1AS :) Dann kommt es nur noch auf deine Präzision drauf an, die du haben willst.
Wenn es keine Raketentechnik ist, wird wohl NTP-Genauigkeit 10ms reichen? https://de.wikipedia.org/wiki/Network_Time_Protocol#Fehler,_Algorithmus_und_Genauigkeit
Wenn über Signalreflektionen diskutiert wird, geht es wohl eher um Nanosekunden, mal abgesehen davon, dass die erste Flanke wohl ankommen wird, egal was hinterher durch die Gegend reflektiert wird.
Wolfgang schrieb: > Bei 300MHz... Das ist ja nur die Taktrate des Prozessors! Mein Problem ist nur die schnelle Flanke, die Reflektionen verursacht. Zwischen den einzelnen Pulsen kann auch gerne eine halbe Ewigkeit liegen! Wolfgang schrieb: > Wenn über Signalreflektionen diskutiert wird, geht es wohl eher um > Nanosekunden Nanosekunden müssen es nicht sein, es ging eher darum, dass eine Reflektion nach etwas Zeit weitere Interrupts auslösen könnte. Ich dachte an ein paar ms zwischen den einzelnen Zeitpulsen, der Slave würde dann dieses Zeitinterval auf die jeweils letzte Zeit draufrechnen und den eigenen Drift damit korrigieren. Bei einer Reflexion würden diese paar Millisekunden dann gleich mehrmals draufgerechnet werden. oszi40 schrieb: > Wenn es keine Raketentechnik ist, wird wohl NTP-Genauigkeit 10ms > reichen? Ironischerweise ist das ganze Komponente einer Testanlage für CubeSats. Aber trotzdem: 10 ms wären mir ausreichend :) Nur kann ich eben an beide Prozessoren kein LAN hängen, sondern bin so ziemlich darauf beschränkt mit einem GPIO zu arbeiten.
Jan W. schrieb: > zwei Prozessoren (Atmel SAM > V71 @ 300Mhz) Die Dinger werden doch normal über Quarze getaktet und aus diesem Takt werden dann per PLL die internen Takte erzeugt. > Nun wird die Leitung wohl so um die 10 Meter lang, ich dachte also an > ein BNC-Kabel Warum machst Du es dann nicht so: Du verwendest keine Quarze, sondern auf der einen Seite einen Quarzoszillator mit LVCMOS-Ausgang. Der Prozessor auf der lokalen Seite bekommt das direkt so für seine PLL. Für den Takt der Gegenseite pufferst Du das Signal mit einem Logikgatter, Serienterminierung, und gehst dann auf die Leitung zur anderen Seite. Dort bekommt es der andere Prozessor als Eingang für seine PLL. Auf diese Weise sind beide Prozessoren immer synchron getaktet und die Zeit zwischen denen driftet nicht irgendwie. Das dürfte normalerweise schon die allermeisten Synchronisationsprobleme lösen.
Wahrscheinlich sollen diese CPUs total unabhängig voneinander arbeiten und NUR die selbe Zeit haben wegen der Ausfallwahrscheinlichkeit. Daß beide 100% taktgleich arbeiten, scheint mir etwas optimistisch.
Jan W. schrieb: > Nur kann ich eben an beide Prozessoren kein LAN hängen, sondern bin so > ziemlich darauf beschränkt mit einem GPIO zu arbeiten. Schade. Bei LAN (100 Mb/s oder GbE) hätte ich dir PTP (IEEE 1588) empfohlen, sofern der NIC Harware Timestamping unterstützt. https://en.wikipedia.org/wiki/Precision_Time_Protocol Bei einer TTL-Leitung fällt mir noch IRIG-B ein. https://en.wikipedia.org/wiki/IRIG_timecode Vielleicht hilft es auch noch, sich die Schnittstellen/Anleitungen von Uhren kommerzieller Anbieter anzuschauen, z.B. Meinberg: https://www.meinberg.de/german/products/modulare-3he-ieee-1588-grandmaster-uhr.htm (Im Handbuch zu dieser Uhr gibt es auch weitere Informationen zu IRIG: "16.9 Time Code", S.133) Da sehe ich als Schnittstellen: PTP, 10 MHz, 2.048 MHz, PPS, NTP, SNTP, IRIG-B DCLS+AM Genauigkeiten: Musst du deine Schaltungen absolut synchronisieren, oder nur relativ (Drift?)? Multi-Master-Modus/automatisches failover zur anderen Uhr (wie Fehler erkennen?), oder schaltest du manuell zwischen Master/Slave um? Wie lange darf die Synchronisierung dauern (kann schon mal einige Minuten dauern, wenn man <1us möchte)?
oszi40 schrieb: > Wahrscheinlich sollen diese CPUs total unabhängig voneinander arbeiten > und NUR die selbe Zeit haben wegen der Ausfallwahrscheinlichkeit. hmm, der TO müsste dafür das dahinterstehende Problem genauer erklären. > Daß > beide 100% taktgleich arbeiten, scheint mir etwas optimistisch. Die Prozessoren werden nicht 100% taktgleich arbeiten, da z.B. die PLLs beim starten unterschiedlich lange zum locken brauchen etc. Aber wenn die PLLs einmal gelockt sind, werden die Clocks der Prozessoren nicht mehr voneinander driften. Das macht vieles schon deutlich einfacher. Wenn beide Prozessoren z.B. eine bestimmte Anzahl von Samples eines Signals aufnehmen, ist die Frequenz des Sampelns bei beiden Prozessoren exakt gleich. Sie haben nur eine Phasenverschiebung, die bleibt aber auch konstant. Die könnte man also einmalig bestimmen und dann auch ausgleichen.
Kennt hier jemand eine vernünftig Dokumentierte Ieee 1588 Implementierung für Stm32F7 Prozessoren? Gerd E. schrieb: > Aber wenn die PLLs einmal gelockt sind, werden die Clocks der > Prozessoren nicht mehr voneinander driften. Das macht vieles schon > deutlich einfacher. Nein die stm32 pll ist nicht perfekt selbst mit rubidium Frequenz normal als Eingangstakt kommt da auf Dauer ein beachtlicher Fehler zusammen. Die frequenz steigt kontinuierlich und fällt dann Sprunghaft an, die passiert defining nicht synchron.
Wahrscheinlich ist es ein Irrweg die Zeit auf beiden CPUs taktgenau zu bekommen. Nützlicher wäre, Arbeitsstände zu vergleichen und so zu prüfen daß irrtümliche Interrupts keine Auswirkung haben können. Denn eine wilde CPU könnte 1000 Interrupts/s liefern und eine tote gar keine.
Jan W. schrieb: > Nanosekunden müssen es nicht sein, es ging eher darum, dass eine > Reflektion nach etwas Zeit weitere Interrupts auslösen könnte. Bis der Interrupt abgearbeitet ist, sind die Reflektionen höchstwahrscheinlich Geschichte. Man sollte das IF vielleicht nicht gerade am Anfang der ISR löschen. Bei 10m Kabel liegen zwischen den Reflektionen um die 100ns. Wie lange braucht denn deine ISR?
Jitterer schrieb: > Nein die stm32 pll ist nicht perfekt selbst mit rubidium Frequenz normal > als Eingangstakt kommt da auf Dauer ein beachtlicher Fehler zusammen. Jitter gibt es natürlich, klar. Aber bei einem Takt der Eingangsclock kommt doch hinten aus der PLL immer die selbe Anzahl an Ausgangstakten raus. Das werden doch nicht mal mehr oder mal weniger Takte. > Die frequenz steigt kontinuierlich und fällt dann Sprunghaft an, die > passiert defining nicht synchron. ?
Jitterer schrieb: > Kennt hier jemand eine vernünftig Dokumentierte Ieee 1588 > Implementierung für Stm32F7 Prozessoren? Nicht für STM32F7, aber die Linux Implementierung ist eigentlich ganz gut leserlich: http://linuxptp.sourceforge.net/ Zum Verständnis von PTP selber fand ich das Datenblatt zum Intel X710 Controller sehr hilfreich (Gegenseite zum PTP Client und Kernel: "8.5. TimeSync (IEEE1588 and 802.1AS)", S.1053): https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/xl710-10-40-controller-datasheet.pdf Linux Implementierung zu clock_gettime ist auch interessant: verwendet den TSC mit regelmäßig aktualisierten Parametern zur Kompensation des TSC-Drift etc. Ähnliches könnte man vermutlich auch mit einem Timer auf einem uC machen: https://elixir.bootlin.com/linux/v4.19.1/source/arch/x86/entry/vdso/vclock_gettime.c#L230 und
1 | struct vsyscall_gtod_data |
siehe: https://elixir.bootlin.com/linux/v4.19.1/source/arch/x86/include/asm/vgtod.h#L17
Stoerungen scheinen mir bei 10m schon relevant. Deshalb auf beiden Seiten zwischen Controllereingang und Leitung einen Tiefpass setzen. Den Impuls per getrenntem Ausgangspin ueber einen (kleineren) Widerstand auf die Leitung geben. So kann sogar jeder Teilnehmer seine Flankensteilheit und somit Impulsverzoegerung selbst messen.
1 | Ausgang o-------[R]--| |-----[R]-------o Ausgang |
2 | Eingang o-------[R]--|----------//-------|-----[R]-------o Eingang |
3 | | | |
4 | [C] [C] |
5 | | | |
6 | GND GND |
Ueber sowas haben sich die wirklichen Experten schon den Kopf zerbrochen: White Rabbit ist dabei herausgekommen. Aber wer an solchen Themen arbeitet, wie zeitsynchrone Erfassung von Messdaten kennt sowas eigentlich und muss hier nicht dumm fragen. Taktgenaue Synchronisation ging vielleicht mit Z80 und MC68000. Aber bei heutigen Controllern mit aus PLL hergeleiteten internen Takten wird das eher nichts. Vermutlich taugt das Gesamtkonzept einfach nichts.
@gerd.Hier wird es genauer beschrieben : https://jaybee.cz/software/stm32-hse-oscillator-stability-problem/ http://blog.dan.drown.org/gps-module-measurements/
Natuerlich kann man beide Prozessoren auf den Takt genau synchronisieren. Indem man den ursruenglichen Clock per PLL aufeinander synchronisiert. Ich wuerde die wahrscheinlich 10MHz, die der Controller am Clockeingang bekommt, per PLL auf den anderen Synchronisieren. Bedeutet einer startet als Master, die koennen das auch per normaler Kommunikation aushandeln. Der Master gibt den Takt vor, der andere synchronisiert drauf. Dann laufen beide Uhren zumindest schon mal synchron. Es gibt Clocksynchronisierer, mit Failover spezifikation. zB AD9548. Der kann Stratum 2 Failover. Dass die beiden Uhren nicht immer im Failover laufen, sollte man periodisch den Clock uebermitteln. Der kann dann auch auf tieferer Frequenz laufen. zB 1Hz. Der 9548 kann auch das. Wenn die beiden Clock dann schon mal synchon laufen, kann man per Protokoll die Zeit uebergeben. Alles andere macht wenig Sinn. Und vergiss den GPIO dafuer zu verwenden. Es gibt eigentlich nur Clock, oder subclock.
:
Bearbeitet durch User
Am einfachsten läßt sich das mit dem CAN-Bus erreichen, da der CAN-Controller den Timestamp jeder Nachricht speichert. Zuerst schickt man eine Sync-Nachricht von der sich beide den Timestamp merken. Dann schickt man eine Nachricht mit der Uhrzeit, zu der die Sync-Nachricht übertragen wurde. Anhand seines Timestamps kann nun der Empfäger seine Uhr korrigieren. Bei 1MBaud ist man so auf 1µs genau.
> Bei 1MBaud ist man so auf 1µs genau.
Eher nicht. Bezogen auf den Clock der einen Station mag das stimmen. Die
Meldung kommt bei der anderen Station rein, und bleibt dort erst mal
etwas liegen. Dann wird die Meldung auseinandergezerrt und allenfalls
irgendwohin geschrieben. Und schwupp sind 20us weg, mit Jitter.
Deswegen laufen die Uhren aber noch nicht synchron. Ausser man koenne
den CAN Clock fuer den PLL des anderen verwenden. Wenn der Clock dann
sichtbar waere.
Name H. schrieb: > Die > Meldung kommt bei der anderen Station rein, und bleibt dort erst mal > etwas liegen. Das ist ja gerade der Trick, das diese "Liegezeit" keinen Einfluß hat. Der Timestamp wird von der CAN-Hardware bei RXOK/TXOK automatisch gespeichert. Kriegt man dann die Uhrzeit zum Zeitpunkt des Stamps, addiert man die Zeitdifferenz des CAN-Timers drauf und setzt damit seine Uhr. Die Rechenzeit für das Lesen des CAN-Timers, eine Subtraktion, eine Addition und Laden der RTC dürfte beim ARM weit unter 1µs betragen.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.