Serielle Kommunikation über 3 m Kabel, gemeinsam mit USB

Ich entwerfe ein System, das serielle Kommunikation über ein Standard-USB-Kabel sowie über normales USB (aber nicht gleichzeitig) ausführen muss. Mit anderen Worten, wenn es an einen PC angeschlossen wird, erscheint es als USB-Gerät und wenn es an ein eingebettetes System angeschlossen wird, verwendet es ein einfacheres serielles Kommunikationsprotokoll. Die USB-Seite hat nur volle Geschwindigkeit (12 Mb/s), und die serielle Kommunikation muss nur 100 Kb/s betragen, obwohl 1 Mb/s schön wäre.

Das eigenständige Gerät verwendet einen Mikrocontroller für die Kommunikation. Sowohl das Gerät als auch das eingebettete System werden Mikrocontroller-basiert sein, höchstwahrscheinlich Atmel XMEGA. Eine Option wäre, ein Gerät mit USB-OTG/Host-Unterstützung auszustatten, aber ich möchte diese Komplexität, Kosten und begrenzte Auswahl an Mikrocontrollern vermeiden.

Die XMEGA-Mikros haben UART- und SPI-Peripheriegeräte an denselben Pins wie USB D+/D-. Ich könnte I2C auch von zwei anderen Pins zu ihnen leiten, und ich glaube nicht, dass dies die Signalqualität beeinträchtigen würde. Da das USB-Kabel nur zwei Leitungen hat, wenn ich SPI verwenden würde, wäre es unidirektional, was ich verkraften könnte. Bidirektionales I2C oder 3,3 V RS232 wären jedoch schön.

Hat jemand so etwas versucht? Ich bin ein wenig besorgt über die Kapazität eines 3 m langen USB-Kabels, das Probleme verursacht. Keines dieser seriellen Protokolle ist differentiell, sollte aber mit schlechten Signalflanken fertig werden. Sie können Leitungstreiber für I2C/SPI/TTL-RS232 erhalten, aber die, die ich mir angesehen habe, scheinen USB zu stören, wenn sie nicht verwendet werden. Wenn man darüber nachdenkt, könnte I2C ohne Leitungstreiber aufgrund der Notwendigkeit von Pull-up-Widerständen problematisch sein.

Nach einigen Recherchen tendiere ich zu 3,3 V RS232. Ich könnte SPI verwenden, aber synchrone Protokolle können bei hohen Geschwindigkeiten Probleme mit einem 3-m-Kabel haben. Wenn der Empfänger die Uhr generiert, gibt es eine gewisse Verzögerung, bevor der Sender sie sieht und die Antwort eintrifft. Wenn der Sender den Takt erzeugt, gibt es kein Verzögerungsproblem (da Daten um den gleichen Betrag verzögert werden), aber es verkompliziert etwas die Zwei-Wege-Kommunikation. Der andere Nachteil von SPI ist das Fehlen von Start-/Stopp-Bits, ist aber normalerweise kein Problem, da Sie eine Aktivierungsleitung verwenden können, um die Kommunikation an einem bekannten Punkt zu starten, aber ich habe nicht genügend Leitungen für eine.

Andererseits kann es den zusätzlichen Aufwand auf der Protokollseite wert sein, getaktet zu werden, damit es bei Signalverschlechterung robuster sein sollte. Abschlusswiderstände sollten helfen, mit Reflexionen fertig zu werden.

In jedem Fall sollte eine einigermaßen hohe Geschwindigkeit möglich sein. Die Sony Playstation verwendet SPI bei 3,3 V mit einem 500-kHz-Takt und funktioniert gut mit langen Leitungen. Der N64 verwendet eine einzelne aysnc-Datenleitung (kein Takt) bei etwa 333 kHz, wiederum über lange Leitungen.

Antworten (2)

Mein Rat ist, einen UART und RS485 zu verwenden.

Wenn Sie versuchen, ein nicht differenzielles Signalisierungsprotokoll auf einer so langen Leitung zu verwenden, erhalten Sie eine schreckliche BER bei nützlichen Datenraten. Differentielles Halbduplex-Async ist der richtige Weg.

Ihre Bedenken hinsichtlich der gemeinsamen Nutzung des Busses mit USB sind berechtigt, aber RS485-Treiber können (im Allgemeinen) in einen hochohmigen Modus versetzt werden, der möglicherweise bereit ist, mit USB zu koexistieren.

Guter Punkt. Es würde bedeuten, einen zusätzlichen Treiberchip hinzuzufügen, da nur wenige Mikros ein 485-Peripheriegerät eingebaut haben, aber es könnte sich lohnen. Glaubst du wirklich, dass ich wahrscheinlich signifikante Fehler über 3m sehen werde? Beispielsweise verwendet die Playstation-Spielkonsole SPI über eine solche Verkabelung mit einer Taktrate von etwa 100 kHz. Ich meine mich zu erinnern, dass das N64 auch nicht differenzielle serielle Daten mit ähnlichen Raten verwendet. Bearbeiten: Tatsächlich verwendet die Playstation 500 kHz, 3,3 V-Signalisierung und kann mit Verlängerungskabeln problemlos über 3 m reichen: store.curiousinventor.com/guides/PS2
FTDI macht ein USB-Async-TTL-Kabel, 1,2 m, denke ich; Der USB-Seriell-Adapter befindet sich am USB-Steckerende, sodass versucht wird, asynchrones TTL über das 1,2-m-Kabel zu senden. Bei Datenraten über 38,4 kbps hat es eine sehr auffällige Fehlerrate. Getaktete Protokolle sind bei gleicher Bitrate immer zuverlässiger als asynchrone Protokolle, daher bin ich nicht überrascht, 100 kbps mit dem PS und/oder N64 zu sehen, aber ich denke nicht, dass es eine optimale Wahl ist.
Haben Sie Referenzen zum Thema FTDI? Beachten Sie, dass der N64 nur eine Datenleitung verwendet, nicht getaktet ist und mit etwa 333 kHz läuft. Ich denke, das FTDI-Problem könnte auf eine schlechte Verkabelung zurückzuführen sein, aber USB ist zumindest abgeschirmt.
Meine Referenz ist meine eigene Erfahrung und die eines Kollegen. Es ist keine schlechte Verkabelung, das Kabel scheint ein abgeschirmtes Kabel von einigermaßen guter Qualität zu sein (obwohl es eine Kabelkapazität sein könnte). Dies liegt daran, dass die Signalisierung nicht differentiell oder sogar hochspannungsmäßig wie RS232 ist. USB ist sowohl abgeschirmt als auch differentiell, also sehr zuverlässig.
Okay, es scheint, dass Sie damals andere Probleme hatten, denn es gibt viele Beispiele, die Ihrer Erfahrung widersprechen. Ich hatte auf einen Einblick in so etwas gehofft.

Dies wurde in vielen Anwendungen durchgeführt. Was Sie benötigen, ist ein Mux, der die Signalstifte entweder zu den USB-Stiften des Mikrocontrollers oder zu den Stiften der seriellen Schnittstelle leitet.

So landen die Signale immer dort, wo sie hingehören, und die beiden Busse können sich nicht gegenseitig stören.

In Bezug auf das serielle Protokoll ist es am besten, mit einem differenziellen Bus zu arbeiten (USB ist differenziell ...)

Es ist möglich, TTL seriell ein paar Meter zu bekommen, aber es hängt stark von der Geschwindigkeit und der Verkabelung ab!

Wie ich bereits sagte, hat dieses spezielle Mikro zufällig einen UART- und SPI-Bus an denselben Pins wie der USB, so dass es nur darum geht, ein Peripheriegerät zu deaktivieren und das andere zum Umschalten zu aktivieren.
Serielle Kommunikation über 3 m Kabel, gemeinsam mit USB
AntwortenHierDatenschutz-Bestimmungen1y, 0v