CSCI1600: Embedded and Real Time Software Lecture 9: Input Output Concepts Steven Reiss, Fall 2015.
CSCI1600: Embedded and Real Time Software Lecture 22: Networking, IPC Steven Reiss, Fall 2015.
-
Upload
bryan-watkins -
Category
Documents
-
view
227 -
download
2
Transcript of CSCI1600: Embedded and Real Time Software Lecture 22: Networking, IPC Steven Reiss, Fall 2015.
CSCI1600: Embedded and Real Time SoftwareLecture 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 Loopfor ( ; ; ) {
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 Servermain() {
struct tcp_pcb * pcb
tcp_tcb_new();
tcp_bind(pcb,NULL,80);
tcp_listen(pcb);
tcp_accept(pcb,http_accept,NULL);
/* main loop */
}
http_accept(void * arg,struct
tcp_pcb * pcb) {
tcp_recv(pcb,http_recv,NULL);
}
http_recv(void * arg,
struct tcp_pcb *pcb,struct pbuf * p) {
// do something with packet p
}