RS232 zu Ethernet Gateway mit Arduino

[Manfred S. (Firma: Manfred) (xfred343)]

Ich stehe hier vor einem komischen Problem. Irgendwie dürfte die 
serielle Schnittstelle sich beim Arduino gemeinsam mit Ethernet 
eigenartig verhalten.
Es sollen Daten auf Port 23 (Telnet) ausgegeben werden, allerdings ein 
serieller Befehl mit einem TCP/IP-Paket.

Ohne dem Trick mit millis() sendet der Arduino ein Paket  mit dem ersten 
Buchstaben und teilt das TCP/IP-Paket auch sonst in mehrere Pakete auf.
Selbst ein Delay hilft da nicht weiter.

    if (x>0){
       delay(50); //geht trotz Warten nicht
       cmdServer.write(g_buf,x);
       x=0;
    }

Mit dem millis() gehts hingegen

    if (x>0 && millis()>blnWait){
       cmdServer.write(g_buf,x);
       x=0;
    }

Mit wireshark sieht man exakt 1 Paket.
Hat irgendwer eine Idee, warum das so ist?

#include <SPI.h>
#include <Ethernet.h>
#define port 23 // Port Telnet
byte mac[] = {0x90, 0xA2, 0xDA, 0x10, 0x5C, 0xFF};
IPAddress g_ip(192, 168, 0, 180);
IPAddress g_gateway(192, 168, 0, 1);
IPAddress g_sub(255, 255, 255, 0);
char g_buf[255];

EthernetServer cmdServer(port);
void setup() {
  Ethernet.begin(mac,g_ip,g_gateway,g_sub);
  Ethernet.setRetransmissionCount(1);  //total number of transmission attempts 
  Ethernet.setRetransmissionTimeout(500);  // set the Ethernet controller's timeout to 500 ms
  cmdServer.begin();
  Serial.begin(9600);
}
void loop() {
  static int x=0;
  static char c;
  static EthernetClient client;
  static unsigned long blnWait;
  if (!client.connected()){
    client = cmdServer.available();
    if (client){
      client.setConnectionTimeout(300);  // set the timeout duration 
    }
  }
  else{
    if (Serial.available()){
      blnWait=millis()+50;
      if (x<255)
         g_buf[x++]=Serial.read();
    }    
    if (x>0 && millis()>blnWait){
       cmdServer.write(g_buf,x);
       x=0;
    }
  }
}

[Patrick (Gast)]

Kann es sein, dass client.connected() auch Werte ungleich null annimmt, 
die sowas wie "Verbindungsaufbau aktiv" aussagen, die du statt 
"!client.connected() auswerten musst? Kannst dir den Wert ja mal auf die 
serielle Schnittstelle spucken lassen.

[Patrick (Gast)]

Quatsch, der wird einfach noch nicht fertig sein mit dem serialread - 
sobald er ein Zeichen empfangen hat, schickt er das los - dein millis() 
überbrückt sozusagen die Zeit des seriellen Empfangs aller Zeichen des 
Befehls, bevor per TCP/IP verschickt wird. Könntest du so lassen, oder 
du bildest dir ein anderes Kriterium für "Empfang abgeschlossen".

[jo mei (Gast)]

Manfred S. schrieb:
> Es sollen Daten auf Port 23 (Telnet) ausgegeben werden, allerdings ein
> serieller Befehl mit einem TCP/IP-Paket.

Habe die Problemstellung nicht wirklich verstanden aber hier
meine Gedanken zu deinem potenteillen Problem:

TCP und "ein Paket" ist ein Widerspruch in sich da man die
Einheit eines Paketes das man zu Sendung beauftragt auf der
TCP-Ebene nie garantiert bekommt dass man es unzerstückelt
(besser: unfragmentiert) beim Emfänger erhält.

TCP ist ein Stream bei dem man garantiert bekommt (Fehler-
kontrolle) dass Daten korrekt übertragen werden. Für die
kontrolle der Zerstückelung (Fragmentierung) und der
erforderliche "Wiederzusammenbau" ist per User-Protokoll
der User selbst verantwortlich.

[Manfred S. (Firma: Manfred) (xfred343)]

Bei dem Stream magst du Recht haben, aber einzelne Pakete - noch dazu 
bis maximal 255 Byte - werden dabei nicht in Teilpakete zerlegt. Die 
werden über ein fehlerfreies Verfahren (am Ende ein ACK) schon 
durchgereicht.

Auf der anderen Seite (PC) ist mein Programm, das über das 
winsock-Steuerelement dann die Befehle entgegen nimmt, das geht z.B. mit 
den Modbus-Komponenten von Beckhoff ganz problemlos - hier kommt auch 
immer nur 1 Paket und ich mag nicht extra für den Arduino meine 
winsock-Klasse umbauen.

Aber vielleicht gibts ja eine Möglichkeit statt dem millis() gleich 
direkt rauszubekommen, ob Serialread() abgeschlossen ist?

[jo mei (Gast)]

Manfred S. schrieb:
> Aber vielleicht gibts ja eine Möglichkeit statt dem millis() gleich
> direkt rauszubekommen, ob Serialread() abgeschlossen ist?

Ja, indem du das Steuerzeichen auswertest das du als Abschluss
deines Komandos bzw Datenpakets erwartest. Typischer Fall wäre
CR/LF bei Text. Oder sehe ich da etwas zu einfach? Ja, das
eigene Protokoll bleibt auf jeden Fall in User-Verantwortung.

[foobar (Gast)]

> Bei dem Stream magst du Recht haben, aber einzelne Pakete - noch dazu
> bis maximal 255 Byte - werden dabei nicht in Teilpakete zerlegt. Die
> werden über ein fehlerfreies Verfahren (am Ende ein ACK) schon
> durchgereicht.

Na, dann setzt mal nen Router mit ner kleinen MTU (z.B. 96) zwischen die 
beiden Rechner - der Empfänger bekommt die Daten dann in schönen kleinen 
40- bis 50-Byte-Blöcken.  Aus einem 200-Byte-write werden dann z.B. vier 
50-Byte-reads.  Ist ein oft zu sehender Fehler in Anwendungen, dass sie 
davon ausgehen, dass das gesamte "Paket" oder die "Befehlszeile" mit 
einem read angeliefert wird - im LAN klappt das meist, im WAN geht's 
schnell schief.

Wer bei TCP Pakete braucht, muß das auf Anwenderebene implementieren - 
das Protokoll gibt das nicht her.

[portwalker (Gast)]

foobar schrieb:
> Wer bei TCP Pakete braucht, muß das auf Anwenderebene implementieren -
> das Protokoll gibt das nicht her.

Hier ist von TCP/ IP die Rede und nicht nur von TCP.

Da muss sich kein “ Userlayer” um irgendwas kümmern!

Also Bullshit das Gequassel.

[jo mei (Gast)]

portwalker schrieb:
> Hier ist von TCP/ IP die Rede und nicht nur von TCP.

Kann ich aus den Infos die der TO liefert nicht erkennen.

Einfach mal "TCP/IP" sprechen und nichts dazu liefern, dann
muss ich mal TCP annehmen. So sieht sein Sourcen-Fragment
auch aus. Lasse mich aber gerne belehren.

[jo mei (Gast)]

portwalker schrieb:
> Also Bullshit das Gequassel.

foobar schrieb:
> Wer bei TCP Pakete braucht, muß das auf Anwenderebene implementieren -
> das Protokoll gibt das nicht her.

[Manfred S. (Firma: Manfred) (xfred343)]

Danke für die durchaus interessanten RÜckmeldungen, als Belohnung gibts 
mein jetzt fertiges RS232 zu TCP/IP Gateway - vielleicht kanns ja jemand 
brauchen.

Es ist schon im Einsatz und zwar an der Servicestelle eines Fröling 
Pelletskessels H3200, funktioniert alles problemlos.

Der Vorteil gegenueber einer Serial2TCPIP Loesung in Github ist, dass 
meine die Antworten puffert und nicht jedes Zeichen gleich auf den Weg 
schickt..

Serial1 ist übrigens für den Atmega (Arduino Mega 2560) bestimmt und 
dort auf PIN18(RX) und PIN19(TX)

#include <SPI.h>
#include <Ethernet.h>
#define port 1600 // Port
byte mac[] = {0x90, 0xA2, 0xDA, 0x10, 0x5C, 0xFF};
IPAddress g_ip(192, 168, 8, 72);
IPAddress g_gateway(192, 168, 8, 1);
IPAddress g_sub(255, 255, 255, 0);
char g_buf[255];

EthernetServer cmdServer(port);
void setup() {
  //Watchdog stellen
  cli();                            // Disable the Interrupts
  WDTCSR = (1 << WDCE) | (1 << WDE); // Enable the WD Change Bit
  WDTCSR = (1 << WDE) | (1 << WDP3) | (1 << WDP0); //  Enable WDT Interrupt, 8 sec (WDP3=1, WDP0=1)
  sei();
  Ethernet.begin(mac,g_ip,g_gateway,g_sub);
  Ethernet.setRetransmissionCount(1);  //total number of transmission attempts 
  Ethernet.setRetransmissionTimeout(500);  // set the Ethernet controller's timeout to 500 ms
  cmdServer.begin();
  Serial1.begin(57600);
}
void loop() {
  static uint8_t x=0;
  static char c;
  static EthernetClient client;
  static unsigned long blnWait;
  __asm__("wdr\n\t");   //Watchdog-Reset  
  if (!client.connected()){
    client = cmdServer.available();
    if (client){
      client.setConnectionTimeout(300);  // set the timeout connect/stop
    }
  }
  else{
    if (client.available()){
        c = client.read();
        Serial1.write(c);
    }
    if (Serial1.available()){
      blnWait=millis()+50;
      if (x<255)
         g_buf[x++]=Serial1.read();
      else
        Serial1.read(); //restliche Zeichen überlesen
    }    
    if (x>0 && millis()>blnWait){
       client.write(g_buf,x);
       delay(10);
       x=0;
    }
  }
}

[jo mei (Gast)]

Manfred S. schrieb:
> als Belohnung gibts
> mein jetzt fertiges RS232 zu TCP/IP Gateway - vielleicht kanns ja jemand
> brauchen.

Ich betrachte dies eher als Strafe als als Lösung. Das ist für
jeden anderen Anwender unbrauchbar.

Eine Datenübertragung die auf (WD-)Reset und Daten-Timeouts und
Puffer-Überlauf als Kern des Protokolls baut .....   danke.

[Johannes S. (Gast)]

Manfred S. schrieb:
> Der Vorteil gegenueber einer Serial2TCPIP Loesung in Github ist, dass
> meine die Antworten puffert und nicht jedes Zeichen gleich auf den Weg
> schickt..

das ist bei TCP eigentlich per default so und wird durch den Nagle 
Algorithmus gemacht, da werden kleine Häppchen bis 200 ms gesammelt und 
erst dann geschickt.
Wenn man das nicht möchte kann man das per Socketoption TCP_NODELAY 
abschalten, das wird vermutlich in deinem EthernetClient gesetzt sein.

[jo mei (Gast)]

Johannes S. schrieb:
> Wenn man das nicht möchte kann man das per Socketoption TCP_NODELAY
> abschalten

Sein Ethernet Client ist ein Arduino mit Ethernet Shield und das
ganze mit der Arduino Ethernet Klasse gesteuert.

Da gibt es keinen Nagle! Jedenfalls keinen beeinflussbaren. Und
Socketoptionen schon gleich gar nicht.

Auf dem Arduino läuft nämlich weder Windows noch Linux. Auch
nicht auf dem Arduino-Ethernet-Controller.

[Manfred S. (Firma: Manfred) (xfred343)]

> Ich betrachte dies eher als Strafe als als Lösung. Das ist für
> jeden anderen Anwender unbrauchbar.
>
Wo bleibt dann deine geniale Lösung?
Bitte her damit

[jo mei (Gast)]

Manfred S. schrieb:
> Wo bleibt dann deine geniale Lösung?

Soweit kommt's noch. Ich soll dir ein Protokoll schreiben von
dem du selbst nicht weisst was es tun soll.

Die Spezifikation deiner Aufgabenstellung lautet: machen sie mal.
Auf diese Art ist wohl der neue Berliner Flughafen entstanden.

[c-hater (Gast)]

jo mei schrieb:

> TCP ist ein Stream bei dem man garantiert bekommt (Fehler-
> kontrolle) dass Daten korrekt übertragen werden.

Und darüber hinaus: in der richtigen Reihenfolge!

> Für die
> kontrolle der Zerstückelung (Fragmentierung) und der
> erforderliche "Wiederzusammenbau" ist per User-Protokoll
> der User selbst verantwortlich.

Was komplett überflüssig ist, wenn die Daten wirklich als Stream benutzt 
werden und nicht irgendeine Paketierung erwartet wird.

Das dürfte der Grundfehler (des Empfängers!!!) sein.

Eine COM-TCP-Bridge braucht sich um so'n Scheiß garnicht zu kümmern. Es 
ist schließlich sowieso hoffnungslos, einen TCP-Stream, der (zumindest 
theoretisch) über unzählige Zwischenstationen mit vollkommen unbekannter 
möglicher maximaler Paketgröße laufen kann, irgendwie sinnvoll bezüglich 
der Paketgröße steuern zu wollen. Das gibt das Protokoll schlicht nicht 
her.

[Stefan F. (Gast)]

Mir ist noch ein anderer Neben-Schauplatz aufgefallen:

Manfred S. schrieb:
> blnWait=millis()+50;
> if (millis()>blnWait)

Ich glaube das funktioniert beim Timerüberlauf nicht wie erwartet. 
Schreibe besser

> start=millis();
> if (millis()-start>50)

Der Trick liegt in der Subtraktion, die liefert trotz Timer-Überlauf 
noch das richtige Ergebnis.

[Manfred S. (Firma: Manfred) (xfred343)]

Stefan ⛄ F. schrieb:
> Mir ist noch ein anderer Neben-Schauplatz aufgefallen:
>
> Manfred S. schrieb:
>> blnWait=millis()+50;
>> if (millis()>blnWait)
>
> Ich glaube das funktioniert beim Timerüberlauf nicht wie erwartet.
> Schreibe besser
>
>> start=millis();
>> if (millis()-start>50)
>
> Der Trick liegt in der Subtraktion, die liefert trotz Timer-Überlauf
> noch das richtige Ergebnis.

Ja, stimmt genau, das hatte ich schon wieder vergessen, das ist auch in 
jenem Moment richtig wo der Timerüberlauf passiert.. bei der Gelegenheit 
werd ich die Variable gleich in lngWait umbenennen Danke