Round Trip

CSE466 Lab 7

Specifications

We will implement a symmetrical protocol (credit Doubleday). That is, the host and the player are not different from each other. We could hook a host to a host, or a player to a player, and the communications should proceed (almost) smoothly. In all cases, the two connected devices will take turns sending a byte of data. The pilot goes first.

The device (pilot or player) can be in one of two modes: In data mode (D), the device is expecting to receive song data; in command (C) mode the device is expecting to receive single byte commands. The device enters command mode upon reset. The following table shows exactly what (binary not HEX) bytes should be sent by each device depending on mode of the sender and receiver:

Device 1 Mode Device 2 Mode On its turn, Device 1 Sends On its turn, Device 2 Sends Comments
C C [S|T|C|0] [S|T|C|0] [S|T] causes receiver to enter D mode

C means Clear buffer (abort) and 0 means do nothing. Neither of these will cause the receiver to change modes.
C D [S|T|C|0] [Song Byte|0] Null (0) bytes can only be inserted between packets in song data, so the sender must make sure that the data queue has at least one complete packet before sending the first byte of the packet. Header data never has any binary zeros, so nulls can be inserted anywhere in a header. Nulls do not cause the receiver to change mode.

Only an end of song packet will cause the receiver to return to C mode.

D C [Song|0] [S|T|C|0] Since null is equivalent to pause,  there is no need to return to C mode during a pause and we don't need another opcode for pause.
D D [Song|0] [Song|0]

When the device issues an 'S' command, only music data will follow (TEMPO,PACKETS). When the device issues a 'T' command, song data will follow (DST,LEN,HEADER,TEMPO,PACKETS). The only difference between a player the pilot is that the player will never issue a 'S' command, and the pilot always starts the protocol, that is, the player does nothing until receiving a byte from the pilot.

For Lab:

  1. Implement two queues: send and receive. The send queue holds data coming from the pilot for streaming or transmitting to another player, while the receive queue holds data coming in from the network for upload to the pilot.
  2. Simulate the existence of the network by putting a song into ROM that includes a test header. Write a dummy network interface task that continuously reads data out of ROM and places it into a receive queue. The dummy task should do a "wait" when that queue is full.
  3. Slightly modify the protocol above to handle this case: the send queue and receive queue are both full. How can this happen? Is there a deadlock potential here? how can the protocol be modified to solve this problem?
  4. Implement the modified protocol on your pilot and on your player. The SERIAL task should be able to manage the protocol by examining the states of the various queues. The serial interface should be interrupt driven on the player.
  5. Any songs received by the pilot should be added to the database. The user should be able to delete, play, or send songs.
  6. Any songs transmitted to the player by the pilot can be placed in the bit-bucket by the player, but the protocol should continue to work.

Write Up

  1. Demonstrate your system, showing the four possible state combinations
  2. Update your interrupt latency and deadline analysis to account for any changes you have made to the system since Lab 5.
  3. Provide a detailed account of all RAM usage, including OS overhead, worst case stack, queues, variables, etc.
  4. Answer the questions in part 3 above and document your protocol modifications.
  5. Documented Source Code for player and pilot