Hi
This is presumably because the loop is putting so much data into the output buffer that the buffer overflow (then the data is simply dropped).
To avoid this it is possible to first check the space in the TELNET output buffer (actually the buffered TCP's output buffer) and quit the loop when the buffer becomes full. Then, using the TX_FREE event the loop can continue once the output buffer has space again.
See the way that debug.c does this - it allows large command line menus to be sent to TELNET (or serial interfaces) which only have quite small buffer sizes.
while (iEntries--) {
if (!fnWrite(DebugHandle, 0, MAX_MENU_LINE)) { // the transmit buffer cannot accept more data so we will pause until it can
fnDriver(DebugHandle, MODIFY_WAKEUP, (MODIFY_TX | OWN_TASK));// we want to be woken when the queue is free again
iMenuLocation = (iEntries + 1); // save the position we stopped at
return 1;
}
iDisplayLen = fnDebugMsg(ptrCom->strCommand);
if (iDisplayLen >= ucTab) {
fnWrite(DebugHandle, ucTabs, 1);
}
else {
fnWrite(DebugHandle, ucTabs, (QUEUE_TRANSFER)(ucTab - iDisplayLen));
}
iDisplayLen = fnDebugMsg(ptrCom->strText);
fnDebugMsg("\n\r");
ptrCom++;
}
Here, each time a new command line item is to be sent there is first a check of the remaining buffer size (the write with zero buffer pointer). Once the space is no longer adequate the loop is quit (the loop variable is remembered so that the lpp can later continue from where it was) and the TX_FREE event is used (not shown in thsi code) to kick-off the next block.
Regards
Mark
