-- ShaiRevzen? - 27 Aug 2003

---

This page contains the summary of the USB or I2C? discussion. Subtopics are:

• RccDevEnv -- development environment tradeoffs
• RccBandwidth -- bandwidth and latency related issues
• RccHwComplexity -- hardware complexity issues
• RccCableTopology -- cabling and network topology issues
• RccSwArch -- software architecture issues
• CommSourceSinkList -- a draft list of possible hardware modules and their bandwidth requirements
• RccGlossary -- terms that were used/confused/invented

• RccFinalDesign -- Finalized design for the RiSE computation and communications hardware

Architectural Descriptions

Common Features

Sensors and actuators in the bus are essentially (slave) servers. They wait for requests from the bus master / CPU and respond with data and/or acknowledgement. At start up, bus master / CPU builds a list of the connected modules (auto-detect) and obtain their communication parameters (packet size, update frequency, etc.) During run-time bus master sweeps thru this list and exchanges information with each module.

I2C? -Based Communication Infrastructure

(AlRizzi - 23 Sep 2003) Hal's characterization of a possible I2C? implementation can be found under I2CbusCharacterization.

-- HaldunKomsuoglu? - 26 Aug 2003

I think of a bus physical topology where the bus lines are laid within the chassis of the robot and the modules are attached at the closest pass of the cables. This approach definitely simplifies cabling and the physical integration of modules would be a matter of placing a connector on this bus at the appropriate location. The bus is either 4-line (DAT,CLK,GND,VCC) or 6-line if we choose to use differential signalling for signal integrity. Note that the slaves are supplied from the bus.

I2C? is a widely accepted bus technology that virtually all microcontrollers implement. Can use a very very small and low power device (i.e. C8051F300? ) for a module whose task is simple but has severe space constraints. At the other extreme a much powerful chip designed for a more complex sensory task can also implement the required bus interface, too.

The sensor/actuator network will have a single master which has two functions: 1) arbitrating the communications; 2) implementing the bridge between the bus and the central computational unit.

Sensors and actuators in the bus are essentially (slave) servers. They wait for requests from the bus master and respond with data and/or acknowladgement. At start up, bus master builds a list of the connected modules (auto-detect) and obtain their communication parameters (packet size, update frequency, etc.) During run-time bus master sweeps thru this list and exchanges information with each module. Note that the resulting transport layer takes the form of a constant bit rate ATM protocol. This approach would yield deterministic timing properties.

The bridge between the bus and the central computational unit can be implemented by a dual-port RAM (similar the way it is done in RhIO) where the RAM becomes an intermediate blackboard for the information. On the bus side bus arbitrar updates the fields in this RAM that correspond to sensory modules and reads commands from actuator fields to be sent to the associated actuator modules. Independently on the other side of the RAM, the central processing unit can access to only those sensory data that it needs and update the command fields.

This scheme has two important advantages: 1) the interrupt service routine for the I2C? bus would be very simple (merely a data copy from bus to RAM), and therefore, very fast; and 2) the asynchronous layer implemented by the dual-port RAM would significantly decrease the load on central processing unit and simplify the interfacing software.

The I2C? hardware layer imposes a very low communication overhead. START, STOP and ACK signals are single bit events embedded within the stream and controlled by the hardware w/o any CPU time. Each packet has a 7-bit address followed by a user-defined length data bytes. For the sake of this discussion assume that the raw bus speed is set to 2.0 Mb/sec which is lower than the max possible in the chip set C8051Fxxx? . Even in the worst case scenerio where the data is a single byte following the address resulting in 50% bus efficiency the net throughput of the bus would be 1.0 Mb/sec.

I will assume that the number of hardware modules will be less than 128, and therefore, 7-bit address is sufficient to identify everybody. If we ever have more than 128 then some extension to the protocol with larger address space can be implemented.

USB-Based Communication Infrastructure

-- ShaiRevzen? - Aug 2003

Use off the shelf main board with USB 2.0 capability and a high fan-out (6-8 port) hub to connect to the external devices. Each "major" device requires its own USB speaking interface controller and 4 wires. The realistic payload bit-rate is either 10Mbps (USB 1.1) or 420Mbps (USB 2.0), of the nominal 12 / 480 MBps.

Each "major" device can consist of one or more sub-devices, connected to different logical USB pipes. These can be either low jitter TDMA sub-channels (isochronous pipes) or asynchronous packetized sub-channels (bulk pipes). The "major" devices can be debugged and developed using any USB capable PC with driver development tools (e.g. Linux).

The "little PCB's everywhere" problem can be avoided when using the USB architecture, because each USB device controller is capable of operating multiple sub-devices, so we would have maybe one board per (complex) leg, controlling all the sub-systems - sensors, actuators, etc. for that leg. This controller could also close a local sensory feedback loop, akin to the anchor dynamics of the template-anchor model, or the spinal cord in an animal.

Feature Comparison Summary

Feature	I2C	USB
Processor family	wide selection from 8-bit MCUs to DSPs	mostly limited to high-end processors
chip form factor	available in very small form factor	large package with large pin count
Raw Bandwidth	max 3.4 Mb/sec	USB 1.1 10 Mb/sec and USB 2.0 480 Mb/sec
Interface hw	requires custom interface development	supported by standard PCs
Cabling	simple and ergonomic bus topology	star topology with possibly complex and hard routing
Sub-channeling	without high-level channel management	hardware provides logical pipes and pipe types
Development sys	requires bus-PC interface card design & implementation	can use a standard PC