Communication bus discussion page

What do we want in a communications bus?

protection against EMI - a differential bus is great
"enough" bandwidth
priority messages should get through
error checking
retransmission of system critical messages (like messages from the pyro node) if an error occurs

Decision Criteria

Identify candidates
- CAN
- USB
Is there a likely showstopper for a candidate? If so, discard it
- USB: no
- CAN: no
ilities (in order)
- Reliability
- Congestion
  - USB: reserved bandwidth
  - CAN: message prioritization
- Devices going nuts (data)
  - USB:
  - turn off hub ports if each device has its own port?
  - will hub not forward unasked for transmits?
  - can we turn off the device?
  - will reserved bandwidth from the host just take care of it?
  - is there a way that hardware will not transmit unless it is asked, or can the device just transmit when it wants to?
  - CAN: no great solution
  - if a high priority device starts spewing messages, the bus will be taken over.
- Devices going nuts (hw)
  - choose not to consider risk
- Bus failure: open, short (noise OK, differential)
  - CAN:
  - open might be downstream and work
  - short loses (tolerates 20V, but the bus is hosed)
  - USB:
  - open just loses device
  - short: 20V to transceiver? data wires?
  - may have to make physical connection modifications to make sure the node doesn't blow up with 20V
    - when we launch, if a device can't talk on the bus, it's as good as dead.
    - we care if we don't have a replacement if the device blows right before a launch or in the field when we're testing
    - remanufacturing is more of a time constraint on PSAS members than a cost constraint (Bart can find grants)
- Behavior on packet corruption
  - CAN: CRC error in received packet triggers request to retransmit
  - USB:
  - iso transfers with corrupted packets are ignored by the intended receiver
    - the software will be able to tell the packet was lost, but it might not receive the corrupted packet
  - control transfers are retransmited (although it might not in the same frame)
  - interrupt transfers are ACK'ed (and no response is sent for corrupted packets)
- Overall transceiver / system reliability
  - CAN: high
  - USB: unknown, but probably lower. firmware failures, etc.
- HW impl difficulty
- Airframe issues: bus complexity
  - CAN: true bus
  - potential for peer-to-peer
  - makes wiring / assembly / disassembly easier (maybe)
  - USB: tree
  - isolates devices
  - need local hubs; wiring gets less convenient
- Tolerance to voltage on phy
  - CAN: already
  - USB: need to design appropriate measures
- Ability to debug / diagnose
  - CAN: need new thing
  - USB: just plugs into laptop
  - laptop 20V!
- Performance

Less important criteria

SW impl difficulty
- Micropackets
- USB: has bigger packets
- CAN: need to assemble packets more often
- Addressing
- USB: device enumeration hell
  - can use our own product IDs
- CAN: sensible addressing scheme
Team skills

Least important criteria

Reproducibility
Cost

Pros and Cons of various busses

USB

(-) no message-by-message priority
(+) fixed bandwidth for each device with isochronous transfers
(-) host must initiate all transfers (even isochronous and interrupt transfers)
(+) 12Mbps
(+) good for software team
- (+) know people with experience doing Linux USB device drivers
- (+) easy to test drivers with a laptop and half the avionics system
- (+) doesn't require uncanny or cantalope
- (+) won't have the modify code to work with uncanny or cantalope

CAN

Known system
(+) bandwidth is fine for current set of nodes
(+) higher priority nodes transmit first (message-by-message priority)

USB fact and question list

Facts:

uses master/slave model only
requires a host and a hub
FC uses USB 1.1 (full speed is 12Mbps)
- 12,000,000 bits per second / 1000 frames per second / 8 bits per byte = 1500 bytes per frame (ignoring bit stuffing)
we will probably need to make our own connectors and special wiring
a hub-cable pair will cause at max a 70ns propagation delay
- to put this in perspective, one bit is transmitted in 83ns (assuming 1500 bytes per frame)
depending on their design, hubs may be able turn off one port, all ports, or groups of ports when a control packet is received

Questions:

Does PP1 require a physical layer chip?
- (./) MPC2500 has OHCI (which requires more hardware). This means we need to make or buy a chip.
how do we do power up without 5 volts? (3.3V/5V)
latency with multiple endpoints?
- Isochronous scheduling
- each device is polled every 1ms
  - note that this does NOT mean that with 5 devices, you have 5ms between polls.
  - when adding more isochronous devices, you have to make sure that the max packet size you allocate for each endpoint doesn't go over the maximum bytes allowed in a frame
- no handshaking, no way of knowing the data was received
- if a CRC check fails during an isochronous transfer, what happens?
- (./) If a CRC check fails, the receiver ignores the packet, and the transmitter doesn't try to resend the failed packet. For system-critical nodes where we really want the message to get through, the USB driver or client software would probably attempt to resend the packet during the next poll. According to the USB 1.1 spec, errors due to electrical failures are rare.

USB transfer types

Control packets
- 10% of the bus is dedicated to control transfers
- control transfers are ACKed by the receiver
- control transfers are retried (but not necessarily in the same frame)
- devices can have control endpoints other than the default endpoint zero
- max payload can be set to either 8, 16, 32, or 64 bytes (full speed)
- transfers don't have to be padded to reach the max payload size
- the data format of the control transfers are defined, with some room for "vendor specific" control messages
- (!) Perhaps the host could send a control transfer to the pyros to fire the parachutes?

Discussion

[Bart] Given that the host must initiate all USB transfers, surely it can more-or-less prioritize the transfers? It seems to me that this is sufficient for our purposes?
- [Sarah]With isochronous and interrupt transfers, each device gets a fixed amount of the USB bandwidth. When a device is enumerated, the host sets the number of frames between polling for each endpoint of the device. This can be 1-255 frames for interrupt transfers; for isochronous transfers, the number of frames between polling is equal to one.
- A frame is about 1ms, and you can transmit up to 1023 bytes with isochronous, and 64 bytes with interrupt.
- Of course, this brings up the question of what happens when you have more than one isochronous device. If each device can potentially transmit 1023 bytes in 1ms, that means the device transmits at about 8Mbps. We can't have more than two devices at that rate with USB 1.1 (since it's 12Mbps). We can't increase the number of frames between polling, so we'd have to allocate less bytes per isochronous transfer at enumeration.
- With interrupt transfers, you can set both the frames between polling and the maximum number of bytes transmitted.
- If necessary, you can reconfigure a device's endpoints to have a different data rate on the fly with a configuration packet. (USB 1.1 spec, 242)
- [Sarah]The host uses the number of frames between polling, along with the maximum number of data bytes an endpoint can send, to set up the sequence of devices to poll to meet the bandwidth requirements. In this sense, you set up device priority by slicing up the bus bandwidth; with CAN, you get a message-by-message priority.
[Jamey] Note that in the existing system, we had ad-hoc mechanisms for switching data rates on some sources -- particularly the accelerometer and gyro samples from the IMU. This was mostly to keep from filling our flash disk while sitting on the ground, but as I recall lower data rates also led to lower power consumption. Using the standard USB "configuration" mechanism instead of ad-hoc CAN messages would be really nice, both for advertising the availability of these data rates (something not supported in our current system, you "just have to know") and for configuring the node for new rates. If examining USB does nothing else for us, it may at least suggest a convenient high-level architecture to impose above whatever bus we do choose.
[Sarah] When initiating a transfer, the USB host controller will wait 18 bit transistions for a response before going on to the next transfer. This means that the node will have to have data ready before the request (ie we can't wait until the request and then go poll a sensor).