ich könnte also in einer while schleife nach der 7'ten Zeile anfangen die restlichen Zeichen in ein array zu schieben und dort wieder zusammenzusetzen?
Ja, aber...
...mit while kann es sein dass der Code abbricht wenn nicht alles sofort da ist. Obwohl Ethernet natürlich schneller als Serial ist, braucht die Übertragung etwas Zeit. Das wird ja alles über SPI übertragen. Du kannst dann nicht nach dem ersten Zeichen gleich alles einlesen. Ständige Funktionsaufrufe kosten natürlich auch Zeit, aber so performant muss das hier nicht sein.
Man kann den Code etwas modifizieren indem man while macht um eventuell mehr in einem Rutsch zu lesen. Das würde sich hier anbieten, da man auf jeden Fall schneller als bei Serial ist. Aber da kann es auch sein, das nicht alles auf einmal da ist und man mehrmals abfragen muss bis man die ganze Zeile hat. Ich weiß aber auch nicht wie schnell die Ethernet Geschichte in diesem Zusammenhang genau ist.
Ich meine das so, dass du nicht denken solltest "ich nehme while um alles auf einmal einzulesen", sondern "ich nehme while um zu lesen was da ist, und dann ruft man eventuell mehrmals die Funktion auf bis man alles hat".
Man schaut dann mit client.avaible() nach ob was da ist. Wenn nein, bricht man die Funktion ab. Wenn ja, liest man den char ein und kehrt nach loop() zurück (oder ein while um mehr als ein char zu lesen). Wenn alles da ist, gibt die Funktion einen Zeiger auf das Array zurück. Ansonsten NULL. Wenn der Rückgabe-Wert also ungleich NULL ist, weiß man in loop(), dass man fertig ist. Wie gesagt ist der Code da für Serial, aber das sollte genauso mit Ethernet gehen. Man müsste allerdings noch überprüfen ob überhaupt eine Verbindung besteht.
Der Code von jurs liest das so ein:
char c=client.read();
if (c>=32 && charcount<sizeof(text)-1)
{
text[charcount]=c;
charcount++;
}
else if (c==10)
{
charcount=0;
return text;
}
Darum könnte man ein while(client.available) legen um eventuell mehrere Zeichen in einem Rutsch zu lesen. Es geht aber auch ohne, nur dann ein wenig langsamer. Bei Serial bringt das halt nichts, da die Zeichen 100-1000µs lang unterwegs sein können. Ob es sich hier lohnt weiß ich nicht. Du kannst es erst mal ohne probieren.
Bei dir kommt dann hier natürlich noch die Synchronisation auf das Startzeichen hinzu
Der Speicher würde schon wieder freigeben werden werden er lokal auf dem Stack wäre. Aber das geht bei der Polling-Version nicht, da er über die Funktionsaufrufe hinaus persistent sein muss. Aber so oder so ist es in diesem Fall Unsinn den ganzen Header einzulesen. Maximal braucht man Speicher für die längste Zeile. Und da auch nur wenn du jede Zeile einlesen würdest, was du nicht machst.
oder kann ich nicht gleich wenn ich "@" gefunden habe die array[zahl] abfragen um dann bei der nächst höheren weiter zu machen?
Es gibt wie gesagt mehrere Möglichkeiten. Das ist eine andere Option.
Allerdings wird vor dem @ gar nichts im Array abgespeichert. Man liest das Zeichen mit read() und schaut was es ist. Der Index steht solange auf 0! Wenn dann das @ kommt, setzt man eine boolean auf true damit man weiß dass man jetzt speichern muss. Dann wird das nächste Zeichen in array[index] geschrieben, also array[0]. Dann inkrementiert man den Index und er steht auf 1, usw.
Dann liest man solange ein bis ein LF kommt (c == '\n') oder (c == 10). Dann ist die Zeile zu Ende und man setzt den Index wieder auf 0 und den boolean auf false.