USB is a general purpose bus.  USB device subsystems (UDC's) are integrated into many popular embedded processors.  The detailed architectures of these UDC's vary considerably, in such matters as number and types of endpoints, DMA facilities, buffer architecture, etc.

Similarly, there are a variety of functions defined for USB, including various network protocols (RNDIS, CDC Ethernet, SAFE, etc.), some published and many not.  Other functions defined by the USB Forum include Audio, Printer, and Human Interface Device (HID).

In addition, the enumeration process is standardized for all functions.

Therefore, to maximize code reuse for USB Device software, Belcarra has created a three-layer USB Device Framework.

• The bus interface layer encapsulates the low level architecture specific details of each architecture, including matters such as the following:
  • number and types of endpoints (bulk, interrupt, isochronous, etc)
  • sending and receiving data using DMA
• The core layer provides a common API to the function layer (see below) and the bus interface layer (see above).  In addition, it incorporates enumeration services, otherwise known as endpoint zero services. These are core activities, common to every function, offering the host information on what function(s) and configuration(s) are available, and responding to host commands on which function/configuration to select
• The function layer implements the logical function in an architecture independent manner. Since the core layer handles enumeration, this reduces the size of the function modules.

GPL implementations of the core layer, bus interface modules for several architectures, and a network function module are available. These constitute a complete GPL target solution for several platforms.

USB Networking

As noted above, there is no single best protocol to use to implement Ethernet-style networking over USB. Indeed, in addition to the variants listed above, Belcarra has created others which are suited to particular purposes.  However, the Framework limits the impact of a particular choice of networking protocol. 

Consider for instance the particular function of networking.  Some would identify USB networking with Microsoft RNDIS. Given a monolithic implementation of Microsoft RNDIS, two situations arise all the time.

• There is a need to port the code to a different underlying architecture
• There is a need to support a different networking protocol, such as CDC Ethernet (to connect to non-Windows platforms).

These situations are all within the relatively narrow category of networking.

The USB Forum has published a number of standards which specify how a USB device can implement some well known peripheral functions in a standard way, e.g. network card, audio card, printer. Accordingly:

A USB Device requires two drivers, one driver to implement the Network Function and another driver to interface the USB Device onto the USB via a USB Bus Interface.

By keeping these drivers separated with an appropriate API it is possible to reuse the Function Driver on different architectures and to allow different Function drivers to be interchanged as simply as unloading a driver module and loading another.

The Belcarra USB Device Framework uses the following model: