Closed webworxshop closed 3 years ago
Thanks for your contribution.
Hi @webworxshop
Thanks for posting this fix, it makes perfect sense. The only problems that I see are:
With that said I think we could elaborate on possible options to fix this otherwise, e.g. calling the slipif_received_bytes()
in batches, since the API says it can work max 255 bytes, so we're in fact violating this definition in esp_netif_lwip_slip
module.
A quick idea to fix this in IDF is:
void esp_netif_lwip_slip_input(void *h, void *buffer, unsigned int len, void *eb)
{
...
// Update slip netif with data
const int max_batch = 255;
while (len > 0) {
int batch = len > max_batch?max_batch:len;
slipif_received_bytes(netif->lwip_netif, buffer, batch);
len -= batch;
}
...
}
Hi @david-cermak,
Thanks for your response, I understand the requirement to minimise changes to lwip and am happy to go for an alternate fix.
However, the code sample you provided seems incorrect to me, for two reasons:
buffer
, so that the correct slice is sent in each call to slipif_received_bytes
len
, since it is used to provide the end bound of the for loop directly below your code snippet.I've submitted an alternate fix at https://github.com/espressif/esp-idf/pull/5928, which resolves these issues and works in my testing.
@webworxshop Of course you are correct, thanks for fixing this and posing the IDF PR! I've only meant to sketch up the idea.
Thanks again, closing this in favour of the https://github.com/espressif/esp-idf/pull/5928
Allows SLIP interface to accept input of longer than 256 bytes in one go. Relevant to https://github.com/espressif/esp-idf/pull/4985, which will perform UART reads with a user defined (32-bit buffer length) and then attempt to write them into
slipif_received_bytes
.