AW: [Oberon] How is ETHO with USB?

[Stauber Sven Philipp]

>How is ETHO with USB?

It only supports some specific UHCI host controllers (see UsbUhci.Init).
This means no high-speed (or super-speed) transfers and that is won't
work on computers that come with OHCI host controllers (most non-Intel
systems).

>Apparently USB is rather complex?

Not necessary. In USB, there is a layer between the actual USB device
and its device driver (I call this layer USB system software here). This
layer takes care about things as device topology, power budget and
management, bandwidth management, ... 
Instead of directly accessing the hardware, the USB driver uses a
software interface provided by this layer (USB driver interface). So
instead of accessing the device's registers and buffers directly (memory
mapped I/O, I/O ports), the USB device driver tells this layer to do so.
Since this layer is aware about the USB topology, your driver won't have
to care about it - from the device driver's view point, it looks as it
would be directly talk to "its" device. 
The protocol used to drive the device is device-specific (except USB
class drivers) and "unknown" to the USB system software which in this
case acts a transport layer only (just moves bytes from/to the device).

--> In overall, USB is rather complex in comparison to legacy hardware,
but writing a USB device driver actually tends to be simpler because of
a reliable way to identify devices and more abstract device access. 

> [...] Does ETHO use this method too?

Yes, it does.

USB devices are identified by either class/subclass/protocol (generic
drivers) or vendorID/productID/[deviceRevision] (device-specific
drivers).
This information is part of the so-called USB device descriptor
(provided by all USB devices) and is automatically retrieved by the USB
system software as soon a device is connected.

For an example, have a look at UsbMouse.MouseProbe. This procedure will
be called by the USB system software to find out whether UsbMouse.Mod
can handle a specific device (abstracted as Usb.UsbDevice). This Probe
procedure has to be registered at the USB system (see module body).
When a device is connected, the USB system software calls all registered
Probe procedures to locate a driver.

> If so, different modules would be needed, to be able  to load the
correct one?

Yes, the USB system software needs to be started first (UsbSystem.Start)
and your device driver needs to register itself there (e.g.
UsbMouse.Init).

> Do the NetWork cards work like this also?

USB network cards are identified as any other USB devices. For PCI
cards, the device identification is very similar
(class/subclass/protocol rsp. vendorID/productID/deviceRevision, busses
and devices can be enumerated).
Also, there must somehow be an interaction between TCP/IP stack and
device drivers which implies  knowledge about which network card drivers
are loaded.

> Apparently for video drivers, the user needs to KNOW, before starting,
because the system can't talk to tell any probe results?

If the video card is PCI or similar (PCI-X, PCIe, AGP,...), devices can
be enumerated, identified and configured automatically. Because of the
possibility of reliable device identification, a piece of software that
knows details about the device (device driver) can be automatically
located and started (-> plug'n'play).

Best,
Sven