UART-Expander (5 Ports auf 11 Ports)

Ich habe ein Board, das ich entwerfen möchte, und es gibt 11 Geräte, mit denen nur über UART gesprochen werden kann . Ich bin auf eine Microchip uC-Chip-Produktpalette beschränkt und habe eine mit 5 UART-Ports gefunden. Ich habe mir eine Jumper-basierte Lösung ausgedacht, bei der der Benutzer, indem er die Verbindung über Jumper zu den 5 verfügbaren Ports herstellt, 5 der 11 Geräte auswählen kann. Ich habe nach einem Chip gesucht, der entweder UART, SPI oder I2C aufnimmt und mir ein paar zusätzliche UART-Ports gibt, aber ich bin zu kurz gekommen. Kann jemand eine Lösung oder ein Produkt vorschlagen, auf das er gestoßen ist?

Es ist nicht entscheidend, dass alle 11 Geräte eine Verbindung zum uC herstellen können (das wäre schön), aber es ist wichtig, dass diese Geräte für ein modulares Produkt auf der Platine sind. Ich möchte das Produkt jedoch benutzerfreundlicher gestalten, da die Jumper-basierte Lösung auf den ersten Blick etwas kompliziert ist, wie mir gesagt wurde.

BEARBEITEN

Okay, sorry, ich erkläre das Problem nicht richtig. Mit dieser Methode schränken Sie die Möglichkeiten des Benutzers ein. Angenommen, Sie verbinden Port a mit Gerät 1 und 2 und Port b mit Gerät 3 und 4 und so weiter ...

Aber was ist, wenn der Benutzer Gerät eins und zwei verwenden möchte? Dann schränkt das Produkt den Nutzer stark ein. Mit 5 Anschlussoptionen und 11 Auswahlmöglichkeiten für Geräte ergibt der Binomialkoeffizient 462 Kombinationen, aus denen der Benutzer wählen kann. Das ist übertrieben, ich suche nicht nach diesem Level. Aber mit der jumperbasierten Lösung kann Port a mit 9 der Geräte verbunden werden, während Port b mit 7 der Geräte verbunden werden kann, Port c mit 8 verbunden werden kann, Port d mit 7 verbunden werden kann und Port e mit 9 verbunden werden kann Mux-Schalter, die dazu benötigt werden, wären über dem Limit.

Gibt es eine andere Lösung, um dem Benutzer die Möglichkeit zu geben, (fast) jede Kombination der Geräte zu verwenden?

Ich habe darüber nachgedacht, zwei uC mit jeweils 5 UART-Ports zu verwenden, um 10 der Geräte anzuschließen, und dann eine viel kleinere Jumper-basierte Lösung für das letzte Gerät zu verwenden, aber diese Lösung ist für die Produktion zu kompliziert und teuer.

Gibt es Chips oder Konzepte, die die UART-Steuerung auf 11 Geräte erweitern?

Früher haben wir den alten (StarTech) ST16C554 oder ST68C554 verwendet, glaube ich. Zurück in den Tag. NXP stellt sie möglicherweise jetzt her. Sie unterstützten mehrere Schnittstellen zum Mikro und stellten vier zusätzliche RS-232-Ports bereit. Sie stellten auch 552 Geräte für zwei Ports her. Sie können mischen und anpassen, um dorthin zu gelangen, wo Sie möchten. (Sie enthielten jeweils auch FIFOs.) Persönlich? Ich würde mehr PIC-Teile hinzufügen.
Könnten Sie RS422/RS485-Transceiver verwenden, solange alle entfernten UART-Geräte nur als Antwort auf Befehle vom Host senden? Dann könnten Sie alle Empfangsdaten zu einem einzelnen UART-Port auf dem Host leiten und die RS422/RS485-Übertragung nur für jeweils eine Fernbedienung aktivieren.
Warum müssen Sie gleichzeitig eine beliebige Kombination von UARTs verwenden? Welches Problem lösen Sie damit genau?
@Chupacabras Es muss keine Kombination von UARTs gleichzeitig verwendet werden, aber das System muss modular genug sein, um dem Benutzer eines der 11 Geräte auf der Platine zu geben, und an diesem Punkt können sie 5 davon verwenden.
@GarethT. Sie müssen also nur mit 1 UART-Gerät gleichzeitig kommunizieren? Sie müssen nicht mit mehreren Geräten gleichzeitig kommunizieren?

Antworten (5)

Verwenden Sie einige UART-SPI-Brücken-ICs, wie:

Sie können so viele UARTs haben, wie Sie freie GPIO-Pins haben, die Sie als Chip-Select-Leitungen verwenden können (oder verwenden Sie einen Demux oder Decoder, und Sie können Größenordnungen mehr haben) - begrenzt nur durch Ihre UART-Baudrate im Vergleich zur maximalen Geschwindigkeit, die Sie ausführen können Ihr SPI.

Das sieht vielversprechend aus, ich werde mir jeden von ihnen ansehen. Danke schön.
Der SC16IS7xx ist auf dem richtigen Weg mit SPI oder I2C zu zwei UART's ist großartig, da ich drei davon bräuchte, um alles zu tun, aber leider sind die Kosten für nur einen von ihnen zu hoch. Wenn es einen Chip gibt, der SPI oder I2C aufnehmen und 4 oder 6 UART geben kann, wäre ich wirklich aufgeregt.
@GarethT. Heutzutage denke ich, dass dies ein weiterer Ihrer 5-UART-PICs wäre. Einfach programmieren, das ist alles.
@jonk Ich habe diese Option wirklich in Betracht gezogen, aber es ist ein bisschen übertrieben für die Aufgabe, und wenn Platinen zur Reparatur kommen und es keine einfache Lösung ist, geben sie immer dem uC oder dem Speicherchip die Schuld. Wenn es zwei von ihnen auf den nächsten Brettern gibt, kann ich die Welt in ihren Augen untergehen sehen.
@GarethT. Sicher. Wie gesagt, wir haben früher die ST16C554- oder ST68C554-Geräte (unterschiedliche Schnittstellen) verwendet. Sie funktionierten gut, um eine große Anzahl von seriellen asynchronen E/A-Ports zu erstellen. Aber ich vermute, dass sie heutzutage ziemlich Boutique sind, weil es billiger/einfacher und leistungsfähiger und bequemer ist, MCUs jetzt zu verwenden. Aber ich bin heute auch nicht im Geschäft. Ich kann Ihnen also nicht sagen, was andere tun, wenn sie Dutzende solcher Ports benötigen. Aber ich sehe auch noch keine wirklich guten Antworten für Multi-Asynch-Geräte. Also vielleicht ist das jetzt der Lauf der Dinge. Was denkst du, wenn du siehst, was du bisher gesehen hast? (+1 übrigens.)
@jonk Ich habe den SC16IS752 aufgeschlagen; SC16IS762 an meinen Chef und er interessierte sich für den Chip, aber für andere Projekte mit weniger UART-Portanforderungen. Vielen Dank für Ihre Hilfe dabei. Ja, es sieht so aus, als wäre die Verwendung von zwei programmierbaren PIC32 erforderlich, um die gewünschten Ergebnisse zu erzielen. Nachdem ich mir den SC16IS752 angesehen habe, sehe ich, dass er RS485 hat. Würden Sie sagen, dass dieser Chip die vollen Anforderungen des RS485-Protokolls (Entfernung) erfüllen kann? Damit meine ich, könnte es die Funktionalität des SN75175A ersetzen? Ich sehe die Treiber für SR485 nicht im Datenblatt des SC16IS752.
AFAIK, die "RS485" -Unterstützung in diesem Gerät dient nur dazu, die RX / TX-Richtungssteuerung auf einer Halbduplexleitung zu verwalten. Es sind keine Leitungstreiber/Empfänger enthalten und Sie benötigen immer noch einen 75175/MAX485/was auch immer.

Sie können analoge Schalt-ICs (analoge Multiplexer) verwenden, um manuelle Jumper zu ersetzen.

Wenn Sie 5 UART-Ports haben, können Sie 1 dieser Ports auf 8 gemultiplexte UART-Ports multiplexen. Sie müssen 8-Kanal-Switches wie DG4051E verwenden .

Ja, ich habe mich bereits damit befasst, aber es erfordert eine lächerliche Menge an Mux-ICs, um das zu ersetzen, was ich mit der Jumper-basierten Lösung getan habe, da es auch die RTS-Leitung sowie die TX- und RX-Leitung gibt.
Sie müssen also 3 Signalleitungen schalten und haben 5 UARTs. Sie brauchen keine lächerliche Menge an Muxes. Alles, was Sie brauchen, sind 3 Chips und einer dieser UART-Ports gemultiplext (Sie haben also 4 UART-Ports + 8 gemultiplext). Also 3 Stk. von 8-Kanal-Multiplexern, wie DG4051E (zufällig ausgewählt).
Bitte sehen Sie sich die bearbeitete Frage an.
@GarethT. Sie haben die Anforderungen in Ihrer Frage dramatisch geändert. Sie haben nicht erwähnt, dass Sie gleichzeitig eine beliebige Kombination von UARTs verwenden möchten.
Ja, deswegen habe ich mich entschuldigt. Verzeihung.

Ansteuern eines SIPO-Schieberegisters (z. B. 74hc595) von 2 GPIO-Pins Verbinden Sie den ~OE-Eingang mit dem UART-Ausgang

Verwenden Sie die GPIO-Uhr in einem Muster, das das Gerät darstellt, mit dem Sie sprechen möchten, und verwenden Sie dann den UART zum Senden

Wenn ein Pull-up vorhanden ist, gibt der Port mit einem Nullbit die UART-Ausgabe wieder.

Verwenden Sie für das Empfangsende ein und Tor / Tore, um das Signal vom Gerät UARTS zu kombinieren.

Ich denke, Sie verwenden das falsche Protokoll und/oder die falsche Topologie für Ihren Fall. Ich würde vorschlagen, RS-485-Transceiver zu verwenden und eine Bustopologie aufzubauen. Wenn Sie 11 mögliche Geräte haben, können Sie 4 Zeilen verwenden, um eines davon zu aktivieren.

Die Vorbehalte, die ich für diese Option sehe, sind:

  • Halbduplex-Kommunikation (kein gleichzeitiges Rx/Tx)
  • Sie können jeweils nur mit einem Gerät interagieren (Bus-Topologie)
  • Ihr uC wird wie ein Meister sein. Es muss ein Gerät aktivieren und die Kommunikation mit ihm starten. (Transceiver sind zum Schreiben auf oder Lesen vom Bus konfiguriert)

Ich habe in Ihren Fragen keine Details darüber gesehen, wie sich diese Einschränkungen auf Ihr System auswirken können oder ob es sich überhaupt lohnt. Ich hoffe, das konnte helfen.

In einem Design von Grund auf neu, sicher, obwohl auf derselben Platine normalerweise kein Bedarf für RS485 besteht, kann alles einseitig auf Logikebene unter Verwendung der Ausgangsfreigaben der UARTs erfolgen. Aber es hört sich ziemlich stark danach an, dass die Dinge, mit denen der Fragesteller sprechen möchte, bereits feste Designs sind, daher ist es wahrscheinlich keine Option, ihre Firmware so zu ändern, dass sie einen adressierbaren gemeinsam genutzten Bus implementiert.
Ich spreche nicht von Adressen, aktivieren Sie einfach die Leitungen zu jedem Transceiver. Dies impliziert weniger Firmware-Änderungen als das Ausprobieren eines I2C-Busses – Sie benötigen nur 1 uart in Ihrem Host-uC.
Wenn die Haupt-MCU die Transceiver steuert, ist dies nur eine umständliche Art, einen Mux zu bauen. Überspringen Sie das Differential, überspringen Sie die Halbduplex-Bedenken und befolgen Sie einfach die vorhandenen Vorschläge, um einen Mux zu erstellen. Der eigentliche Sinn von RS485 besteht darin, dass die Geräte selbst auf ihre Adresse lauschen und auf die folgenden Daten achten oder ihren Transceiver danach aktivieren, um zu antworten, und dass die Signalisierung differentiell ist. Beides passt nicht wirklich zu Ihrem überarbeiteten Vorschlag für diese Anwendung.
RS485 definiert nur eine elektrische Schnittstelle, keine Adressierung. Aus diesem Grund schlage ich vor, Transceiver vom uC zu aktivieren, da die Adressierung tatsächlich zusätzliche Firmware impliziert. Die einzige Änderung, die Sie benötigen, ist: Anstatt UART X für Gerät Y zu verwenden, aktivieren Sie Transceiver Y und verwenden Sie UART1. Ich sehe diese Option als machbar an, da das OP sagte: "Ich habe ein Board, das ich entwerfen möchte ..."
Sicher, aber Sie bestehen darauf, die offensichtliche Tatsache zu ignorieren, dass dies sinnlos komplex und restriktiver ist als die Verwendung der von anderen bereits vorgeschlagenen Multiplexer. Ihr System bietet demgegenüber keine Vorteile, aber viele Nachteile dagegen. RS485 ist nur nützlich , wenn es für Dinge verwendet wird, die hier nicht zutreffen würden.
Wie Sie in meinem Beitrag lesen können, liste ich 3 Nachteile dieser Verwendung auf, und nur eine Antwort schlägt vor, analogen Mux zu verwenden, und OP antwortet bereits darauf. Die Vorteile hängen davon ab, was für Sie wertvoll ist: verwendete UARTs, verwendete Pins, PCB-Fläche, Skalierbarkeit, Modularität, Kosten, Hardware- oder Firmware-Aufwand usw.
Genau keiner dieser Faktoren gibt Ihrer überkomplexen Idee den Vorteil. Was Sie beschreiben, ist logischerweise ein Mux; Aber die Art und Weise, wie Sie einen effizient bauen, besteht aus Mux- oder Switch-Chips, nicht aus differenziellen Treibern und Empfängern.
Sicher, es ist logischerweise ein Mux, und das ist die kurze Antwort auf die OP-Frage, er braucht einen Mux. Und für einen Mux sind die Einschränkungen die gleichen, die ich beschrieben habe. Ich denke, mehr Vor- und Nachteile könnten mit Details angegeben werden, als ob die UART-Geräte in der Lage sind, eine Kommunikation zu starten, wenn weitere Geräte hinzugefügt werden, wenn geplant ist, die Topologie zu ändern usw., da diese Details nicht vom OP angegeben werden. Mein wichtigster Rat ist jedoch, die Topologie zu überdenken, wenn er/sie eine gewisse Kontrolle darüber hat, wie die Schnittstelle zu den Geräten hergestellt wird, und sie sich in der Entwurfsphase befindet.

Als Alternative könnte PSoC Ihnen helfen

Hier ist ein Beispiel mit 11 UART auf einem PSoC 5lp

https://hackaday.io/project/11974-averaging-many-gpses/log/39157-11-serial-ports-with-psoc5

Nur ein Vorschlag, überprüfen Sie, ob Ihr System die zusätzlichen seriellen Ports und die zu verarbeitenden Daten verarbeiten kann. Ich weiß nicht, wie schnell oder wie viele Daten diese durchlaufen, und es kann sein, dass es Ihnen gut geht.
UART-Expander (5 Ports auf 11 Ports)
AntwortenHierDatenschutz-Bestimmungen1y, 0v