CSCI1600: Embedded and
Real Time Software
Lecture 22: Networking, IPC
Steven Reiss, Fall 2015
Interprocess Comunication
 Multiple tasks need to communicate
 We’ve covered shared memory
 Using synchronization where necessary
 When is synchronization necessary?
 What other means are there?
Semaphores
 We saw semaphores as a synchronization mechanism
 Protect a synchronized region
 Protect a set of resources
 Protect a producer-consumer queue
 They can also be used for communication
 When the amount of information is small
 Flag to let another task run
Is This Sufficient?
 Semaphores are low level and error-prone
 Getting communications and synchronization right
 Can be tricky
 Can lead to hard to find and replicate problems
 Higher level abstractions can be easier to use
 And can be supported by a RT operating system
 What abstractions are appropriate?
Mailboxes
 What it is
 A synchronized holder for a single message
 Operations
 create – initialize a mailbox structure
 accept – takes in a message
 pend – waits for a message
 post – sends a message
 Messages
 void * (arbitrary pointer)
Mailbox Implementation
 Mutex for operations
 Create: set up everything, empty mailbox
 Accept: check if mailbox is empty, if not, emtpy it
 Pend:
 Wait until the mailbox is non-empty
 Put task on wait queue for mailbox
 Then get message and return it
 Conflicts can be FIFO, priority-based, random
Mailbox Implementation
 Post:
 If queued tasks, find proper waiter and remove from queue
 Insert message into mailbox
 Let that task continue
 Else if there already is a message, return error
 Else save message and return
 Note that all operations are synchronized appropriately
 What mailboxes can’t do
 Multiple messages (but can prioritize)
 Blocking on post
Message Queues
 Similar to mailboxes
 Differences
 More than one message at a time
 Can be dynamic or fixed maximum sized
 Block on send
 At least optionally
Message Queue Implementation
 What does this look like
 Synchronized producer consumer queue
 Handling multiple readers and writers
 What this doesn’t handle
 Variable sized messages
 Communication without shared memory
Pipes
 Similar to message queues except
 Handle varying sized messages
 May be entirely byte oriented
 May take <length,data> for messages
 Can work across processes if messages lack pointers
 Can work across machines
 But have to be wary of endian problems
Higher Level Abstractions
 Imply higher level bugs
 Bugs are less likely to be synchronization related
 Data-oriented problems to watch out for
 Using the wrong queue/pipe/mailbox
 Misinterpreting the passed data
 “Ownership” of passed pointers
 Wanting to ignore duplicate messages
Wider Scale Communications
 Might want to do more
 Communicate between processes
 Communicate between devices (e.g. in a car)
 Means for doing so
 Attached devices: point-to-point communication
 Busses
 Ethernet: MAC (Media Access Control), UDP
 Ethernet: TCP, IP
Commonalities
 Framing: putting messages together
 Error detection
 Flow control
 Reliability and guarantees
 Bus “arbitrarion” / MAC protocols
Internetworking
 Embedded web server interface
 IP cameras, switches, …
 Post information to a server
 Sensors, …
 Data from network shares
 Music player, web radio
 Act as browsible share (TiVo)
 Home automation, VoIP, alarms
Internetworking
 UDP (covered in CSCI1680)
 Not very different from interacting with a bus
 Best effort delivery (no reliability guarantees, acks)
 You manage retries, assembly/dissembly, congestion
 Good for sensor updates, etc.
 TCP/IP
 Similar to a IPC pipe
 Adds reliability, byte stream interface
 Internally manages retries, ordering, etc.
 Web services, simple APIs
TCP/IP

Sockets are like 2-way pipes
 Both sides can read/write independently

Sockets are address by host-port

Connection to a socket
 Create socket on the server
 Bind it to a known port (on the known host)
 Do an accept on the socket
 Create a socket on the client
 Connect to know server socket (connect) operation
 Server does accept on its socket
 This yields a new socket bound to that client
TCP/IP
 Lightweight implementation exist (even for Arduino)
 Library interface for lwIP (Light Weight IP)
 ip_input(pbuf,netif)
 Takes an IP package and the network interface as args
 Does TCP/IP processing for the packet
 tcp_tmr()
 Should be called every 100ms
 Does all TCP timer-base processing such as retransmission
 Event-based callbacks
 This is not sockets, but it is TCP/IP
lwIP Basics
 Initialization: tcp_init
 Manage all TCP connections
 tcp_tmr()
 Must be called every 250 milliseconds
 sys_check_timeout()
 Calls tcp_tmr and other network related timers
lwIP Server Connection
 tcp_new : create a PCB for a new socket
 tcp_bind : bind that socket to a port on this host
 tcp_listen : listen for connections
 tcp_accept : specify a callback to call
 Passed routine called when someone tries to connect
 tcp_accepted : called from the routine to accept the
connection
lwIP Client Connection
 tcp_new : create new PCB (socket)
 tcp_bind : bind the socket to target host/port
 tcp_connect : establish the connection
 Provides callback function
 Called when connected
 Or if there is an error in the connection
lwIP Sending Data
 tcp_sent : specify callback function
 Called when data acknowledged by remote host
 tcp_sndbuf : get maximum data that can be sent
 tcp_write : enqueues the data for write
 Can be via copy or in-place
 tcp_output : forces data to be sent
lwIP Receiving Data
 tcp_recv : specifies a callback function
 Function called when data is received
 Or when there is an error (connection closed)
 Calls tcp_recved to acknowledge the data
lwIP Other Functions
 tcp_poll : handle idle connections
 tcp_close : close a connnection
 tcp_abort : forcibly close a connection
 tcp_err : register an error handling callback
Simple Web Server
 Assuming the host IP is known
 Create a server socket on port 80
 Listen for connections
 Read message from connection
 Should be header + body
 Simple message = header only
 Decode header, branch on URL
 Compute output page
 Send reply on the connection
 HTTP header + HTML body
Simple Web Communicator
 To send periodic updates
 Put together a message
 Simple HTTP header
 URL using ?x=v1&y=v2 to encode data
 Connect to <SERVER HOST:80>
 Send the message
 Close connection
Simple Server Communicator
 Use arbitrary message format
 Use arbitrary host/port for the server
 Send and receive messages in that format
Homework
 Read 12.1 – 12.2
Point-to-Point Framing
 Sentinals
 Special bytes at beginning and end of message
 Escaped when inside a packet
 Length counts
 Encode length of the packets explicitly
 Bit errors may introduce big mistages
 Clock-based
 Each frame is t microseconds long
 Keep clocks synchronized with transitions
Example: RS232 Serial Ports
 Many variants exist, 2 wire is simplest
 A byte is encoded as 0bbbbbbbb1 (10 bits per byte)
 bbbbbbbb is LSB first
 Leave TX asserted until next byte
 Software flow control: XON, XOFF
 Hardware flow control
 Two extra wires: RTS, CTS
MACs and Arbitration
 Time based
 Devices work out which uses the medium
 Bus arbitration
 MAC protocols
What is a bus
 System lines
 Includes clock and reset
 Address and data
 32 time mux lines for address and data
 Interrupt and validate lines
 Arbitration
 Not shared
 Controlled by PCI bus arbiter
 Error lines
PCI Bus Arbitrarion
 Four interrupt lines, rotated per device
 Level triggered interrupts
 Hard to miss
 Hard to share
 Shared 33.33Mhz clock
 32 bit width => 133MB max transfer speed
PCI Bus Arbitration
 Bus master holds the right to use the bus at any time
 Different strategies can be used to assign the master
 Daisy chain (round robin) – each gets a turn
 Independent requests
 Each device has its own signal it can send to controller
 Polling
 Controller counts through all devices
 Device raises a flag when it wants to communicate
Programmed I/O vs DMA
 CPU – MEMORY also has a bus
 With address lines
 With data lines
 With control lines (IRQ, NMI, VMA, R/W, BUS, RESET)
 Read/Write to memory
 Sets address lines
 Reads/writes using data lines
 BUS, R/W lines indicate when to read/write
 Enable lines on devices wired directly to appropriate memory
 Based on high order lines and low order lines
Ethernet Framing
 Carrier sense multiple access with collision detection
 If line is idle
 Send immediately with fixed max frame size
 Wait 9.6 microseconds between back-to-back frames
 If line is busy
 Wait until idle and transmit immediately
 If collision occurs
 Jam for 32 bits, then stop transmitting
 Delay (random exponential backoff) and try again
Sample Code – Main Loop
for ( ; ; ) {
if (poll_driver(netif) == PACKET_READY) {
pbuf = get_packet(netif);
ip_input(pbuf,netif);
}
if (clock() – last_time >= 100 * CLOCK_MS) {
tcp_tmr();
last_time = clock();
}
}
Sample Code: Minimal Server
main() {
http_accept(void * arg,struct
tcp_pcb * pcb) {
struct tcp_pcb * pcb
tcp_recv(pcb,http_recv,NULL);
tcp_tcb_new();
tcp_bind(pcb,NULL,80);
}
tcp_listen(pcb);
tcp_accept(pcb,http_accept,NULL); http_recv(void * arg,
/* main loop */
struct tcp_pcb *pcb,struct pbuf * p) {
// do something with packet p
}
}