Please don't point me to what it is used for, there are plenty of articles telling me how to make my Pi Zero an ethernet gadget.
Putting "dtoverlay=dwc2" into /boot/config.txt appears to fix a known issue with a CH340 Usb to Serial device (arduino clone) and yet when the wifi is disconnected it seems to eat up the processor!!! This doesn't make sense to me.
My setup is: RPi Zero connected to USB hub using an OTG cable then on to an Arduino Nano Clone (CH340) to make the Arduino the slave. Also in the hub is a Wifi thingy. The Pi is also connected to buttons, leds and an lcd display over I2C. EDIT: The hub is only powered from the pi and draws 100ma (peak 140ma) for itself, the wifi and the arduino.
Scenario 1: 'dwc2' in config.txt, arduino connected, wifi working. => Great! All works as expected.
Scenario 2: same as scenario 1 but wifi access point is off. => No remote access obviously. Wierd behaviour which makes me think that 99.9% of the processor is eaten up somewhere. The LCD updates a letter at a time and python asheduler tells me its missing its cron times by anywhere up to a minute. Usual service is resumed when the wifi is reconnected.
Scenario 3: 'dwc2' NOT in config.txt => All works except Arduino clone which gives the usual "usb_serial_generic_read_bulk_callback - urb stopped: -32" in dmesg. This behaviour is somehow FIXED in scenario 1. (and 2)
If I could keep dwc2 but stop it freaking out without wifi connected then I wouldn't need to fix the issue with the clone.
Edit: ideally I'd like to be told exactly why dwc2 appears to fix a driver issue yet hammers the processor (unconfirmed) when there is no network connection. I suspect that dwc2 is trying to use the CH340 to route network traffic when the wifi is down, but as I have no information as to the workings of dwc2, this is merely a guess. Information as to what it does functionally may help to diagnose this eg the stty parameters that it appears to change are: "min = 0 -icrnl -ixon -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke" with dwc2, "min = 1 icrnl ixon opost onlcr isig icanon iexten echo echoe echok echoctl echoke" without, though this alone does not make the dmesg errors go away. The command "lsusb -d1a86:7523 -v" gives exactly the same result in all scenario, so for example the USB speed is unchanged. It is rumoured that forcing the device to run at USB1.1 makes it work, but this isn't happening here.
To give context, if I asked 'how does the pi boot', I would be given a detailed list of events from first reading the SD card, through init and rc.local, run level 0 to agetty providing a login prompt. I am looking for a similar description.