Basic i50Phone

1. Basic i50Phone EECS150 Fall 2007 - Lab Lecture #10 Allen Lee EECS150 Lab Lecture #10

2. Example MyTeam UsrName1 UsrName2 UsrName3 M S 10 EECS150 Lab Lecture #10

3. Example MyTeam UsrName1 UsrName2 UsrName3 UsrName4 Dialing User: UsrName2 Cancel(B) M S 10 EECS150 Lab Lecture #10

4. Example MyTeam UsrName1 UsrName2 UsrName3 UsrName4 Dialing User: UsrName2 Cancel(B) User Unavailable M S 10 EECS150 Lab Lecture #10

5. Example MyTeam UsrName1 UsrName2 UsrName3 UsrName4 Dialing User: UsrName2 Cancel(B) User Unavailable Dialing User: UsrName3 Cancel(B) M S 10 EECS150 Lab Lecture #10

6. Example MyTeam UsrName1 UsrName3 UsrName2 UsrName3 UsrName4 Dialing User: UsrName2 Cancel(B) User Unavailable Dialing User: UsrName3 Cancel(B) Connection Established M S 10 EECS150 Lab Lecture #10

7. Example MyTeam UsrName3 UsrName2 UsrName3 UsrName4 Dialing User: UsrName2 Cancel(B) User Unavailable Dialing User: UsrName3 Cancel(B) Connection Established Connection Terminated M S 10 EECS150 Lab Lecture #10

8. Example MyTeam UsrName2 UsrName3 UsrName4 Dialing User: UsrName2 Cancel(B) User Unavailable Dialing User: UsrName3 Cancel(B) Connection Established Connection Terminated M S 10 EECS150 Lab Lecture #10

9. Example MyTeam UsrName2 UsrName3 UsrName4 User Unavailable Dialing User: UsrName3 Cancel(B) Connection Established Connection Terminated Call From: UsrName4 Acc(A)/Rej(B) M S 10 EECS150 Lab Lecture #10

10. Example MyTeam UsrName4 UsrName2 UsrName3 UsrName4 Dialing User: UsrName3 Cancel(B) Connection Established Connection Terminated Call From: UsrName4 Acc(A)/Rej(B) Connection Established M S 10 EECS150 Lab Lecture #10

11. Overview • Introduction to Checkpoint 4 • Adding to Checkpoint 1 • Adding to Checkpoint 2 • Communications protocol • Advice • Extra Credit EECS150 Lab Lecture #10

12. Checkpoint 4 = Everything in this circle Checkpoint 4 (Communications and Registry) EECS150 Lab Lecture #10

13. Checkpoint 4 Additions EECS150 Lab Lecture #10

14. Adding to Checkpoint 1 • Audio Buffer • Previously stored all audio data into one huge FIFO and local playback. • Must now support sending and receiving audio data from transceiver. • AC97 Controller • Remains the same • Volume and Mute signals now come from user input module in CP2. EECS150 Lab Lecture #10

15. Old Audio Buffer • Data output from FIFO goes back to Audio controller: EECS150 Lab Lecture #10

16. New Audio Buffer • Must now support sending and receiving from wireless transceiver: EECS150 Lab Lecture #10

17. Adding to Checkpoint 2 • User Input Parser • Keep track of a cursor position (0 through 7) for each of the top two regions. • Only allow the cursor of a particular region to change when the focus is on that region. • When the cursor is on a valid user in the Channel region, and “A” is pressed: • Change the focus to the console. • Send a call request, and wait for a response. • Press “B” to cancel the request and change focus to Channel region. • Ignore incoming calls while requesting a call. • When a connection established or refused, change focus to Channel region. EECS150 Lab Lecture #10

18. Adding to Checkpoint 2 • User Input Parser (cont’d) • When the cursor is on a valid user in the “Connection” region, and “B” is pressed: • Send a disconnect signal • Focus remains in “Connection” region • When there is an incoming call and you are not requesting a call: • Change focus to console • Press “A” to accept, or “B” to reject • In either case, return focus to “Channel” EECS150 Lab Lecture #10

19. Adding to Checkpoint 2 • Video Display • Support a registry that stores up to 8 users in the channel and 8 connected users. • New users may arrive in the Channel at any time. • Support disconnecting from a connected user. • Don’t worry about supporting more than 8 users. • Remove users that timeout (more on this later). • Store and display appropriate console messages (use RAM for this). • Console must display up to 8 lines of 32 characters each. • Once console fills up, each new message should push the oldest one out. EECS150 Lab Lecture #10

20. Announcements • Checkpoint 3 is due in two weeks • Week of 11/12 • Checkpoint 4 is due in four weeks • Week of 11/26 • Checkpoint 4 design reviews next week. EECS150 Lab Lecture #10

21. Announcements • Each group should have been assigned a channel during lab last week. • Don’t continuously spam your channel. • Another group is sharing your channel. • Guaranteed your channel during your lab section. • Channel assignments will be posted this weekend. EECS150 Lab Lecture #10

22. Announcements • Clarification for Checkpoint 3 • BigOut and BigIn should be 328 bits (41-bytes), not 320 bits (40-bytes). • An updated version of the checkpoint has been uploaded. EECS150 Lab Lecture #10

23. Announcements • Midterms have been graded • Pick them up after lab lecture. EECS150 Lab Lecture #10

24. Communications Module • Responsibilities • Announce presence every 250 ms. • Initiate a call with another station. • Acknowledge a call request. • Reject a call request. • Receive audio data. EECS150 Lab Lecture #10

25. Packet Format • The 41-byte payload from Checkpoint 3 belongs to the “application layer” • 1-byte header • 40-byte payload EECS150 Lab Lecture #10

26. Packet Format EECS150 Lab Lecture #10

27. Packet Types • Announce • Broadcast (0xFF) an announcement packet containing your user name every 250 ms. • Init Call • You want to initiate a call request to someone specific. • Ack Init • Acknowledge that you received an init call request, but neither accept nor reject. • Accept Call • Accept a call request EECS150 Lab Lecture #10

28. Packet Types • Reject Call • Reject a call request • Data • Payload contains audio data • Ready • Acknowledge an accept call. • Used to keep an active connection alive when no data is being sent. EECS150 Lab Lecture #10

29. Communications Behavior • Sit idle and receive packets by default. • Send an Announce packet every 250 ms. • If received packet is an Announce packet, notify Video Display. • If you initiate a call request, send an Init Call packet and wait for acknowledgement. • Keep exchanging Init Call/Ack Init until one of the following happens • Connection times out. • Accept Call packet is received, establish chat. • Reject Call packet is received, return to idle state. • You press Cancel. • No need to send Announce packets during Init Call/Ack Init exchange EECS150 Lab Lecture #10

30. Communications Behavior • During a call, perform the following: • Receive audio data and Ready packets. • Reset timeout counter. • Send audio data whenever it is ready. • Receive Announce packets and notify Video Display. • Optionally send Ready packets to keep the connection alive in the absence of audio data. • Return to idle receive state if: • Neither audio data nor Ready is received in 1 second. • You manually disconnect the call. • No need to send Announce packets during a call. EECS150 Lab Lecture #10

31. Communications Behavior EECS150 Lab Lecture #10

32. Communications Behavior EECS150 Lab Lecture #10

33. Tips, Hints, & Common Pitfalls • Start early • If you’re already done with CP3, start designing now! • We are not providing skeleton Verilog files • Run the TA solution to see what the final result should look like. EECS150 Lab Lecture #10

34. Tips, Hints, & Common Pitfalls • Split up the checkpoint to work in parallel with your partner: • User input parser can be fully tested independently without Video Display or Communications. • Video Display can be fully tested with a simple user input parser and no Communications. • Communications module can be fully tested in ModelSim without the user input parser or video display. • Do not combine until you’ve verified each part works independently. • It can take up to 50 minutes to push to board after combining! EECS150 Lab Lecture #10

35. Tips, Hints, & Common Pitfalls • Reset is unreliable if N64 controller is unplugged (unknown button status is returned). • Even if N64 controller is plugged in, the user input parser may still enter an unpredictable state upon Reset. • Output the current state of the parser somewhere and keep resetting until it enters the correct state. EECS150 Lab Lecture #10

36. Requirements • Support persistent two-way communication between two stations. • Need not be compatible with TA solution • Single bit file • Latency between speaking into microphone and hearing on remote station must be less than 1 second. EECS150 Lab Lecture #10

37. Extra Credit • Maximum 20% • Some Ideas (Exact % TBD): • Text messaging • Talk with more than 1 person simultaneously • Audio effects (e.g. reverberations) • Using the console region for a shared game (e.g. Pong, Tetris, Guitar Hero) • Send video • Record and playback a long conversation using SDRAM • Ring tones • Open-ended! Come up with something special, cool, clever, unique, and/or challenging. EECS150 Lab Lecture #10

38. Stay Tuned… • The spec has not been finalized yet. • It should be up by later tonight. • There is enough information in these lecture slides to get you started. EECS150 Lab Lecture #10

39. Questions? EECS150 Lab Lecture #10