ECEN 4623/5623

Assignment #3 -- Device Interfaces

Format: Plain text, Rich text, PDF, or MS Word

Code Format: Turn in all code in a tar or zip file!

Upon Completion upload to culearn.colorado.edu, "Lab Assignments, Lab 3".

(If there is a problem with culearn, then E-mail to siewerts@colorado.edu with subject line "LAB SUBMISSION 3" (subject line must be all caps exactly as it appears between quotes) and CC the TA.)

Be sure to include all source code with your submission.

All Extended Lab Design Assignments should be submitted to culearn.

(If there is a problem with culearn, then E-mail siewerts@colorado.edu with subject "EXTENDED LAB 5623")

Extended Lab updates and submissions should be in an MS Word or text document with names of participants clearly identified on a cover page! Only ONE submission needs to be made for partners working together.

Problem 1 [10 pts] -- Read the paper "Architecture of the Space Shuttle Primary Avionics Software System", by Gene Carlow and provide an explanation and critique of the frequency executive architecture. What advantages and disadvantages does the frequency executive have compared to a threading/tasking model for real-time services. Please be specific about the advantages and disadvantages.

Problem 1b [10 pts EXTRA CREDIT] -- Read the paper "Measuring Latency for Video Surveillance Systems", by Rhys Hill, Christopher Madden, et al, and provide an explanation and critique of their methods for comparing latency of CCTV/NTSC analog cameras and digital. What advantages and disadvantages do you see comparing analog and digital cameras for real-time surveillance systems? Please be specific about the advantages and disadvantages.

Problem 2 [20 pts] -- Read the following chapters in "Linux Device Drivers, 3rd Edition" by Jonathan Corbet, Alessandro Rubini and Greg Kroah-Hartman: 1, 2, 3, 4, & 13. This should give you a good overview of Linux "char" drivers and how to write kernel device driver code along with an introduction to USB devices. Plug at least one USB device into your Ubuntu host system (e.g. Logitech C200 USB camera). As described in Chapter 13 on USB devices, first on your Ubuntu host, explore /sys/devices/pci0000:00/ looking at each and every subdirectory and find all "usb" subdirectories. You should find "idVendor" and "idProduct". Verify that these IDs are correct for what you physically have connected to your system by cross checking with http://www.linux-usb.org/usb.ids and provide the output you see from a "cat" of these two files along with annotation to identify the device. Now do "lsusb" and verify that you see the same information and once again provide the output annotated to identify the USB test device you have been using. Unplug the device used for this exercise from you Ubuntu system and now plug it into your Beagle xM. On the Beagle xM, use "lsusb" to list devices and verify that you can see the same device on your target system. Provide the output from the Beagle xM serial or SSH console, again annotated. The Beagle xM does not have the same sys file system entries that Ubuntu has, why not?

Problem 3 [Extra Credit - 20 pts] -- Write a Linux kernel module for the Beagle xM that can provide output via printk to "dmesg" that identifies all USB devices attached to your Beagle xM. Provide the dmesg output showing this works and compare to "lsusb". Now, add a set of "char driver" standard entry points for this driver kernel module including: ioctl, read, write, creat. Set up the ioctl so that you can configure the driver to return either Vendor ID, Product ID, or both with a follow up read request from a user space test program. A call to write should allow the calling test application to add a "fake" additional Vendor ID and Product ID to an internal driver maintained "fake USB device" table that will cause this information to be added to the read (and dmesg) output on subsequent reads. Use "insmod" and "rmmod" to remove your driver module and make sure it provides dmesg debug output with printk on load and unload.

Problem 4 [20 pts] -- Set up your USB camera you intend to use for your extended lab and use the USB tracing capabilities of Wireshark to analyze the USB protocol between your host and the camera device during operation. (You can install Wireshark on Ubuntu with "apt-get install wireshark"). Set up your camera to stream and describe on the trace where the command to start streaming is sent to the device and where the data packets with video data are transferred to the host. If you are not using a USB camera for your final project, then please analyze the protocol for the USB2Serial interface you are using between your Beagle xM and your Ubuntu host and take traces for both active and inactive serial port use.

Problem 5 [50 pts] -- Camera Driver (UVC) and V4L2 Exploration on Ubuntu Host and Beagle xM Target:

  1. [20/50 pts] Build a new Linux kernel for the Beagle xM using Kaushik's Kernel Build notes which includes either the UVC or Leopard camera driver set up your flash card to boot this new kernel using the process from Lab #0. Once you have successfully built and booted this kernel, show that the UVC or Leopard driver is present with a dump of /proc/devices. Likewise, if you are using a USB camera, connect it and verify detection by UVC with dmesg. If you are not using a USB camera (e.g. Leopard imaging alternative), then show that this device is seen through /proc/devices instead. If you are using a driver other than UVC, you may substitute inclusion of that alternative driver from UVC to satisfy this kernel configuration and build exercise.

  2. [20/50 pts] Once the driver has been successfully integrated, now cross compile the V4L2 libraries including the main and convert libraries and download to your board. Use your prototype implementation to make test calls into the V4L2 API and use convert (or write your own custom conversion code if you prefer and download to Beagle xM) to create a YUV 4:2:2 formatted version of the following RGB P6 PPM test frame. Include the YUV version with your lab as just a binary pixel data only file and test by converting from the rainbow test image to YUV 4:2:2 and back to a new P6 PPM RGB to verify that this new RGB version can be displayed with Linux Gimp or Windows Irfanview and include the final image in your lab report - comment on whether the new result looks the same or different and why. Run this both on your host Ubuntu system and the Beagle xM to test the porting of your conversion code or use of V4L2 conversion library code you cross compiled.

  3. [10/50 pts] Finally, to get practice with ffmpeg encoding, take the frames found here and encode them into an MPEG4 transport stream using an ffmpeg command line - e.g. ffmpeg -f image2 -i robot%d.ppm -bufsize 8M -maxrate 10000k -s 720x480 -vcodec mpeg4 -qscale 1 -an robot_movie.mp4. This ffmpeg FAQ is very helpful for this type of frame to MPEG and MPEG to frame encode/decode. (Note that frames can be extracted from an MPEG too - e.g. ffmpeg -i movie.mpg -vframes 30 -f image2 -vcodec ppm robot%d.ppm will extract the first 30 frames. Upload this very short MPEG with your lab on CU-learn and make sure it can be played in VLC. The orignal full-length video (720x480, 59.94 interlaced frames per second, YUV, Standard Definition) can be found here in case you want to work with up to 1800 frames to emulate Extended Lab video processing requirements.


EXTENDED LAB UPDATES - Please upload to CU-learn for feedback.

If you have updates on your final detailed design, please upload them to CU-learn. Be sure to schedule a 1:1 FEEDBACK session if you have questions on your Ubuntu host implementation work and make sure that all of your design material is a close to final format as possible at this point.