USB Host Support for the XL200 ARM (groundwork for the USB-to-Ethernet network feature)

The controller's USB port can now act as a USB "host" - meaning the XL200 can operate USB devices plugged into it, the way a PC does - in addition to its existing role as a device (the USB console released in July). The controller decides automatically at power-up which role to take based on what kind of cable is plugged in. This is the foundation for the upcoming feature that will give EtherCAT machines a network connection through a USB-to-Ethernet adapter (remote console, and eventually Eclipse connectivity).

This has been proven on the bench: the controller powers the USB port, recognizes an attached USB flash drive, and reads information from it - all while running a live EtherCAT machine network without disturbing it.

Three pre-existing problems were found and fixed along the way:

1. Plugging a USB device into a running machine used to freeze the entire controller for about 1/7 of a second - long enough for every EtherCAT drive on the machine to fault. The USB standard requires the controller to pause through several waiting periods when a device is first plugged in (letting the connection settle, resetting the device, letting it recover) - about 150 ms of mostly just waiting. As delivered by the chip vendor, all of that waiting was done inside the "drop everything" interrupt handling that runs when a device is detected, so the whole controller stood still for the duration. The fix moves this work out of the interrupt handling and into a low-priority background job: the interrupt now only takes a note that a device arrived (well under a microsecond), and the background job does the required waiting while everything else - EtherCAT, the 386 interface, all normal operation - keeps running at full speed. The same approach the vendor already used for the chip's other USB port was applied to this one; it was simply never finished on the port our hardware uses.

2. An error in the USB startup code could leave the port dead with no indication of why. Fixed: startup failures are now reported cleanly on the console and the rest of the controller keeps running.

3. The ARM processor has been using only about a third of the working memory it actually has - half of its RAM was reserved for a purpose that doesn't apply to our hardware and sat unused since the original board bring-up. This was discovered when USB support pushed memory usage over the old limit and networking failed to start. Fixed: all memory is now available. Every current and future feature on this processor benefits from this.

Also included: better diagnostics. Failures in network startup and USB power now print exactly what failed on the console instead of failing silently.

No change to normal operation: machines without anything plugged into the USB port behave exactly as before, and the USB console feature from July is unchanged.