From 8b2c69d79e868651817d42d488d0e1045c522093 Mon Sep 17 00:00:00 2001 From: Hardy Griech Date: Mon, 26 Jun 2023 08:14:47 +0200 Subject: [PATCH] lwip-notes updated --- doc/lwIP-notes.adoc | 113 +++++++++++++++++++++++++++----------------- 1 file changed, 70 insertions(+), 43 deletions(-) diff --git a/doc/lwIP-notes.adoc b/doc/lwIP-notes.adoc index 96cdf96f3..078747b36 100755 --- a/doc/lwIP-notes.adoc +++ b/doc/lwIP-notes.adoc @@ -13,55 +13,69 @@ an uncountable number of additional CDC com ports. + Currently just a Segger SysView server is listening on port 19111. But I guess there is more to come. + +## Pitfalls + lwIP had some traps waiting for me. Despite reading the official https://www.nongnu.org/lwip/2_1_x/pitfalls.html[Common Pitfalls] I took some of them. -MAC:: Do not use a random MAC! At least not for the first byte. - I was "lucky" choosing one with an odd first byte. Unfortunately - bit 0 marks a group address. At least Linux rejects such MAC - addresses with a more or less useless error message in the syslog. - Took a while until I found out that the MAC address was the culprit - for no communication. + - Finally I have used 0xfe as the first byte and the remaining five - bytes of the MAC address are copied from the last bytes of Picos serial number - (which actually is the serial number of the external flash). - -OS Mode:: *really* take it serious what they are writing about "raw" APIs - and only using the TCPIP thread for any calls to it. + - Use `tcpip_callback_with_block(, , 0)` for - non-blocking invocations of some function. This also saves you - from creating extra simple threads for communication tasks line - in the TineUSB/lwIP glue code. That was my first idea and it took - a while until I found out how bad that idea was. + - Same was true for the thread(!) which stuffed data for SysView into - it's server: bad idea! + - Effect of wrong API handling were random crashes or connection - disruptions. +### MAC + +Do not use a random MAC! At least not for the first byte. +I was "lucky" choosing one with an odd first byte. Unfortunately +bit 0 marks a group address. At least Linux rejects such MAC +addresses with a more or less useless error message in the syslog. +Took a while until I found out that the MAC address was the culprit +for no communication. + +Finally I have used 0xfe as the first byte and the remaining five +bytes of the MAC address are copied from the last bytes of Picos serial number +(which actually is the serial number of the external flash). -RNDIS/ECM/NCM:: - To be honest, I'm very confused about the system behaviour of RNDIS/ECM/NCM. - Sometimes the host gets "disconnected", because the DNS in `/etc/resolv.conf` - are changed, sometimes not. Sometimes the probe needs `dhclient` to get - the TCP/IP connection, sometimes not. Sometimes the probe has an IPv6 address, sometimes - not. And this all just on my Linux host. Interoperation with Windows - makes things even worse. + - And `/etc/network/interfaces` generates error - messages even when the device has `allow-hotplug`. + - * *RNDIS*: this was my former favorite, because it is supported by all - relevant OSs. Also throughput seemed to be good. - Unfortunately RNDIS seems to manipulate routing in a way that the - default route on my Linux wants to go through the probe. Not - really what I want... - * *NCM*: is said to be the best choice. I did not manage to get an - acceptable throughput. Transfer seems to get stuck from time to time - and SystemView aborts. So also not the favorite. - * *ECM*: works good, packets are transferred continuously, throughput - also seems to be ok. So this is the way to go. + - Unfortunately there is no driver integrated into Win10, so possible - extra trouble appears. Yes... extra trouble: cannot find a driver - for Win10. +### OS Mode + +*really* take it serious what they are writing about "raw" APIs +and only using the TCPIP thread for any calls to it. + +Use `tcpip_callback_with_block(, , 0)` for +non-blocking invocations of some function. This also saves you +from creating extra simple threads for communication tasks line +in the TineUSB/lwIP glue code. That was my first idea and it took +a while until I found out how bad that idea was. + +Same was true for the thread(!) which stuffed data for SysView into +it's server: bad idea! + +Effect of wrong API handling were random crashes or connection +disruptions. + + +### RNDIS/ECM/NCM + +To be honest, I'm very confused about the system behaviour of RNDIS/ECM/NCM. +Sometimes the host gets "disconnected", because the DNS in `/etc/resolv.conf` +are changed, sometimes not. Sometimes the probe needs `dhclient` to get +the TCP/IP connection, sometimes not. Sometimes the probe has an IPv6 address, sometimes +not. And this all just on my Linux host. Interoperation with Windows +makes things even worse. + +And `/etc/network/interfaces` generates error +messages even when the device has `allow-hotplug`. + +* *RNDIS*: this was my former favorite, because it is supported by all + relevant OSs. Also throughput seemed to be good. + Unfortunately RNDIS seems to manipulate routing in a way that the + default route on my Linux wants to go through the probe. Not + really what I want... + +* *NCM*: is said to be the best choice. I did not manage to get an + acceptable throughput. Transfer seems to get stuck from time to time + and SystemView aborts. So also not the favorite. + + `iperf` is running fast, it seems that `ncm_device.c` output is triggered + by incoming packets. + +* *ECM*: works good, packets are transferred continuously, throughput + also seems to be ok. So this is the way to go. + + Unfortunately there is no driver integrated into Win10, so possible + extra trouble appears. Yes... extra trouble: cannot find a driver + for Win10. [NOTE] ==== @@ -72,8 +86,21 @@ This is not a fault of lwIP, it is a bug in the Win10 driver(?). ==== +## Performance + +To measure performance, `iperf` is used (which implies, that `OPT_NET_IPERF_SERVER` +must be set on built). Good command line for measurement: + + iperf -c 192.168.14.1 -e -i 1 -l 1024 + + ## Log +### 2023-06-26 + +* after some changes to `rtt_console.c`, `net_sysview.c` and `net_glue.c` + ECM is working again as expected + ### 2023-05-12 * for unknown reasons the probe is even with ECM in stutter mode, don't know