USB TestDrive - Panda

Introduction

For some time now Belcarra has made available a USB test package system for the Gumstix Overo Earth and related boards. This package is ultimately based on the Angstrom system.

The goal of Testdrive Panda is to extend the project to newer systems using the TI Pandaboard. The decision was made to use Ubuntu instead of Angstrom because it’s possible to put a complete development system on board the distribution -- so if you want to test with an additional tool -- just load it on the board either with the package manager or in the worst case build it from source, all on the board, no cross-compilation needed.

However, another goal of the effort was to make this mostly unnecessary. For example, the standard network performance tool iperf is not part of the Ubuntu distro that we used, but we added a source for iperf to the package manager’s source list.

In addition to this, we customized the distro to use a more recent Linux kernel  with a customized configuration streamlined for USB testing.

Acquiring and Installing TestDrive-Panda

Testdrive Panda Features

Testdrive Panda is built on the Precise 10 Ubuntu distribution with some small customizations.

• The language is specified as English and date format is US English
• A custom Linux kernel rather that the one supplied in Precise 10, although the the original kernel is available
• Text-based operation only -- via the serial port or via ssh
• Simple scripts to load ECM NCM EEM modes with specified VID/PID pairs (Gadget)
• iperf available (see above)
• quick boot
• a special user user called testdrive with no password that is in the sudo group --  and therefore has root privilege via the sudo command.

USBLAN Support for RNDIS Protocol

Belcarra is pleased to announce the addition of the RNDIS protocol to USBLAN (http://usblan.belcarra.com/),

Belcarra’s USB Class Driver is a suite of products which enables networking over the USB link. Belcarra’s RNDIS implementation provides several USBLAN features including faster data transfer abilities. The addition of RNDIS gives USBLAN the most complete set of USB networking protocols available in a single driver product.

http://www.prweb.com/releases/2012/8/prweb9769681.htm

Contact us to receive your evaluation copy of the  USBLAN 2.4.3 release.

Virtual Driver for USB Network Devices

USBLAN for Mac OS/X

Belcarra’s new Virtual Driver for Networked USB devices greatly improves the end user experience for interfacing smart devices to the Mac OS/X desktop.

Traditional solutions create a network interface for each attached device requiring the user to find and then configure a network service for the interface with the correct operating parameters (IP address etc.)

Belcarra’s solution features a Virtual Network Interface that is created when the system is started. This interface can be configured to a static IP address or simply default to use the normal DHCP configuration.

The Virtual Network driver contains a bridge that performs two functions. First it connects all compatible devices plugged into the system to the Virtual Network Interface. Second it contains a Virtual DHCP server that can be used to configure both the Host (Mac System) IP address and each of the attached devices.

USBLAN 2.4.1 Available

USBLAN 2.4.0 release provided support for CDC-NCM and Microsoft NDIS 6.

USBLAN 2.4.1 now adds support for the Microsoft RNDIS protocol.

OEM's with with WinCE, embedded Linux or other devices configured to use RNDIS can now simply take advantage of USBLAN's many networking features such as:

• DHCP Service – DHCP service is not need on target or Windows, USBLAN's built in DHCP server option can be used to co-ordinate and assign address of both the host and device network interfaces 
• Composite function – the USBLAN driver is fully compatible with the Windows USB composite function support 
• WHQL – drivers are fully compatible with Microsoft Windows Hardware Quality Labs (WHQL) tests and procedures 
• Multiple devices can be connected allowing peer to peer networking and to the Windows desktop.

An evaluation version and OEM manual are freely available

Belcarra EEM Configuration Extension Descriptor

The CDC-EEM protocol is capable of aggregating multiple network datagrams into a single Bulk Data transfer.

The standard does not implement a mechanism to allow the host and device to determine an appropriate size for Bulk transfers. While implementing EEM without this information is possible, it complicates the implementation. If the Host and Device know what the capabilities of the other end are (WRT to transfer size especially) then the driver implementations can be significantly simpler and easier to implement.

This has led to many implementations only allowing for a maximum of 1536 byte transfers (based on Ethernet MTU of 1510 bytes.) and a single datagram per transfer. Other implementations require administrative configuration to configure one or more of the operating parameters.

The result is that the only safe configuration that can support unknown hosts or devices is:

•  CRC - disabled
•  bMaxDatagrams - 1
•  bMaxTransferSize - 1536

This extension described herein can be used by an EEM Class driver on the host to send configuration data to the device and receive configuration data from the device. The EEM Configuration Extension Descriptor is sent to the device as Echo Data command data.

If the device is non-conforming (does not support this extension), it will either ignore or send the command back unchanged (specifically the D0 flag of the bmFlags field will remain reset.) In this case the host will continue to use the default configuration.

Conforming devices will send the command back, but will fill in the configuration fields. If the device receives this command it can assume that the host will use the information to operate with. Otherwise they will operate with the default configuration. Conforming devices MUST SET the D0 bit of the bmFlags field to indicate that they have recognized this configuration request and are responding with valid values.

Multiple Frame Support

Networking over USB protocols can support network frame aggregation. This allows for multiple network frames to be transferred in a single Bulk Data transfer.

USB Bulk Data transfers have overheads. Both at the bus level where individual transfers must be terminated with a short data packet. And at the OS level where the USB controller drivers must setup and tear down each transfer. And finally in the communication between the protocol driver (class driver on host systems and matching function driver on devices) and the low level controller drivers. These add latency to the time it takes for each transfer to take place.

Aggregating multiple network frames into a single Bulk Data transfer allows the overheads and associated latencies to be absorbed across multiple network frames.

Care must be taken in the use of this feature though. Additional latency is induced as the entire Bulk Transfer must be received before any of the network frames it contains can be forwarded. This places a bound on effective number of frames that should be aggregated. The actual number is best determined by using simple heuristics at runtime to ensure that the use of available bandwidth is optimized with only minimal latency added.

Effective multi-frame support can provide close to 100% improvement in throughput.

See also: Networking over USB Protocol Comparison