CMPE 401 - Computer Interfacing

Assignment #2

Model Solutions

 

  1. In the context of the RS-232 serial communications, briefly explain what is meant by a "null modem". Many point-to-point wireline communications standards (e.g. RS-232 and USB) are asymmetrical with respect to the connector types used at either end of the communications medium. In such standards, when is it necessary to have null modems? How could one design a new point-to-point communications standard that avoids the need for null modem connections?

 

For RS-232, a null modem takes the place of two Data Communication Equipment (DCE) devices along with the transmission line, and:

·         Crosses over the data lines such that outputs go to inputs (e.g. RX to TX)

·         Allows two Data Terminal Equipment (DTE) devices with male DB-9 connectors to interface directly to one another

 

For systems utilizing asymmetrical connectors, null modems are necessary when one host (or slave) device is required to communicate directly with another.  In order to avoid the use of null modems, the following could be done:

·         Building in the cross-over into all cables (i.e. identical connectors and pin-outs for host and slave devices)

·         Where appropriate, the use of a backplane bus (e.g. the PCI bus) with a standard connector and on-board routing of signals

·         The use of bi-directional communications lines (e.g. I2C), where the same line is used for both transmitting and receiving, reduces wire count and the need for cross-over connections

 

  1. Consult the on-line documentation or the course textbook, and then briefly explain how the T1 and T0 trace mode bits in the status register work. In your answer be sure to highlight the difference between the two trace modes. Why were both modes provided in the CPU32 microprocessor?

 

The two trace bits are present in the status register and can be set only in supervisor mode.  Setting T1 (SR[15]) causes a trace exception after every single instruction, while setting T0 (SR[14]) causes a trace exception only when a change of flow occurs.  This includes branching (taking of a branch with Bcc, or a BRA or JMP instruction), traps, and going to (BSR, JSR) and returning from subroutines or exceptions (RTx).  Setting both T1 and T0 is an undefined state.

 

T1 was provided to allow for higher-level debugging (ignoring the sequential operation of the program and stopping only at ‘decision points’ or exceptions and interrupts), while T0 allows for lower-level debugging, stopping after every instruction.


  1. Consult the on-line documentation or the course textbook, and then briefly describe the three CMPU32 return instructions, namely, RTS (return from subroutine), RTR (return and restore CCR), and RTD (return and de-allocate). What previous stack operations should have been performed before (not necessarily immediately before) each of these return instructions is executed?

 

Before any of the return instructions can be used, the stack must be restored to the condition that the subroutine began with.  Any stack space used by the subroutine must be de-allocated, leaving the return address (and an extra word for RTD) at the top of the stack

·        RTS – (ReTurn from Subroutine) restores the program counter by popping the top two words from the stack and loading them into the PC

·        RTR – (ReTurn and Restore condition codes) assumes that the status register was saved by the subroutine to the top of the stack, and restores the CCR by popping a word from the stack and loading the CCR portion back into the status register.  It then pops another two words from the stack and restores the program counter

·        RTD – (ReTurn and Deallocate) also restores the program counter by popping the top two words on the stack and loading them into the PC, but further increments the stack pointer by adding a 16-bit displacement to the stack pointer (useful for deallocating data passed to the subroutine via the stack)

 

  1. In the lectures we discussed the various reasons why communications interfaces are layered. In you own words, summarize those advantages. Why do you suppose that it is generally best to access an interface at the highest possible layer? What would be a good reason for accessing a communications interface at a lower than usual layer?

 

Layering helps manage the complexity present in many modern communication interfaces.  The modular design of the individual layers helps to simplify the design of communications schemes, and allows each layer to be specified, designed, and implemented more easily than a monolithic protocol.  The modularity also allows each layer to be modified or reworked without affecting other layers.  Layering also helps with application development as many of the layers have known good implementations which can be used and built upon.

 

Generally, it is good to access a communications interface at the highest possible level as this will be higher-level (in terms of built-in handling and abstraction) than a lower layer, and thus easier to deal with.  In spite of this, accessing at a lower level might be done to cut down on the overhead created by headers/trailers introduced by the different layers and to build in extra functionality or redefine features found in higher levels (e.g. VoIP which uses UDP packets, possesses more robust error correction than TCP and stronger packet ordering ability).  Accessing at lower levels may also allow for encapsulation and optimization of functions provided in higher levels and increased efficiency (e.g. LwIP).


  1. The Internetworking Protocol (IP) has the right to split up (i.e. to segment) TCP datagrams into smaller packets as required. What major steps would be required to take one TCP segment, split it up, and then produce two shorter (and yet still legal) IP datagrams? Then explain what the major steps would be required in re-assembling two IP datagrams into one longer IP datagram that contains the same data as in the original two datagrams. Be sure to mention any situation that might prevent make datagram re-assembly impossible.

 

In order to split a packet, IP would need to:

·        Split the entire TCP packet into two, and attach headers to both

·        Calculate the total byte size of both packets and place in total length fields

·        Set the more fragments (MF) flag of the first packet and clear it in the second packet

·        Set the fragment offsets of the two packets (0 in the first and the byte number of the first data byte in the second)

·        Calculate the checksums over the header and place in the checksum fields

 

To create an IP datagram from two IP datagram fragments:

·        Calculate the checksum of the two headers and req. retransmit if necessary

·        Ensure that the two packets are sequential (the fragment offset of one is the fragment offset of the other + the total length – the header length)

·        Set the MF flag of the first packet the same as that of the second

·        Strip the header of the second and append the data from the second packet to end of the first

·        Calculate the total length of the combined packet and use it in the header

·        Calculate the new header checksum and use it in the header

·        Retain all else from the first packet header

Datagram reassembly may be impossible if packets are lost, corrupted, or if the reassembled packet exceeds the maximum allowed size (2^16, or 65535 bytes)

 

  1. Briefly explain how the architecture of the lightweight IP (lwIP) stack promotes portability across both processors and operating systems.

 

The core implementation of the TCP/IP stack of LwIP (the LwIP process) is written in standard ANSI C, and is kernel and OS independent (and thus easily portable).  It is also written to be as small, and have as small of a memory footprint, as possible so that it can fit on many processors.  Breaking strict layering allows the LwIP stack to be more efficient and compact. 

 

The core LwIP kernel offers “insulated” access from all sides (application, operating system and network hardware).  Applications only access the stack through a simplified API.  The Operating System Emulation layer keeps OS specific functions together, and allows for the optimization of LwIP, but must be rewritten for each OS.  LwIP access the network hardware only via device drivers (which must be tailored to LwIP).