CMPE 401 - Laboratory #3 hints

• Specification clarifications:
  • Your LED support must be task-based. In other words, your implementation of the LED support in both exercise 2 and 3 must make use of queues and tasks in the same way that Lab #1 and Lab #2 did.
  • Global space may be used for large array allocations in this lab for space reasons. If the linker complains about region X being full, try moving the allocations of the array to a different region. Ask me for more details if necessary.
• Adding LED Display support for the lab:
  • You must add the shift_reg.o object file to the list of object files included in the LAB3OBJS variable
  • You must add a makefile command to assemble the shift_reg.s file into a shift_reg.o file. Use the Lab1 or Lab2 Makefile as an example on how to do this.
  • You must add a global variable to hold the head of the LEDQueue into the global variable section in lab3.c
  • You must allocate storage, create the LEDQueue, initialize the shift register, and create the LEDDisplayTask in the StartTask in lab3.c. Use the Lab #1 or Lab #2 code as your example.
  • Use the model of the LEDDisplayTask in Lab #1 and Lab #2, and adapt to the specifications on this lab. Remember that passing a zero through the LEDQueue is not permitted. There are many ways to deal with the null pointer problem. All are acceptable as long as the LEDQueue and Task method of displaying the toggling LEDS is used.
  • Use the #defines in the lab3.h file to choose a priority for the LEDDisplayTask. In this lab the priority is automatically set to the TaskId + 5. See the TaskCreate function in lab3.c
• The newlib standard c library is available for your use. The functions that you can use are limited to non-operating system reliant calls. That means that if it compiles and links then you can use it. So functions like strlen, strcat, strncat, strtok,strcpy, memcpy, etc. are available. The documentation on the newlib library is here. Once you open the pdf, search for the function you want to use. Under portability it will list the supporting OS subroutines that it requires. You can use any routines that say "X requires no supporting OS subroutines".
• To verify the TCP/IP packet information, I have written a script called capture_serial. It is located in /usr/local/bin/ on all of the lab machines. You'll require sudo to use it. Type sudo capture_serial to generate the capture file. It currently stores it to /tmp/output.pcap. After running the script for 60 seconds (default) or killing it with control-c, you can launch wireshark to open it and view the resulting capture. Run Wireshark and open the output.pcap file. You'll see all of the info about the data that passed over the slip interface during the capture. Note that if there is no traffic on the sl0 interface the script never terminates due to a known bug in libpcap. Simply type control-c to kill it. If the slip interface is not up, the script returns immediately without capturing anything. Wireshark is in the XFCE menu under Network. Choose the regular Wireshark. Wireshark is located in /usr/bin. I will be using it to verify your port numbers during the demo.
• To see what to expect from the time connection to the Ubuntu box on port 13, type: telnet localhost 13 in any terminal window in the e5-02 lab.
• If starting up slip generates the following error

  nem@e5-02-01:~/cmpe401/fall2007/labs/lab3$ sudo slipup
  SLIP_set_disc(1): File exists
  SIOCSIFADDR: No such device
  sl0: ERROR while getting interface flags: No such device
  SIOCSIFDSTADDR: No such device
  sl0: ERROR while getting interface flags: No such device
  SIOCSIFNETMASK: No such device
  SLIP is now up
  

  Simply restart it again and the error should go away. This is due to a known kernel bug in ubuntu 7.04's kernel.
• The lwip API documentation has errors in it. Check the source code in src/lwip to verify the API calls if compiling them generates errors.
• During the demo I will only be using the telnet/firefox interfaces to evaluate your solution. Use the minicom window output for debugging only.