Arduino Nano mit Ethernetshield: TCP-Verbindung bricht ab

[Frank E. (Firma: Q3) (qualidat)]

Ich arbeite an einem Projekt, wo Schaltkommandos per TCP zu einem 
Arduino Nano mit Ethernetshield gesendet werden sollen. UDP fällt leider 
aus, weil die Übertragung später mal aus einer Webseite heraus erfolgen 
soll, da gibts nur TCP.

Es funktioniert ja im Prinzip auch, aber nach jeweils 4..5 Kommandos 
kommt keine Datenübertragung mehr zustande. Erst ein Hard-Reset hilft.

Dabei ist es egal, ob ich die einmal aufgemachte TCP-Verbindung offen 
lasse, oder (wie z.B. ein Browser) öffne, übertrage und dann schiesse. 
In beiden Fällen kann ich leider immer nur eine begrenzte Anzahl 
übertragen.

Der Empfang erfolgt im loop()-Bereich mit diesem Code-Schnipsel. Der 
Algorithmus zur Befehlserkennung funktioniert mit Serial und 
Serial.read() über Stunden einwandfrei. Es muss schon ein spezielles 
Netzwerkproblem sein.

EthernetClient client = server.available();
 
        while(client.available())
        {
          
          cmd[0]=cmd[1];cmd[1]=cmd[2];cmd[2]=cmd[3];cmd[3]=cmd[4];cmd[4]=cmd[5];
          
          cmd[5]=client.read();

          if(cmd[0]=='<' && cmd[5]=='>')
          {
            param=100*(cmd[2]-48)+10*(cmd[3]-48)+(cmd[4]-48); 
            client.print(String(cmd));       
            switch(cmd[1])
            {
              case 'L': laser(param); break;
              case 'H': hmov(param); break;
              case 'V': vmov(param); break;
              case 'B': blnk=param; break;
            }
          }
          
        }
        client.stop();

Wo ist der Fehler ... bzw. wie halte oder bekomme ich dieses Code-Stück 
zuverlässig? Danke für Tips.

Nachtrag: Könnte es ein Speicher-Problem sein? Beim Compilieren erhalte 
ich die Info: "Der Sketch verwendet 21670 Bytes (70%) des 
Programmspeicherplatzes. Das Maximum sind 30720 Bytes.
Globale Variablen verwenden 1270 Bytes (62%) des dynamischen Speichers, 
778 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
"

[Stefan F. (Gast)]

Ich vermute den Fehler woanders. Du solltest erst mal ein 
Beispielprogramm versuchen dass garantiert ok ist um Hardwarefehler 
auszuschließen.

Und gewöhne Dir an, vollständige (ausführbare) Quelltexte zu posten, 
allerdings auf möglichst wenig Zeilen reduziert, wo das Problem mit 
nachvollziehbar ist.

[Jim M. (turboj)]

Frank E. schrieb:
> Nachtrag: Könnte es ein Speicher-Problem sein?

Zur Beantwortung müssten wir Deinen vollständigen Source Code sehen...

[Fred R. (Firma: www.ramser-elektro.at/shop) (fred_ram)]

Dazu kommt, das diese Shields nicht gerade einem Router nahe kommen :-/

[Frank K. (fchk)]

Frank E. schrieb:

> Globale Variablen verwenden 1270 Bytes (62%) des dynamischen Speichers,
> 778 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.

Das reicht ja nicht mal für einen kompletten Ethernet-Frame von 1.5k.


fchk

[Frank E. (Firma: Q3) (qualidat)]

Frank K. schrieb:
> Frank E. schrieb:
>
>> Globale Variablen verwenden 1270 Bytes (62%) des dynamischen Speichers,
>> 778 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
>
> Das reicht ja nicht mal für einen kompletten Ethernet-Frame von 1.5k.
>
> fchk

Der landet m.E. auch zunächst nur im Puffer des ENC28j69. Daraus wird 
mittels client.read() byteweise gelesen. Oder?

[Stefan F. (Gast)]

Wenn die Software auf µIP oder lwIP basiert, dass liest sie immer den 
ganzen Puffer am Stück aus. Allerdings bin ich gewohnt, dass der dazu 
nötige Speicher statisch reserviert wird.

Wenn den Controller tatsächlich nur 2kB RAM hat, dann ist der wirklich 
zu klein, um sinnvoll Ethernet nutzen zu können.

Zur Not kannst du versuchen, kleinere Puffer zu benutzen, aber das ist 
dann auch wieder mit zahlreichen Haken verbunden. Als mindest-Controller 
empfehle ich einen ATmgea664.

[Joachim B. (jar)]

Stefan U. schrieb:
> Als mindest-Controller
> empfehle ich einen ATmgea664.

644? -> – 4 Kbytes Internal SRAM

also ehrlich wer will denn da sparen, ich plädiere für einen m1284p mit 
16 KB SRAM, ist in meinem Pollin Webserver auf AVR Basis auch drin.

[Frank E. (Firma: Q3) (qualidat)]

ne ne ne ... Leute. Bleiben wir mal bitte beim Thema Nano.

Ich habe ein anderes Projekt, ebenfalls mit dem Nano und genau diesem 
Ethernetshield mit der selben Lib, allerdings per UDP, das läuft seit 2 
Jahren völlig problemlos.

Es muss schon mit TCP zusammenhängen. Ein Bug in der Library 
UIPEthernet.h ist ja evtl. auch nicht völlig aiuszuschließen ... 
allerdings hätte man dazu etwas im Web finden/lesen müssen ...

Wird wohl nur irgend eine fiese Kleinigkeit sein ...

[Kaj G. (Firma: RUB) (bloody)]

Das erste was ich mal umschreiben wuerde:
> cmd[0]=cmd[1];cmd[1]=cmd[2];cmd[2]=cmd[3];cmd[3]=cmd[4];cmd[4]=cmd[5];

Sorry, aber sowas geht gar nicht...

for (uint8_t i = 0; i < 5; i++) {
    cmd[i] = cmd[i + 1];
}

Und dann solltest du mal die Doku lesen...
https://www.arduino.cc/en/Reference/ClientRead

Returns

The next byte (or character), or -1 if none is available.

Und jetzt schauen wir uns nochmal deinen Code an:

while (client.available()) {
    for (uint8_t i = 0; i < 5; i++) {
        cmd[i] = cmd[i + 1];
    }

    cmd[5] = client.read();

    if (cmd[0] == '<' && cmd[5] == '>') {
        ...
    }
}

Jetzt musst Du wissen, ob es zu Problemen fuehren kann, wenn das Array 
cmd mit -1 gefuellt wird. Wir wissen ja nicht wie dein weiterer Code 
aussieht.

Ich wuerds umschreiben zu:

while (client.available()) {
    int8_t tmp = client.read();
    if (tmp != -1) {
        for (uint8_t i = 0; i < 5; i++) {
            cmd[i] = cmd[i + 1];
        }

        cmd[5] = tmp;
        if (cmd[0] == '<' && cmd[5] == '>') {
            ...
        }
    }
}

Ob das was mit deinem Problem zu tun hat? Keine Ahnung. Ob's logisch 
richtig ist? Keine Ahnung, du zeigst deinen Code ja nicht...

[Frank E. (Firma: Q3) (qualidat)]

Kaj G. schrieb:
> Das erste was ich mal umschreiben wuerde:
>> cmd[0]=cmd[1];cmd[1]=cmd[2];cmd[2]=cmd[3];cmd[3]=cmd[4];cmd[4]=cmd[5];
>
> Sorry, aber sowas geht gar nicht...
> for (uint8_t i = 0; i < 5; i++) {
>     cmd[i] = cmd[i + 1];
> }
> ...


Danke für deine Mühe, aber das kann nicht die Ursache sein. Ich benutze 
exakt den selben Code in Verbindung mit Serial & Serial.read().

Auch auf Senderseite verwende ich für beide Übertragungswege die gleiche 
Kommando-Erzeugung und sende jeweils mal per Serial oder per Socket.

Über Serial funktioniert der Code stundenlang ohne Probleme. Mag ja 
sein, dass meine Auswertung nicht optimal ist ... aber wegen der 6 
Zuweisungen finde ich eine Schleife jetzt nicht unbedingt zwingend. Wenn 
es 20 wären ... ja dann :-)

Inzwischen habe ich aber auch einen Verdacht in Richtung Macbook/OSX und 
Xojo. Frühere Projekte habe ich mit der 2016er Version gemacht, das 
heutige mit einer von 2017. Möglicherweise werden Sockets da irgendwie 
ausgebremst. Ich werde das Morgen nochmal mit Windows testen, vlt. suche 
ich auch nur an der falschen Stelle.

Ich habe beobachtet, dass die Aktivitäts-LED am Ethernetshield immer 
dann, wenn es nicht mehr funktionierte, auch nicht mehr synchron zu den 
Sendungen blinkte. Und zeitweise blinkte diese LED wiederum erheblich 
heftiger als das normale Broadcast-Geflimmere im heimischen LAN so 
üblich ist, obwohl ich garnicht sendete ...

Die meiste Zeit habe ich das Macbook im WLAN und der Arduino hing per 
Kabel am Switch. Aber auch eine direkte Kabelverbindung zwischen Macbook 
und Arduino brachte keine grundlegende Änderung. Allerdings ließ sich 
der Arduino auch nur sehr selten erfolgreich Pingen ... das änderte sich 
auch nicht mit einem anderen, zweiten Ethernetshield ...

[Frank E. (Firma: Q3) (qualidat)]

Ich habe dann doch noch wireshark angemacht ... und da kommt für die IP 
des Arduino einfach garnix, wenn ich mein Sendetool anwerfe.

Gebe ich die Adresse des Arduino in den Browser ein, sehe ich zumindest 
ARPs vom Macbook für die Adresse ... aber die weden nicht beantwotet ...

Nachtrag: Wenn ich mit meinem Tool auf die Adresse 255.255.255.255 
(Broadcast) sende, dann gibt splötzlich Datenverkehr aufzuzeichnen ...

ok, ist spääät ...

[Christian M. (Gast)]

Frank E. schrieb:
> Ein Bug in der Library UIPEthernet.h ist ja evtl. auch nicht völlig
> aiuszuschließen ..

Genau das! Die hat Bugs!

Gruss Chregu

[Kaj G. (Firma: RUB) (bloody)]

Frank E. schrieb:
> Danke für deine Mühe, aber das kann nicht die Ursache sein.
Ich hab auch nicht gesagt, das die Zuweisung was mit deinem Problem zu 
tun hat. Ist nur unschoen. Aber jeder wie er mag :o)