Wie ich schrieb: nach 64 byte kommt \0.
Auf welcher IDE-Version lässt Du das laufen?
Welche versionen haben Deine Libs?
Und sorry - ich hatte oben in meinem Code zwei { } vergessen ;(
Ich habe gerade eine andere Bibliothek ausprobiert und da kommt alles an.
Die heißt "Wifinina_Generic" und "WifiUdp_Generic"
Zwar nacheinander, aber ich bekomme alles 
Dort werden dann die 64 Byte aufgeteilt.
Ich habe nur eine andere Bibliothek verwendet, der restliche Code ist alles gleich.
18:25:20.351 -> Received packet of size 115
18:25:20.398 -> From 192.168.178.20, port 50786
18:25:20.398 -> Contents:
18:25:20.445 -> 3131313131313131313131313131313131313131313131313131313131313131313131313131313131313131313131313131313131313131313131313131313100000000000000000000000000000000000000000000000000
18:25:20.633 -> 1111111111111111111111111111111111111111111111111111111111111111
18:25:20.681 -> Received packet of size 51
18:25:20.728 -> From 192.168.178.20, port 50786
18:25:20.728 -> Contents:
18:25:20.775 -> 3131313131313131313131313131313131313131313131313131313131313131313131313131313131313131313131313131
18:25:20.867 -> 1111111111111111111111111111111111111111111111111111111111111111
????
Und nun ist der TO stumm.
Gruß Tommy
Ja nu...
Hätte ich heute noch SIE, würde ich mich auch eher darum kümmern...
Nachdem was ich da rauslese, ist die erste Angabe das vollständige Packetsize - 115.
Da kommen 64 zurück und im nächsten Umlauf ohne neues zu senden kommen die restlichen 51.
Das ist tricky und irgendwie bin ich auch noch immer auf dem trip, das der Speicher nicht reicht um das vollständig auszulesen.
Andere Idee??
Ohne Reaktion des TO auch eher kein Interesse. Evtl. gibt es in der neuen Lib einen Mechanismus, der das aufdröselt, aber da habe ich derzeit keine Lust, zu suchen.
Wenn der TO damit zufrieden ist und sich nicht mehr meldet, ok, sein System.
Gruß Tommy
Irgendwo müsste man doch den Speicher festlegen können, dass wenigstens die 256 Byte am Stück gelesen werden können.
P.S.
Ich habe gestern mein Limit an Antworten erreicht, da ich auch erst gestern diesen Account erstellt habe. Ich konnte also nicht mehr antworten.
Und Danke für die schnellen Antworten!
machste ja,
aber ich erinner nochmal an #21
Sind Deine Firmware, libs, IDE auf dem aktuellen Stand?
Die Doku und den Code zu dieser Lib findest Du hier
Gruß Tommy
Hallo,
der Buffer auf Arduino Seite hat default nur 64 Bytes. Wird in der HardwareSerial.h festgelegt. Jetzt kommt die Vermutung, der Sender schickt mehr ohne weitere Kontrolle ob alles empfangen wurde. Deswegen geht der Rest gnadenlos verloren.
?
Was hat HWSerial da verloren?
So in der WifiNINA Library ist die Datei "WifiSocketBuffer.cpp".
Dort wird der Puffer auf 64 Byte festgelegt.
#define WIFI_SOCKET_BUFFER_SIZE 64
Den habe ich jetzt auf 256 erhöht und jetzt bekomme ich auch 256 Byte rein.
Danke nochmal für die vielen Antworten und das Interesse an meinem Problem!
Ihr habt mir auf jeden Fall sehr geholfen!
Viele Grüße
Weil der Verdacht nahe lag das WiFi davon erbt. Jetzt kam durch den TO raus das die Buffergröße dafür selbst festgelegt wird. Die Richtung der Gedanken stimmte.
Wobei ich da immernoch zwiegespalten bin.
Wenn das überladen nicht möglich ist, wozu kann man das machen?
Zumal das ja mal funktioniert hat.
Hallo,
ich stehe anscheinend auf dem Schlauch. Was soll überladen werden können?
Warum kann ich selbst eine Größe eines möglichen Buffer übergeben,
und so ist das auch vorgesehen,
wenn die nicht beachtet wird?
Da ist irgendwo im Hintergrund etwas fest verdrahtet, was da nicht fest verdrahtet gehört.
Ursprünglich funktionierte len auf Basis von packetsize in einem Durchgang.
Das war möglich, weil der buffer so gross gewählt werden konnte, wie er vermeintlich gebraucht wurde.
Aktuell macht die Angabe einer Größe keinen Sinn, der ist immer 64 bytes gross.
Richtig?
Hallo,
ich kann es ehrlich gesagt nicht ganz nachvolliehen. Fremde große Libs sind sowieso immer etwas besonderes.
Global definiert wird
char packetBuffer[255]; //buffer to hold incoming packet
Udp ist das Objekt
WiFiUDP Udp;
Dann gehts in loop los mit
int packetSize = Udp.parsePacket();
Hier scheitere ich schon wie ich die define Abfrage vertehen muss.
#if 0 ist hart kodiert. Auf was soll geprüft werden?
Ich weiß es nicht.
int WiFiUDP::parsePacket()
{
#if 0
while (_parsed--)
{
// discard previously parsed packet data
uint8_t b;
WiFiSocketBuffer.read(_sock, &b, sizeof(b));
}
#endif
_parsed = ServerDrv::availData(_sock);
#if (KH_WIFININA_UDP_DEBUG > 3)
Serial.print("WiFiUDP::parsePacket: len=");
Serial.print(_parsed);
Serial.print(", _sock =");
Serial.println(_sock);
#endif
return _parsed;
}
Dann kommt die read Methode dran.
int WiFiUDP::read(unsigned char* buffer, size_t len)
{
if (_parsed < 1)
{
return 0;
}
int result = WiFiSocketBuffer.read(_sock, buffer, len);
if (result > 0)
{
_parsed -= result;
}
#if (KH_WIFININA_UDP_DEBUG > 3)
Serial.print("WiFiUDP::read: buffer=");
for (int i = 0; i < result; i++)
{
Serial.print(String(buffer[i], HEX));
Serial.print(", ");
if (( i > 0 ) && ( i % 20 == 0 ))
Serial.println("");
}
Serial.println("");
#endif
return result;
}
Schauen wir uns WiFiSocketBuffer.read an
int WiFiSocketBufferClass::read(int socket, uint8_t* data, size_t length)
{
int avail = available(socket);
if (!avail)
{
return 0;
}
if (avail < (int)length)
{
length = avail;
}
memcpy(data, _buffers[socket].head, length);
_buffers[socket].head += length;
_buffers[socket].length -= length;
return length;
}
Die Bufferlänge wird mit available(socket) verglichen. Was ist _sock?
_sock ist ein privater Member der WiFiServer Klasse.
Datei WiFiUpd_Generic .h/.cpp
Wird mit der begin Methode irgendwie initialisiert.
uint8_t sock = ServerDrv::getSocket();
und wird unter einer Bedingung dann _sock zugewiesen.
uint8_t ServerDrv::getSocket()
{
WAIT_FOR_SLAVE_SELECT();
// Send Command
SpiDrv::sendCmd(GET_SOCKET_CMD, PARAM_NUMS_0);
SpiDrv::spiSlaveDeselect();
//Wait the reply elaboration
SpiDrv::waitForSlaveReady();
SpiDrv::spiSlaveSelect();
// Wait for reply
uint8_t _data = -1;
uint8_t _dataLen = 0;
SpiDrv::waitResponseCmd(GET_SOCKET_CMD, PARAM_NUMS_1, &_data, &_dataLen);
SpiDrv::spiSlaveDeselect();
return _data;
}
Was ist _data? Der 3. Parameter param.
int SpiDrv::waitResponseCmd(uint8_t cmd, uint8_t numParam, uint8_t* param, uint8_t* param_len)
{
char _data = 0;
int ii = 0;
IF_CHECK_START_CMD(_data)
{
CHECK_DATA(cmd | REPLY_FLAG, _data) {};
CHECK_DATA(numParam, _data)
{
readParamLen8(param_len);
for (ii = 0; ii < (*param_len); ++ii)
{
// Get Params data
//param[ii] = spiTransfer(DUMMY_DATA);
getParam(¶m[ii]);
//KH
#if (KH_WIFININA_SPI_DEBUG > 3)
Serial.print("spi_drv-waitResponseCmd: *param_len = ");
Serial.println(*param_len);
Serial.print("spi_drv-waitResponseCmd: *param[ ");
Serial.print(ii);
Serial.print(" ] = ");
Serial.println(param[ii]);
#endif
}
}
readAndCheckChar(END_CMD, &_data);
}
return 1;
}
param wird manipuliert mit
getParam(¶m[ii]);
void SpiDrv::getParam(uint8_t* param)
{
// Get Params data
*param = spiTransfer(DUMMY_DATA);
DELAY_TRANSFER();
}
spiTransfer gibt eigentlich nur das empfangene char zurück. Irgendwas fehlt mir im Zusammenhang mit der Bufferlänge. Weil das ist ja die Rückwärtsverfolgung was mit der Bufferlänge verglichen wird. Entweder bin ich wo falsch abgebogen oder ich verstehe es nicht.
char SpiDrv::spiTransfer(volatile char data)
{
char result = SPIWIFI.transfer(data);
DELAY_TRANSFER();
return result; // return the received byte
}
An der Stelle hört es bei mir auf das zu verfolgen bzw. zu verstehen. Tut mir leid. Da müßte man den Lib Schreiber fragen.
#if 0 ist eine (üble) Methode Codeteile stillzulegen. Erwische ich mich gelegentlich selbst bei, aber die Entwöhnung läuft
Ich vermute, dass damit Altcode aus einer vorherigen Version stillgelegt, aber während der Entwicklung noch nicht gelöscht werden sollte, damit man im Extremfall zurück kann. Dann wurde das im produktiven Stand vergessen zu entfernen.
Gruß Tommy
Ich kann Dir sagen, das ich 5 Stunden versucht habe, das zu zerlegen und gescheitert bin.
Da ich das nicht benutze - war und ist für mich an der Stelle das Ende der Fahnenstange erreicht.
Ich habe auch andere Baustellen.
Aber Danke das Du drauf geschaut hast.