Hallo, ich habe eine allgemeine Frage zur Funktion der XPORT-Reihe von Lantronix: ...leider finde ich dazu keine gute Softwaredoku, auch der ct-Artikel liefert mir keine nützlichen Infos. Nach meinem Verständnis kann ich über die IP des XPORTs einfach eine TCP-Verbindung aufbauen, in meinem Fall über LabView - VIs, im nächsten Schritt dann eben Daten senden oder lesen... Wie schaut das nun aus, kommen die Daten - Byte für Byte - welche ich über die aufgebaute Verbindung sende genau so wieder, per RS232, aus dem XPORT heraus - oder steckt da noch eine Protokollebene zwischen? Sollte letzteres der Fall sein, wo finde ich die Doku dazu? Der erste Fall wäre mir deutlich lieber - aber ist dem wirklich so, meine Vermutung zur Funktion also korrekt? Grüße Sascha
P.S.: Es sei noch zu erwähnen, dass ich nicht darauf aus bin einen Virtual COM-Port Treiber zu verwenden! Das ganze soll schon über TCP laufen.
>Wie schaut das nun aus, kommen die Daten - Byte für Byte - welche ich >über die aufgebaute Verbindung sende genau so wieder, per RS232, aus dem >XPORT heraus Ja. >P.S.: Es sei noch zu erwähnen, dass ich nicht darauf aus bin einen >Virtual COM-Port Treiber zu verwenden! Das ganze soll schon über TCP >laufen. Ich glaube das geht gar nicht (bin mir nicht sicher). Xport ist vor allem dann eine Fehlentscheidung, wenn man dem Kunden zutrauen muss, die ganzen Einstellungen über das Webinterface von dem Chip vornehmen zu müssen. Für den Eigenbedarf, kann man die natürlich nehmen, aber so... Muss auf der µC Seite unbedingt RS232 sein? Sonst könnte man einen LAN-Chip mit I2C oder SPI Interface nehmen.
Hallo Arno N. :-) die Daten, die Du zum Xport per TCP/IP schickst, kommen mit der am XPort eingestellten Baud-Rate wieder raus. Da gibts eigentlich kein großes Geheimnis bei. Aber...... Es kann zu Timing-Verschiebungen kommen. Der XPort versucht z.B. die IP-Pakete voll zu bekommen. Sollte nun aber nix mehr kommen, wartet er ein Weilchen und schickt dann dieses "halbe" Paket los. Reine Text- bzw. Daten-Anwendungen haben damit kein Problem. Eine Anwendung, die die Pin's der ser. Schnittstelle "mißbrauchen" wird aber höchst wahrscheinlich Probleme machen.
Ich habe ein ähnliches Problem. Die Daten die ich von der seriellen Schnittstelle über den XPort sende kommen beim Endrechner an. Wenn ich aber Daten an den XPort sende werden diese offenbar nicht richtig weiter geleitet. Ich nutze einen Controller, der diese Daten empfangen soll. Er schleust sie derzeit nur über eine 2.serielle Schnittstelle raus an einen weiteren PC, wo ich "mitlese". Wie gesagt, andersherum gehts. Ich sende eigentlich nur Daten im ASCII Format. MfG J_uri
Hi J_Uri, das habe ich jetzt nicht richtig verstanden. In welche Richtung tritt das Problem auf? Kommt da garnix an, oder verstümmelter Datenmüll? Es gibt beim XPort Einstellungen, die nur über Telnet erreichbar sind. Schreib mal genaueres, vielleicht kann ich's hier nachstellen.
Ok, also der derzeitige Aufbau sieht folgendermaßen aus: PC 1 <-Ethernet-> XPort <-Seriell-TTL-> minimodulC167 <-Seriell-RS232-> PC 2 Es gibt also zwei PCs die nach obigem Aufbau miteinander verbunden sind. Auf PC1 ist die COM-Port-Redirectorsoftware installiert die den XPort auf COM8 legt damit ich über das HyperTerminal mit ihm kommunizieren kann. Auf PC 2 ist ebenfalls das Hyperterminal gestartet. Das minimodul C167 dazwischen schleust die Daten einfach nur durch und dient nebenbei auch noch als Wandler von TTL-Pegel in RS232-Pegel. Da soll später mal ne andere Anwendung ran, deshalb ist es dazwischen. Es nutzt einen C167 als µC. Folgendes Problem liegt nun vor: Wenn ich Daten im PC 2 eingebe, dass funktioniert das wunderbar. Sie werden am PC 1 im Hyperterminal angezeigt. Alles Ok. Wenn ich Daten im PC 1 eingebe, dann passiert nix. Der XPort blinkt, scheint also Daten zu bekommen. Wenn ich mit dem Oszilloskop an den Pins des XPorts messe passiert auch was. Die Daten scheinen also auch rauszugehen, in das minimodul. Es gibt also die Möglichkeit, dass der C167 damit nicht klar kommt... Komischerweise scheint es eine Art Echofunktion im XPort zu geben, denn der Buchstabe den ich eingebe, der wird mir im Hyperterminal auch angezeigt. Ein Blick auf WireShark zeigt, dass die Daten, die an den Xport gesendet werden postwendend auch wieder zurückkommen. Komisch. Vielen Dank schonmal für die Hilfe. Ist etwas verzwackt. MfG J_uri
Hi J_uri, klingt für mich nicht zwingend nach XPort-Prob. Hast Du test-weise den XPort schonmal übergangen? PC1 (ser) <-> µC <-> PC2 (ser) Oder noch besser den µC übergehen PC1 (IP) <-> XPort <-> PC2 (ser) Vorher würde ich nicht den XPort als Übeltäter beschimpfen. :-) Zum Echo Ja, Du hast Recht es gibt eine Echo-Einstellung. Um alle nötigen Einstellungen im XPort vorzunehmen, verwende ich Telnet. Zum einen gibt es da Einstellungen, die im Web nicht vorhanden sind und zum anderen bin ich schon mehrfach mit unterschiedlichen Browsern auf die .. gefallen, da Daten teilweise nicht übernommen wurden oder Daten aus dem Cache angezeigt wurden, die nicht mehr vorhanden waren. PS: Man kann den XPort auch "von hinten" konfigurieren. Sollte man sich mal mit den IP und Subnetmask-Einstellungen mal ausgesperrt haben oder IP unbekannt, braucht man nach einem XPort-Reset nur 3 kleine "x" (also im Hyperterminal am bessten die x-Taste so lange drücken bis eine Reaktion kommt) eingeben und man hat das Telnet-"Menü" über die Serielle.
Hallo Weichlöter, ja du hast Recht. Die Echofunktion habe ich inzwischen ausgeschaltet. Inzwischen weiß ich woran es wohl liegt. Ich habe ein bisschen mit dem Oszi mitgemessen. Der XPort schafft es nicht, den Pegel des TTL-Signals nach unten zu ziehen. Es liegt also an der Verbindung XPort <-Seriell-TTL-> C167. Eigentlich müsste der XPort 5V-Kompatibel sein (TTL-Pegel 0-5V). Aber er schafft es nicht die Daten so zu übergeben, dass der Controller es erkennt. Was mach ich denn jetzt? Ich habe eine Xport vom Typ 03R, und soweit ich weiß sind alle ab 03 kompatibel zu TTL-5V Pegeln. MfG J_uri
Hi J_uri, Mist, da hätt ich drauf kommen sollen. :-) Vor dem Prob stand ich auch schon. Die Leitungen des XPorts sind 5V-tollerant - sprich die gehen da nicht kaputt, aber eigentlich ist es 3,3V-Logic Möglichkeiten - Pegelwandlung mittels IC mit OC - wie bei c't-Variante mittels 3,3V-ZDioden - Transi - Optokoppler usw.. Ich würde die Z-Dioden-Variante vorziehen. Ist von allen Varianten die kleinste. :-)
Angehängte Dateien:
-
Schaltung_Xport.png
12 KB
Hallo nochmal, ich habe die Schaltung aktualisiert (sh. Anhang). Komischerweise sind in allen Vorgaben (also bei c't und auch bei der XPort Referenz) immer nur die Eingangspins mit ZDioden und Widerstand beschalten. Bei mir ist es aber genau das umgekehrte Problem, der Datenausgang gibt keine korrekten Pegel raus. Die Schaltung müsste aber trotzdem helfen, oder? Möchte nur sicher gehen bevor ich mich ans löten mache. MfG und vielen Dank für die Hilfe J_uri
Angehängte Dateien:
-
schema.png
2,9 KB
Zusatz: An den TxD/RxD Pins des Controllers liegt parallel ein RS232-Pegelwandler, da neben den TTL-Pins auch eine RS232-Schnittstelle eingebaut ist. Kann es sein, dass dieses aktive Bauelement meine Pegel beeinflusst? Das Bild im Anhang zeigt das Problem. MfG J_uri
>Kann es sein, dass dieses aktive Bauelement meine Pegel >beeinflusst? Mit allergrößter Wahrscheinlichkeit: Ja
Gibts eine Möglichkeit das zu umgehen/unterbinden ohne die Verbindung zu trennen (wie auch immer ich die finden soll)?
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.