CSE466 Lab 8, Smoke Signals

Introduction

The main purpose of this lab is to implement and test the physical layer of  an I2C embedded network. Theodora has built and tested an I2C network with two 8051 systems, each hooked to a hyperterm window. Users at each window can send short messages to the each other via the I2C connection between them. Your system will be tested by connecting it to the Theodora's bus and and to a third hyperterm window. You must demonstrate that your systems can exchange messages with the other two without interfering with transmissions between the other two.

The user interface is very simple. To send a message type

<destination address>:<message><\n>

For example, if the user of device number 2 types

> 1:I love cse466!

followed by a carriage return, then system 2 should send a binary 2, followed by the sequence of ascii bytes "I love cse466!" to the system w/ address 1 on the network. Note that the binary 2 is part of the data message as far as the I2C bus in concerned.  Upon receipt of this message, system number 1 should display the string "2: I love cse466!" on its hyperterm display. Make sure to echo any characters that are typed by the user.

For this week, send the whole message as single frame on the bus. You must support messages up to 25 characters, including the byte for the sender's address. Please follow these rules of etiquette:  

• Make your system's I2C address programmable from the UI. maybe that's the first character that the user types. The user interface for that is up to you. No reason to hard-code the device addresses.
• The sender should not attempt to master the bus until the user hits return so that you don't hold the bus busy while the user scratches her head. Once the user hits enter, the sender should attempt to become bus master and send the message until it is successful. 
• The receiver should receive the entire frame before printing it to the display, so that you don't hold the bus busy while doing serial I/O. 
• Make sure to echo the characters that are typed by the user
• Configure your system to run the I2C bus at approximately 45KHz (see the device data sheet for more details).

Implementation Notes:

• You do not have to use Tiny for this assignment. 
• You can poll the serial port for user input if you want (interrupts are preferred), but you must use interrupts to respond to I2C events that set PIN to 0 (for instance, completion of a byte transfer as master or slave). Make sure to setup the bus controller to give you an interrupt signal, it won't do it by default.
• Note that the flow diagrams in the datasheet assume polling, so think about how they would be slightly different for interrupt driven approaches (it explains the part about reading the slave address from the S0 register that I wasn't sure about in lecture).
• Before testing with Theodora's system or anyone else's, use a scope to make sure that your bus interface generates expected SCL and SDA signals as bus master. To see signals on SCL and SCA you will need to add pull-up resistors to those pins on the bus controller. I think ~20KOhms is fine.
• Make sure to have a common ground between all systems on a network during testing. And, make sure to have only one set of pull-up resistors on the bus lines at a time.
• You will have to use an 11MHz crystal that we will give you. Don't forget to change the reload value for timer 1 to generate the correct baud rate. At 11MHz crystal a reload value of 253 generates 9600 baud.
• Don't forget to buffer the clock signal from CK2 of the 8051 to the CLK input of the 8584. Use a 74HCT00 that we will give you for this.

Turn In:

• Source Code
• Plot overhead/bit v. message length for messages ranging from 2 to 25 bytes. Overhead is the amount of time per bit over and above the time that would be required to transmit the message at the bus clock rate (45KHz).  Don't rely on Theodora's system to do this analysis. Find another group with a working system to experiment with.