UART-Kommunikationsproblem bei uClinux auf Lantronix XPort Pro

[Peter D. (peter9)]

Hallo Community,

für ein gewerbliches Projekt habe ich mir einen "XPort Pro" inkl. 
Linux-SDK herausgesucht. Nachdem ich schon Wochen in die 
Applikations-Entwicklung gesteckt habe, ist nun ein Problem aufgetreten, 
dass auch beim originalen Linux-Image, das von Lantronix bei 
Auslieferung aufgespielt wurde, auftritt.

D.h., aktuell habe ich wieder das original Image auf einen "XPort Pro" 
und habe dort das Gateway "Server Mode" (Standard) eingestellt. Wenn ich 
mittels Terminal-Programm Telegramme (nur ASCII-Text ohne Sonderzeichen) 
an die UART-Schnittstelle des "XPort Pro" schicken, kommen die 
Telegramm-Daten dann auf der TCP-Schnittstelle an. So weit so gut (das 
ist die Basis-Funktion dieses Gerätes).

Standardnmäßig steht die Baudrate dabei auf 115200. Für das oben 
erwähnte Projekt wird aber eine Baudrate von 2400 benötigt, was im 
Normalfall eher vorteilhaft ist, in diesem Fall aber nicht :-(

Aktuell ist es so, dass die Telegramme ab einer gewissen Länge nicht 
mehr komplett eingelesen werden. Der Effekt wird schlimmer je niedriger 
die Baudrate ist :o)

Hier eine Auflistung der Ergebnisse:

Telegramm-Länge -> Rx:  Baudrate:   Daten-Länge, die auf der TCP-Seite 
empfangen wird:

 150                     115200         150
                           9600         150
                           2400        ~110 ???

 300                     115200        300
                           9600        300
                           2400        ~110 ???

1000                     115200        1000
                           9600        ~500 ???
                           2400        ~110 ???

Hat jemand so einen Effekt schon mal irgendwo bei Linux gesehen?

Was könnte die Ursache sein?

Parallel zu dieser Anfrage hier habe ich auch den Support von Lantronix 
angeschrieben, befürchte aber, keine Antwort zu bekommen.

Grüße
Peter

[Sigi S. (sermon)]

Wird das ein Salamischeiben Thread?

[Norbert (der_norbert)]

Peter D. schrieb:
> Hat jemand so einen Effekt schon mal irgendwo bei Linux gesehen

Nein, weil das mit Linux nichts zu tun hat.

> Was könnte die Ursache sein?

Alles Mögliche.

> Parallel zu dieser Anfrage hier habe ich auch den Support von Lantronix
> angeschrieben, befürchte aber, keine Antwort zu bekommen.

Wenn die Beschreibung genauso aussieht, dann teile ich deine 
Befürchtung.

[Frank O. (frank_o)]

Related products: XPort Pro
Duration: 2:43
Updated: *August 4, 2016* (wieso wird das nicht fett dargestellt)

Ich finde das ist "auf Sand gebaut".

Für gewerbliche Zwecke setzt man nur auf aktuelle und gepflegte Systeme.

[Hmmm (hmmm)]

Peter D. schrieb:
> Was könnte die Ursache sein?

Da gibt's viele, aber eine halte ich bei Deiner Beschreibung für 
besonders wahrscheinlich:

Der Konverter schickt nach einem bestimmten Timeout (bei Deinen Werten 
rund 500ms) ein Paket mit dem, was bis dahin im Buffer gelandet ist, 
raus. Bei niedrigen Baudraten ist das nur ein Teil des kompletten 
Telegramms.

Deine Software am anderen Ende der TCP-Verbindung wartet per select() 
auf Daten, holt dann per read() ein einziges Mal alles, was da ist, und 
wartet nicht mehr auf den Rest.

Aber um wirklich zu wissen, was los ist, musst Du schon mehr tun. Ein 
Logic Analyzer auf der UART-Schnittstelle und Wireshark auf dem 
Netzwerkinterface sollten Dich der Erleuchtung näherbringen.

Edit: Im Handbuch ist das Stichwort "Packing Mode".

[Peter D. (peter9)]

Hmmm schrieb:
> Deine Software am anderen Ende der TCP-Verbindung wartet per select()
> auf Daten, holt dann per read() ein einziges Mal alles, was da ist, und
> wartet nicht mehr auf den Rest.

ja, ein guten Hinweis, aber ich hatte nicht erwähnt, dass ich bei meiner 
selbst-geschriebenen C-Applikation den exakt gleichen Effekt sehe und 
dort verwende ich gar kein TCP.

Ich wollte nur ausschließen, dass ich einen Programmierfehler in meiner 
Applikation habe und habe daher das originale Lantronix-Image 
aufgespielt, und damit kann ich den Effekt (Fehler) nur über den 
TCP-Gateway nachweisen.

D.h., in meiner Applikation habe ich ein "read" auf TTYS0 laufen und der 
liefert schon weniger Datenbytes als erwartet zurück. TCP verwende ich 
gar nicht.

[Hmmm (hmmm)]

Peter D. schrieb:
> D.h., in meiner Applikation habe ich ein "read" auf TTYS0 laufen und der
> liefert schon weniger Datenbytes als erwartet zurück.

Du berücksichtigst aber auch dort, dass die Daten durchaus in mehreren 
Häppchen ankommen können?

[Peter D. (peter9)]

Hmmm schrieb:
> Du berücksichtigst aber auch dort, dass die Daten durchaus in mehreren
> Häppchen ankommen können?

ja, sicher, der "read" läuft in einer Endlosschleife (mit VMIN=0) und 
liefert vor allem bei 115200 Baud die empfangenen Daten in mehreren 
Häppchen, aber immer in der Summe mit der erwarteten Anzahl.

Wie groß die Häppchen dann sind, hängt vom Aufruf-Intervall von "read" 
ab.

[Hmmm (hmmm)]

Peter D. schrieb:
> ja, sicher, der "read" läuft in einer Endlosschleife (mit VMIN=0)

Und Du reichst permanent alles durch, was reinkommt? Oder gibt es ein 
Kriterium, nach dem Dein Code davon ausgeht, dass nichts mehr kommen 
wird?

[Peter D. (peter9)]

Hmmm schrieb:
> Und Du reichst permanent alles durch, was reinkommt? Oder gibt es ein
> Kriterium, nach dem Dein Code davon ausgeht, dass nichts mehr kommen
> wird?

ich glaube, in diese Richtung weiter zu suchen macht wenig Sinn, da der 
Fehler ja bereits im Lantronix-Original-Image auftritt. Gut, es könnte 
natürlich sein, dass ich exakt den gleichen Fehler im Quellcode habe wie 
bei der Lantronix-Software, aber die Wahrscheinlichkeit ist gering, da 
ich schon alle möglichen Quellcode-Beispiele aus dem Inet ausprobiert 
habe.

Ich denke eher, es ist ein Fehler im uClinux-Kernel (Treiber?) und ich 
hatte gehofft, dass sich ein Linux-Kernel-Kenner an irgendetwas 
erinnert, dass in diese Richtung geht.

Hier noch mal ein paar technische Daten (Auszüge der Boot-Meldungen):

Prozessor: ColdFire MCF5208 on the XPort Pro
uClinux:   Linux version 2.6.30.4-uc0-AR-890 (root@ubuntu) (gcc version 
4.4.1 (Sourcery G++ Lite 4.4-53) )
Treiber:   ColdFire internal UART serial driver
           ttyS0 at MMIO 0xfc060000 (irq = 90) is a ColdFire UART

Ich könnte auch noch mal ein beliebiges (fremdes) Terminal-Programm 
ausprobieren, wenn mir jemand einen Download-Link bereitstellt?

[Harald K. (kirnbichler)]

Peter D. schrieb:
> ich glaube, in diese Richtung weiter zu suchen macht wenig Sinn, da der
> Fehler ja bereits im Lantronix-Original-Image auftritt.

Vielleicht liegt der Fehler ja auch ganz woanders, nämlich in dem Teil, 
der auf Deinem PC läuft und mit dem Lantronix-Gerät kommunizieren soll.

Was ist der spezielle Hintergrund, warum Du überhaupt mit dessen 
(Linux-) Firmware herummachst? Kann die 08/15-Standard-Ausführung 
irgendwas nicht, was Du brauchst? Oder tritt bei der der von Dir 
ausgemachte Fehler ebenso auf?

Peter D. schrieb:
> Ich könnte auch noch mal ein beliebiges (fremdes) Terminal-Programm
> ausprobieren, wenn mir jemand einen Download-Link bereitstellt?

Solltest Du Windows verwenden, kannst Du z.B. Teraterm nutzen.

[Peter D. (peter9)]

oh, ich habe mich wohl missverständlich ausgedrückt, das 
Terminal-Programm ist nicht für den PC sondern für den XPort (also ein 
Programm, das auf uClinux läuft)!

Ich würde dieses Terminal-Programm auf dem XPort starten und dann vom PC 
aus ein Datentelegramm mit unterschiedlicher Länge schicken. Im 
Optimalfall sollten alle gesendeten Zeichen im Terminal-Programm des 
XPorts angezeigt werden.

Ich "mache mit der Linux-Firmware" herum, weil dass so von Lantronix 
freigegeben ist. Es gibt ein offizielles SDK (als VM unter VMWare), 
womit man eigene C-Applikationen schreiben, kompilieren und laufen 
lassen kann.

Genau dafür haben wir das Teil herausgesucht!

[Harald K. (kirnbichler)]

Peter D. schrieb:
> Genau dafür haben wir das Teil herausgesucht!

Sicher, aber welches Problem soll das lösen?

[Peter D. (peter9)]

Harald K. schrieb:
> Sicher, aber welches Problem soll das lösen?

"Problem" ist nicht die optimale Beschreibung, ich würde 
"Aufgabenstellung" dazu sagen. Meine Applikation soll Datentelegramme 
von der UART annehmen und intern weiterverarbeiten.

Wir haben uns aus diversen Gründen für den XPort entschieden, da wir 
davon ausgegangen sind, dass der sich wie alle anderen µC verhält...

[Harald K. (kirnbichler)]

Peter D. schrieb:
> Meine Applikation soll Datentelegramme
> von der UART annehmen und intern weiterverarbeiten.

Gut, aber am anderen Ende des Netzwerks ist ja auch noch irgendwas. Und 
mit diesem Irgendwas stellst Du ja wohl den auftretenden Fehler fest, 
denn den soll es ja auch mit der Original-Firmware geben, d.h. ohne 
Deine auf dem Xport selbst laufenden Anwendung.

Das jedenfalls habe ich Deiner Beschreibung entnommen. Und das ist es 
eben, was mir seltsam vorkommt; Xports gibt es schon lange, und so etwas 
triviales wie eine serielle Kommunikation haben damit zigtausend Leute 
schon erfolgreich betrieben (auch in meiner Firma wurde sowas vor 
vielleich 20 Jahren mal für irgendein Projekt eingesetzt, in diesem Fall 
wurde mit 9600 Baud kommuniziert, und Probleme gab es keine).

Insofern kommt es mir so vor, als ob das geschilderte Problem 
möglicherweise ganz woanders zu suchen ist.

[Hmmm (hmmm)]

Peter D. schrieb:
> ich glaube, in diese Richtung weiter zu suchen macht wenig Sinn, da der
> Fehler ja bereits im Lantronix-Original-Image auftritt.

In der Lantronix-Firmware gibt es dieses Verhalten (bzw. etwas, was bei 
kaputter Gegenstelle dazu führen kann) wie gesagt als Feature.

Zur dabei verwendeten TCP-Gegenstelle hast Du nichts gesagt (PuTTY im 
Raw-Modus wäre zum Testen eine Möglichkeit), und auch die Frage, wie Du 
in Deinem eigenen Code das Thema Timeouts gelöst hast, ist noch offen.

Das Verhalten deutet wie gesagt darauf hin, dass ca. 500ms nach Beginn 
des Telegramms keine weiteren Daten mehr angenommen werden.

Dass Du in bestimmten Abständen read() aufrufst, statt mit select() und 
non-blocking I/O zu arbeiten, deutet schonmal auf Murks hin.

Peter D. schrieb:
> Ich könnte auch noch mal ein beliebiges (fremdes) Terminal-Programm
> ausprobieren, wenn mir jemand einen Download-Link bereitstellt?

Ist kein cu(1) dabei?

[Peter D. (peter9)]

Hmmm schrieb:
> Dass Du in bestimmten Abständen read() aufrufst, statt mit select() und
> non-blocking I/O zu arbeiten, deutet schonmal auf Murks hin.

um zu beweisen, dass es nicht an meinem Murks (sehr freundlich von dir) 
liegt, habe ich mir ein Test-Quell-Code von dieser Homepage:

https://linuxvox.com/blog/using-select-for-nonblocking-serial/

heruntergeladen und für den XPort übersetzt und getestet. Der Quell-Code 
sieht so aus:

#define BUFFER_SIZE 1024
#define SERIAL_PORT "/dev/ttyS0" // Replace with your port
#define BAUD_RATE B2400
 
int main() {
    int serial_fd;
    struct termios tty;
    fd_set read_fds;
    struct timeval timeout;
    int ret;
 
    // Step 1: Open serial port
    serial_fd = open(SERIAL_PORT, O_RDWR | O_NOCTTY | O_NONBLOCK);
    if (serial_fd == -1) {
        perror("Failed to open serial port");
        return EXIT_FAILURE;
    }
    printf("Serial port opened (fd: %d)\n", serial_fd);
 
    // Step 2: Configure serial port
    if (tcgetattr(serial_fd, &tty) != 0) {
        perror("tcgetattr failed");
        close(serial_fd);
        return EXIT_FAILURE;
    }
 
    // Set baud rate
    cfsetospeed(&tty, BAUD_RATE);
    cfsetispeed(&tty, BAUD_RATE);
 
    // 8N1 (8 data bits, no parity, 1 stop bit)
    tty.c_cflag &= ~PARENB;
    tty.c_cflag &= ~CSTOPB;
    tty.c_cflag &= ~CSIZE;
    tty.c_cflag |= CS8;
    tty.c_cflag |= CLOCAL | CREAD;
 
    // Raw mode (no canonical processing)
    tty.c_lflag &= ~ICANON;
    tty.c_lflag &= ~ECHO;
    tty.c_lflag &= ~ECHOE;
    tty.c_lflag &= ~ISIG;
 
    // No software flow control
    tty.c_iflag &= ~(IXON | IXOFF | IXANY);
 
    // Read timeout
    tty.c_cc[VTIME] = 10; // 1 second
    tty.c_cc[VMIN] = 0;
 
    if (tcsetattr(serial_fd, TCSANOW, &tty) != 0) {
        perror("tcsetattr failed");
        close(serial_fd);
        return EXIT_FAILURE;
    }
   {
    // Step 3: Ensure nonblocking mode
    int flags = fcntl(serial_fd, F_GETFL, 0);
    if (flags == -1 || fcntl(serial_fd, F_SETFL, flags | O_NONBLOCK) == -1) {
        perror("fcntl failed");
        close(serial_fd);
        return EXIT_FAILURE;
    }
   }
    // Step 4: Monitor and read data (main loop)
    printf("Monitoring serial port (press Ctrl+C to exit)...\n");
    while (1) {
        FD_ZERO(&read_fds);
        FD_SET(serial_fd, &read_fds);
 
        timeout.tv_sec = 1;
        timeout.tv_usec = 0;
 
        ret = select(serial_fd + 1, &read_fds, NULL, NULL, &timeout);
        if (ret == -1) {
            perror("select failed");
            break;
        } else if (ret == 0) {
            // Timeout: no data
            continue;
        }
 
        if (FD_ISSET(serial_fd, &read_fds)) {
            char buffer[BUFFER_SIZE];
            ssize_t num_bytes = read(serial_fd, (unsigned char*)buffer, BUFFER_SIZE - 1);
            if (num_bytes == -1) {
                if (errno != EAGAIN && errno != EWOULDBLOCK) {
                    perror("read failed");
                    break;
                }
            } else if (num_bytes > 0) {
          if (num_bytes == 1 && buffer[0] == 27) {
            break;
          }
          else {
            buffer[num_bytes] = '\0';
            printf("Received (%d): %s\n", num_bytes, buffer);
          }
            }
        }
    }
 
    // Step 5: Cleanup
    close(serial_fd);
    printf("Serial port closed\n");
}

Der Effekt ist exakt der gleiche wie bei meiner Applikation und beim 
origin al Lantronix-Image!!!!

> Ist kein cu(1) dabei?

leider nein. Daher hatte ich ja weiter oben nach einem 
Beispiel-Linux-Programm gefragt, das direkt auf dem XPort lauffähig ist.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Peter D. schrieb:
> um zu beweisen, dass es nicht an meinem Murks (sehr freundlich von dir)
> liegt, habe ich mir ein Test-Quell-Code von dieser Homepage:

Das ist doch wieder typisch: es werden angebliche Beweise gesucht und 
auch vorgelegt, um bloß nicht auf die Idee kommen zu müssen, dass es an 
dem eigenen Pfusch liegen könnte. Jeder halbwegs brauchbare Entwickler 
wird bei solchen Problemen einfach mit einem Netzwerkmonitor wie z.B. 
Wireshark/Tcpdump ein Protokoll mitschneiden und dann ganz genau 
anschauen, welche Pakete von welcher Seite geschickt wurden und welche 
von der Gegenseite quittiert wurden. Und auch an der zeitlichen 
Entwicklung der TCP Window Size könnte man sehr schnell erkennen, ob 
eine Blockierung auf Empfängerseite vorliegt.

Aber Du wirst ja schon Deine Gründe haben, solche Mitschnitte hier nicht 
zu veröffentlichen, sondern lieber unter den Tisch zu kehren.

[Peter D. (peter9)]

Hallo Andreas,

danke für deinen kontruktiven Beitrag, aber es geht doch überhaupt 
garnicht um TCP oder Netzwerk. Nur für einen Test mit dem orignal 
Lantronix-Image habe ich den TCP-Gateway verwendet.

In allen anderen Beiträgen (insbesondere meinem letzten) geht es nur um 
eine reine UART-Kommunikation.

Drücke ich mich so missverständlich aus? Dann entschuldige ich mich 
mehrmals dafür.

Grüße
Peter

[Hmmm (hmmm)]

Peter D. schrieb:
> um zu beweisen, dass es nicht an meinem Murks (sehr freundlich von dir)
> liegt

Geht es Dir darum, das Problem zu lösen, oder nur darum, die Schuld bei 
einem Produkt zu suchen, das in so grossen Stückzahlen verkauft wird, 
dass derart gravierende Bugs ziemlich schnell auffallen würden?

Peter D. schrieb:
> Der Effekt ist exakt der gleiche wie bei meiner Applikation und beim
> origin al Lantronix-Image!!!!

Zeig mal den Output davon, wenn mit ein paar Sekunden Abstand zwei (!) 
Datenpakete reingekommen sind.

Peter D. schrieb:
> leider nein. Daher hatte ich ja weiter oben nach einem
> Beispiel-Linux-Programm gefragt, das direkt auf dem XPort lauffähig ist.

cu wäre so ein "Beispielprogramm".

Peter D. schrieb:
> In allen anderen Beiträgen (insbesondere meinem letzten) geht es nur um
> eine reine UART-Kommunikation.

Hast Du die denn inzwischen mal mit einem Logic Analyzer begutachtet?

Ich vermisse hier eine systematische Fehlersuche, denn wenn hinten Müll 
rauskommt, prüft man doch zuerst, ob vorne evtl. schon Müll reingeht.

[Sigi S. (sermon)]

1. Antwort, Salamitaktik….

[Peter D. (peter9)]

Hallo an alle Beteiligten,

ich muss zu meiner Schande Abbitte leisten und entschuldige mich nochmal 
für eventuelle missverständliche Antworten.

Ich bin leider (danke an Hmmm) davon ausgegangen, dass der PC, mit dem 
ich die Test-Telegramme an den XPort schicke, diese auch genauso 
geschickt hat.

Hat er aber nicht :-( Hier lag der Fehler auf meiner Seite!

Hinzu kam aber ein zweiter Fehler auf dem XPort. Nur das 
Beispiel-Programm (mit "select"), das ich oben gepostet habe, zeigt nun 
die korrekte Anzahl empfangener Bytes an. Meine Applikation macht es 
nicht, aber hier kann ich ja jetzt den Quellcode des Beispiel-Programms 
übernehmen ;-)

Danke nochmals für eure Hilfe-Versuche, die ich leider nicht alle 
berücksichtigt habe, da ich von falschen Umständen ausgegangen war.

Ich hoffe, ich darf trotzdem nochmal hier etwas posten? ;-)

Grüße
Peter

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Peter D. schrieb:
> danke für deinen kontruktiven Beitrag, aber es geht doch überhaupt
> garnicht um TCP oder Netzwerk. Nur für einen Test mit dem orignal
> Lantronix-Image habe ich den TCP-Gateway verwendet.

Und bei diesem Test mit dem Lantronix-Image treten doch offenbar schon 
Probleme auf. Warum verheimlichst Du dann die Netzwerkmitschnitte der 
Kommunikation zwischen PC und Lantronix-Modul? Ach, da könnte man 
erkennen, dass die Blockierung auf der Empfängerseite erfolgt?

Bei Ethernet-basierter Kommunkation kommt es übrigens auch vor, dass ab 
bestimmten Paketlängen Probleme auftreten, wenn die Taktfrequenzen 
zwischen Gerät und Hub/Switch zu stark voneinander abweichen. Mir ist 
mindestens eine Gerätekombination bekannt, bei beide Teilnehmer knapp 
außerhalb der zulässigen +/100 ppm lagen und es deswegen zu 
längenabhängigen Paketverlusten kam. Das ließ sich damals sehr einfach 
durch Modifikation der Quarzbeschaltungen beheben.

[Frank O. (frank_o)]

Peter D. schrieb:
> Hinzu kam aber ein zweiter Fehler auf dem XPort.

Ich wundere mich, dass es nicht nur am XPort lag. Anfangs schrieb ich ja 
schon, dass man gepflegte Systeme im professionellen Bereich benutzt und 
nicht Sachen, wo das letzte Update 2016 war. Fast 10 Jahre in der 
heutigen Computerzeit sind doch gefühlt ein Jahrtausend. Was sich da 
alles ändert und dann vielleicht an so einem Teil stecken bleibt.
Aber scheint ja wohl doch zu klappen. Ich muss ja auch nicht immer recht 
haben. :-)

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Frank O. schrieb:
> Ich wundere mich, dass es nicht nur am XPort lag. Anfangs schrieb ich ja
> schon, dass man gepflegte Systeme im professionellen Bereich benutzt und
> nicht Sachen, wo das letzte Update 2016 war.

Das XPort Pro ist eben ein völlig ausgereiftes Produkt und keine 
Bananensoftware, die beim Kunden reift. Das Teil wird noch aktiv 
hergestellt, aber für Neuentwicklungen nicht mehr empfohlen.

https://www.lantronix.com/products/xport-pro/

Warum sollte Lantronix also irgendwelche Features in der Firmware 
hinzufügen, wenn diese womöglich zu Inkompatibilitäten bei 
Bestandsprojekten führen könnten? Dann müssten alle möglichen Kunden 
ihre Skripte für die Fertigungstests und/oder Fertigungsanleitungen 
immer wieder anpassen. Letztendlich kauft(e) man ein XPort eben nicht, 
weil man immer den heißesten Scheiß haben will, sondern um uralte Geräte 
mit einer möglichst einfach zu integrierenden Netzwerkstrippe zu 
versehen. Nicht mehr und nicht weniger.

Wer ein Modul mit mehr Features einsetzen will, setzt eben eine 
modernere Ausführung ein.

Deine Anforderung, dass einwandfrei funktionsfähige Komponenten aus 
reinem Selbstzweck "gepflegt" und damit inkompatibel gemacht werden 
sollen, wäre vergleichbar damit, einem LM358 plötzlich einen neunten Pin 
zu spendieren und z.B. eine Spannungsreferenz oder einen 
Temperaturfühleranschluss herauszuführen. Und auch die Pinbelegung wird 
angepasst, damit künftig VCC und GND nebeneinander liegen und sich somit 
ein Abblockkondensator viel EMV-gerechter anbinden lässt. Dann passt das 
Teil zwar auf keine bestehende Leiterplatte mehr, aber man hat als 
Hersteller Produktpflege betrieben.

[Frank O. (frank_o)]

Andreas S. schrieb:
> aber für Neuentwicklungen nicht mehr empfohlen.

Deshalb schrieb ich es zum Eingangsbeitrag.

Bei dem Rest bin ich bei dir.

Aber wer so was schreibt, da kann ich persönlich nur so antworten und 
mitlesen.

Peter D. schrieb:
> Hallo Community,
>
> für ein gewerbliches Projekt habe ich mir einen "XPort Pro" inkl.
> Linux-SDK herausgesucht.

So fängt man nicht ohne zwingende Gründe an.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Frank O. schrieb:
> Fast 10 Jahre in der heutigen Computerzeit sind doch gefühlt ein
> Jahrtausend.

IPv6 ist auch schon exakt dreißig Jahre alt. Die letzten beiden 
Änderungen erfolgten 1998 und 2017. Dazwischen lagen schlappe 19 Jahre. 
Und auch seit der letzten Änderung sind schon wieder 8 Jahre vergangen.

Und es gibt in der Netzwerktechnik eben auch Protokolle und 
Implementierungen, die mittlerweile völlig ausgereift sind und nicht 
mehr angefasst werden müssen. Ethernet-Switches für den Heimgebrauch und 
die Bürovernetzung werden auch in zwanzig Jahren immer noch 10Base-T und 
100Base-TX unterstützen, weil es auch dann noch Anwendungen mit geringem 
Bandbreitenbedarf geben wird.

Ein Großteil der heutigen Ethernet-Controller und insbesondere PHYs ist 
auch schon seit 10-20 Jahren in unveränderter Form auf dem Markt.

[Frank O. (frank_o)]

Andreas S. schrieb:
> IPv6 ist auch schon exakt dreißig Jahre alt.

Ist das schon wieder so weit? :-)
Ich meinte auch nicht das Teil, sondern eher das, was drum rum ist. 
Immer mehr Gbit-Lan und da könnte ich mir eben vorstellen, dass das Teil 
vielleicht nicht mehr ganz auf der Höhe gewesen wäre und deshalb die 
Kommunikation nicht klappt.
Tut es offensichtlich doch.
Ich schrieb ja schon, dass ich nicht immer recht haben muss.

Andreas S. schrieb:
> Ein Großteil der heutigen Ethernet-Controller und insbesondere PHYs ist
> auch schon seit 10-20 Jahren in unveränderter Form auf dem Markt.
Und ich bin schon fast 30 Jahre raus.
Man kriegt noch was mit, aber ich bin halt nicht mehr direkt im Thema.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Frank O. schrieb:
> Immer mehr Gbit-Lan und da könnte ich mir eben vorstellen, dass das Teil
> vielleicht nicht mehr ganz auf der Höhe gewesen wäre und deshalb die
> Kommunikation nicht klappt.

Die allermeisten aktuellen Microcontroller haben auch nur 10/100 MBit/s 
Ethernet, z.B. STM32H5, STM32H7. Gigabit und mehr sind da eher die 
Ausnahme. Nur bei den "richtig dicken" Mikroprozessoren wie z.B. STM32MP 
gibt es Gigabit, da diese Teile auch für Netzwerkspeicher usw. gedacht 
sind.

Und welchen Vorteil sollte ein einkanaliger UART-Konverter der 100 
kBit/s-Klasse mit Gigabit-Ethernet haben? Schließlich ist die 
Leistungsaufnahme rund zehnmal so hoch, insbesondere im Leerlauf. Für 
einen Gigabit-PHY muss man locker mit 2 A impulsförmiger Stromaufnahme 
rechnen. Das erfordert also ohne Not eine wesentlich leistungsfähigere 
Stromversorgung. Eine Baugruppe von anno 1998, an die dann jemand im 
Jahr 2012 ein XPort-Modul gedengelt hat, ist nicht unbedingt darauf 
ausgelegt.