Hi, ich möchte gern bei einem ARM7 LPC die beiden UARTs so konfigurieren hardware-technisch, dass beide wirklich zur gleichen Zeit ihre Daten losschicken. Natürlich darf das Empfangen von Daten dadurch nicht benachteiligt werden. Gibt es hier eine einfache Möglichkeit diese zu synchronisieren? ARMuser
Wenn die UARTs Hardwarehandshake unterstützen, dann ja, und zwar mit der Handshakeleitung, die der UART das Senden verbietet. Sonst: Nein. Wozu?
>Gibt es hier eine einfache Möglichkeit diese zu synchronisieren?
Auf wieviel Nanosekunden musst du die synchronisieren?
Rufus t. Firefly schrieb: > Wenn die UARTs Hardwarehandshake unterstützen, dann ja, und zwar mit der > Handshakeleitung, die der UART das Senden verbietet. Vielen Dank für diese Information. Das müssten die CTS, RTS oder DSR/DTR Signale sein, oder? Kennst du eine Application Note oder ähnliches wie man diese verdrahten muss, damit Hardwarehandshake unterstützt wird? Kann das auf eine beliebige Anzahl an Uarts ausgedeht werden?
und eine kleine Zusatzfrage, sind diese Signale für alle Modis des Uarts gültig (RS232, RS422 und RS485)?
Was hindert Dich daran, im Datenblatt des von Dir verwendeten Controllers nachzusehen? Woher soll ich wissen, welcher es ist und was für eine Art von UART darin verbaut ist? Du könntest allerdings noch die Frage beantworten, wozu das ganze gut sein soll.
Rufus t. Firefly schrieb: > Was hindert Dich daran, im Datenblatt des von Dir verwendeten > Controllers nachzusehen? Woher soll ich wissen, welcher es ist und was > für eine Art von UART darin verbaut ist? die Signalleitungen sind vorhanden CTS (clear to send) und RTS (ready to send). D.h. es müssen beide RTS mit & Gatter verschachtelt werden und dann an beide CTS Eingänge (wahrscheinlich negiert) angeschlossen werden. >Du könntest allerdings noch die Frage beantworten, wozu das ganze gut >sein soll. mit zwei Uarts macht es nicht so viel Sinn (nur zur demo), wenn die Anzahl aber steigt, dann ist es schön, wenn alle Daten synchron an ihr gewünschtes Ziel ankommen. Dann ist das System einfacher zu überblicken.
soweit ich weiß werden diese CTS und RTS nur bei RS232 und RS422 eingesetzt, aber nicht bei Rs485. Dieser Bus besitzt nur zwei Leitungen für die Daten. Andreas
@ ARMuser (Gast)
>Gibt es hier eine einfache Möglichkeit diese zu synchronisieren?
Schreib die Daten direkt nacheinandwer in die UARTs. Der Versatz um ein
paar CPU-Takte spielt selbst bei 115k2 Baud keine Rolle.
MFG
Falk
hab gestern viel zu kompliziert gedacht, die RTS Leitungen sind egal, man benötigt ja nur die CTS Leitungen, die man alle zusammenschaltet und per GPIO dann auf low zieht wenn alle Uarts gefüllt sind mit Daten. Falk Brunner schrieb: > Schreib die Daten direkt nacheinandwer in die UARTs. Der Versatz um ein > paar CPU-Takte spielt selbst bei 115k2 Baud keine Rolle. ich weiß, wollt es lediglich im Hardware-Layout einbauen, dann kann ich es selbst mit eigenen Augen sehen g.
ARMuser schrieb: > ich weiß, wollt es lediglich im Hardware-Layout einbauen, dann kann ich > es selbst mit eigenen Augen sehen g. Na sowas: ein technikungläubiger Techniker... Glaubst du deinem PC auch nicht, wenn du nicht jedes einzlene Bit und jede Operation nachmessen kannst? > und per GPIO dann auf low zieht GPIOs wären mir für sowas zeitlich absolut unkritisches viel zu wertvoll.
Lothar Miller schrieb: >> und per GPIO dann auf low zieht > GPIOs wären mir für sowas zeitlich absolut unkritisches viel zu > wertvoll. wird ja nur ein GPIO benötigt und davon hab ich noch reichlich vorhanden :-) Lothar Miller schrieb: > Glaubst du deinem PC auch nicht, wenn du nicht jedes einzlene Bit und > jede Operation nachmessen kannst? da läuft auch einiges schief in so einem PC - nur mal Windows und USB betrachtet
> soweit ich weiß werden diese CTS und RTS nur bei RS232 und RS422 > eingesetzt, aber nicht bei Rs485. Dieser Bus besitzt nur zwei Leitungen > für die Daten. Das interessiert die UART nicht. Die kennt weder RS232 noch RS485 oder RS422, die kennt nur TTL-Pegel, die zur Versorgungsspannung der UART bzw. des sie enthaltenden Controllers passen.
Rufus t. Firefly schrieb: > Das interessiert die UART nicht. Die kennt weder RS232 noch RS485 oder > RS422, die kennt nur TTL-Pegel, die zur Versorgungsspannung der UART > bzw. des sie enthaltenden Controllers passen. d.h. prinzipiell kann man diese Flusssteuerung CTS RTS immer anwenden mit dem UART (bzw. diese Signale werden immer generiert) und erst durch einen folgenden Pegelwandler entscheidet sich ob man RS485 RS422 etc. rausschmeißt...
Mir scheint protokollmaessig etwas ganz falsch zu sein, wenn man UARTs per Hardware synchronisieren muss. Das ist ueblicherweise eine Aufgabe des Protokolles. Wenn das Timing derart wichtig ist, sollte man im ganzen System synchron fahren. Indem man zB einen gemeinsamen Clock hat, einen gemeinsamen Trigger und einen oder mehrere synchrone Busse
Hallo, egal wie ihr euch anstrengt (Handshake per RTS/CTS oder gleichzeitiges Schreiben in den UART). Es wird immer einen Versatz um bis zu 1/16 Bitzeit beim Sender und 1/16 Bitzeit bei den Empfängern geben, da der Baudratentakt (normalerweise Faktor 16 über Baudrate) nie ganz synchron sein wird.
Anja schrieb: > egal wie ihr euch anstrengt (Handshake per RTS/CTS oder gleichzeitiges > Schreiben in den UART). gleichzeitiges Schreiben in den UART funktioniert nicht, also bleibt nur das Handshake. Wirkt sich eigentlihc das Zusammenschalten von RTS und CTS beim Controller negativ aus, wenn ab und zu Datenpakete received werden? Die Gegenstelle hat nämlich nicht die Möglichkeit RTS CTS zu verwenden (benötigt dies aber auch nicht, da das über das Protokoll selbst ausreichend definiert ist, wann überhaupt Daten received werden können...) Anja schrieb: > Es wird immer einen Versatz um bis zu 1/16 Bitzeit beim Sender und 1/16 > Bitzeit bei den Empfängern geben, da der Baudratentakt (normalerweise > Faktor 16 über Baudrate) nie ganz synchron sein wird. Durch was genau wird dieser Versatz hervorgerufen? Liegt das in der Generierung des Baudratentaktes, weil möglicherweise Stellen nach dem Komma gerundet werden???
@ ARMuser (Gast) >> Es wird immer einen Versatz um bis zu 1/16 Bitzeit beim Sender und 1/16 >> Bitzeit bei den Empfängern geben, da der Baudratentakt (normalerweise >> Faktor 16 über Baudrate) nie ganz synchron sein wird. >Durch was genau wird dieser Versatz hervorgerufen? Durch die Arbeitsweise der UARTs. Die Steuerung arbeitet mit einem Takt, welcher der 16fachen Baudrate entspricht. MFG Falk
Also Moment. Eine Handshakeleitung signalisiert nur dem Gegenueber einen Zustand. Wielange der damit beschaeftigt ist, ist nicht definiert. Moeglicherweise wird ein Interrupt ausgeloest, moeglicherweise wird mit einem Timer gepollt, moeglicherweise steht was Wichtigeres an.
Hi >Durch was genau wird dieser Versatz hervorgerufen? Liegt das in der >Generierung des Baudratentaktes, weil möglicherweise Stellen nach dem >Komma gerundet werden??? Hier scheint einiges am Verständnis der Funktionsweise einer UART im Argen zu liegen. MfG Spess
ich glaub habs verstanden: wenn der Uart bereit ist Daten zu senden, wird die RTS Leitung auf low gezogen --> ist RTS direkt mit CTS verbunden -> die Daten werden gesendet, weil CTS dann auch auf low ist. Wenn Daten an den Uart gesendet werden, werden diese solange im FIFO des Uarts gespeichert, bis dieser voll ist -> RTS und CTS spielen hier gar keine Rolle. Der Sender an den Uart hat nämlich keinen Handshake eingebaut. D.h. die RTS und CTS haben nur symbolischen Charakter "signalisieren, dass der Empfang möglich oder nicht möglich ist", aber sperren den Empfang z.B. nicht...
RTS & CTS laufen immer ueber den Controller, das UART hat keinen direkten Zusammenhang zwischen den Handshakeleitungen und dem Schieberegistern. Das genuegt auch so, weil das UART eh fuer jedees Byste einzeln bedient werden muss. Das geht weil zwischen den Bytes genuegend Zeit ist.
> einen Versatz bis zu ... 1/16 Bitzeit bei den Empfängern geben, Oder noch mehr, abhängig vom Empfänger: es gibt auch welche mit 8-fachem Oversampling, z.B. AVR im Asynchronous Double Speed Mode. Und das sind garantiert nicht die einzigen... :-o
Nilp schrieb: > RTS & CTS laufen immer ueber den Controller, das UART hat keinen > direkten Zusammenhang zwischen den Handshakeleitungen und dem > Schieberegistern. So isses, die Handshakeleitungen sind nur extra GPIOs mit Interrupt on Change. Es wurde auch immer noch nicht die Sinnhaftigkeit des Vorhabens dargelegt. Der Empfänger wartet immer auf das Startbit und damit ist es pupegal, wann ne UART sendet. Peter
> RTS & CTS laufen immer ueber den Controller, das UART hat keinen > direkten Zusammenhang zwischen den Handshakeleitungen und dem > Schieberegistern. Das ist so nicht unbedingt korrekt. Was Du da beschreibst, ist eine UART ohne Unterstützung für Hardwarehandshake. So etwas gibt es, aber das ist glücklicherweise nicht die einzige Möglichkeit. Einerseits existierten UARTs, die sehr wohl echtes Hardwarehandshake unterstützen, andererseits existieren UARTs, die zusätzlich noch über Sende- und EmpfangsFIFOs verfügen. Und die findet man auch in µCs. Da --wie ich bereits kritisiert hatte-- der Threadersteller nicht beschrieben hat, welchen µC er verwendet ("LPC" ist nicht ansatzweise ausreichend genau, auch nicht, wenn ARM7 dazu genannt wird), können wir nur raten. Es gibt beispielsweise von Philips/NXP ARM7-Varianten aus der LPC2xxx-Reihe, deren UARTs dem PC-Klassiker 16550 enstpricht - und das ist 'ne UART mit Sende- und Empfangs-FIFOs und Hardwarehandshake.
Rufus t. Firefly schrieb: > LPC2xxx-Reihe, deren UARTs dem PC-Klassiker 16550 enstpricht - und das > ist 'ne UART mit Sende- und Empfangs-FIFOs und Hardwarehandshake. Dann sag mir mal, wo im Datenblatt das steht: http://www.google.de/url?sa=t&source=web&ct=res&cd=3&ved=0CBQQFjAC&url=http%3A%2F%2Fwww.national.com%2Fds%2FPC%2FPC16550D.pdf&ei=wuZIS66fCduh_AaV0PGgAg&usg=AFQjCNHdc9W4k68aWPnn6keU1fHQrzGSXA Die Modem-Controll-Logic ist völlig abgekoppelt von der UART-Funktion. Peter
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.