Today: Wired embedded networksmy.eng.utah.edu/~cs5785/slides/17.pdfEmbedded vs. TCP/IP ! Many TCP/IP...
Transcript of Today: Wired embedded networksmy.eng.utah.edu/~cs5785/slides/17.pdfEmbedded vs. TCP/IP ! Many TCP/IP...
u Today: Wired embedded networks Ø Characteristics and requirements Ø Some embedded LANs
• SPI • I2C • LIN • Ethernet
u Next lecture: CAN bus u Then: 802.15.4 – wireless embedded network
Network from a High End Car
Embedded Networking u In the non-embedded world TCP/IP over Ethernet,
SONET, WiFi, 3G, etc. dominates
u No single embedded network or network protocol dominates Ø Why not?
Embedded vs. TCP/IP u Many TCP/IP features unnecessary or undesirable in
embedded networks u In embedded networks…
Ø Stream abstraction seldom used • Embedded networks more like UDP than TCP • Why?
Ø Reliability of individual packets is important • As opposed to building reliability with retransmission
Ø No support for fragmentation / reassembly • Why?
Ø No slow-start and other congestion control • Why?
Which is better?
Latency
Latency
Characteristics and Requirements u Determinism more important than latency u Above a certain point throughput is irrelevant u Prioritized network access is useful u Security important only in some situations u Resistance to interference may be important u Reliability is often through redundancy u Cost is a major factor u Often master / slave instead of peer to peer
A Few Embedded Networks u Low-end
Ø SPI Ø I2C Ø LIN Ø RS-232
u Medium-end Ø CAN Ø MOST Ø USB
u High-end Ø Ethernet Ø IEEE-1394 (Firewire) Ø Myrinet
How do you choose one? u Does it give the necessary guarantees in…
Ø Error rate Ø Bandwidth Ø Delivery time – worst case and average case Ø Fault tolerance
u Is it affordable in… Ø PCB area Ø Pins Ø Power and energy Ø $$ for wiring, adapter, transceiver, SW licensing Ø Software resource consumption: RAM, ROM, CPU Ø Software integration and testing effort
Most Basic Embedded Network u “Bit banged” network:
Ø Implemented almost entirely in software Ø Only HW support is GPIO pins Ø Send a bit by writing to output pin Ø Receive a bit by polling a digital input pin
u Can implement an existing protocol or roll your own u Advantages
Ø Cheap Ø Flexible: Support many protocols w/o specific HW support
u Disadvantages Ø Lots of development effort Ø Imposes severe real-time requirements Ø Fast CPU required to support high network speeds
SPI u Serial Peripheral Interface
Ø Say “S-P-I” or “spy” u Characteristics:
Ø Very local area – designed for communicating with other chips on the same PCB • NIC, DAC, flash memory, etc.
Ø Full-duplex Ø Low / medium bandwidth Ø Master / slave
u Very many embedded systems use SPI but it is hidden from outside view
u Originally developed by Motorola Ø Now found on many MCUs
SPI Signals u Four wires:
Ø SCLK – clock Ø SS – slave select Ø MOSI – master-out / slave-in Ø MISO – master-in / slave-out
u Single master / single slave configuration:
Multiple Slaves u Each slave has its own select line:
u Addressing lots of slaves requires lots of I/O pins on the master, or else a demultiplexer
CPOL and CPHA u Clock polarity and clock phase
Ø Both are 1 bit Ø Configurable via device registers
u Determine when: Ø First data bit is driven Ø Remaining data bits are driven Ø Data is sampled
u Details are not that interesting… u However: All nodes must agree on these or else SPI
doesn’t work
SPI Transfer 1. Master selects a slave 2. Transfer begins at the next clock edge 3. Eight bits transferred in each direction 4. Master deselects the slave
u Typical use of SPI from the master side: 1. Configure the SPI interface 2. Write a byte into the SPI data register
Ø This implicitly starts a transfer 3. Wait for transfer to finish by checking SPIF flag 4. Read SPI status register and data register
u Contrast this with a bit-banged SPI
More SPI u SPI is lacking:
Ø Sophisticated addressing Ø Flow control Ø Acknowledgements Ø Error detection / correction
u Practical consequences: Ø Need to build your own higher-level protocols on top of SPI Ø SPI is great for streaming data between a master and a few
slaves Ø Not so good as number of slaves increases Ø Not good when reliability of link might be an issue
I2C u Say “I-squared C”
Ø Short for IIC or Inter-IC bus u Originally developed by Philips for communication
inside a TV set u Main characteristics:
Ø Slow – generally limited to 400 Kbps Ø Max distance ~10 feet
• Longer at slower speeds Ø Supports multiple masters Ø Higher-level bus than SPI
I2C Signals and Addressing u Two wires:
Ø SCL – serial clock Ø SDA – serial data Ø These are kept high by default
u Addressing: Ø Each slave has a 7-bit address
• 16 addresses are reserved • One reserved address is for broadcast • At most 112 slaves can be on a bus
Ø 10-bit extended addressing schemes exist and are supported by some I2C implementations
I2C Transaction u Master issues a START condition
Ø First pulls SDA low, then pulls SCL low u Master writes an address to the bus
Ø Plus a bit indicating whether it wants to read or write Ø Slaves that don’t match address don’t respond Ø A matching slave issues an ACK by pulling down SDA
u Either master or slave transmits one byte Ø Receiver issues an ACK Ø This step may repeat
u Master issues a STOP condition Ø First releases SCL, then releases SDA Ø At this point the bus is free for another transaction
Multiple-Master I2C u One master issues a START
Ø All other masters are considered slaves for that transaction Ø Other masters cannot use the bus until they see a STOP
u What happens if a master misses a START? Ø When a master pulls a wire high, it must check that the wire
actually goes high Ø If not, then someone else is using it – need to back off until
a STOP is seen
LIN Bus u Very simple, slow bus for automotive applications
Ø Master / slave, 20 Kbps maximum Ø Single wire Ø Can be efficiently implemented in software using existing
UARTs, timers, etc. • Target cost $1 per node, vs. $2 per node for CAN
Ethernet u Characteristics
Ø 1500-byte frames Ø Usually full-duplex Ø 48-bit addresses Ø Much more complicated than SPI, I2C Ø Often requires an off-chip Ethernet controller
u Can be used with or without TCP or UDP u Hubs, switches, etc. support large networks u Random exponential backoff has bad real-time
properties Ø No guarantees are possible under contention
Embedded TCP/IP u This is increasing in importance
Ø Remember that TCP/IP can run over any low-level transport • Even I2C or CAN
Ø TCP/IP stacks for very small processors exist u Drawbacks
Ø TCP/IP is very generic – contains features that aren’t needed
Ø TCP/IP targets WANs – makes many design tradeoffs that can be harmful in embedded situations
u Good usage: Car contains a web server that can be used to query mileage, etc.
u Bad usage: Engine controller and fuel injector talk using TCP/IP
Summary u Embedded networks
Ø Usually packet based Ø Usually accessed using low-level interfaces
u SPI, I2C Ø Simple and cheap Ø Often used for an MCU to talk to non-MCU devices
u CAN Ø Real-time, fault tolerant LAN
u Ethernet Ø More often used for communication between MCUs
u Subsequent lectures: Ø CAN bus Ø 802.15.4 – low-power wireless embedded networking