- Common code problems to avoid:
- --- AVOID using X memory in the vicinity of $40 and the index register r6. The I/O system uses these to maintain a stack.
- --- If you hear "motorboating" when you are listening to the result of a process which uses a large circular buffer, Make Sure that you have used a valid buffer base address.
- There was a bug in the MATLAB m file iirtable.m, that produced the wrong zeros for bandpass filters with an odd number of second order sections. Please correct your version by cutting and pasting from the following:
- fixed version of iirtable.m
- The Lab 4 document has been Posted. If you want to use a SOAP (Sum of All Pass) filter structure on the 56307, take a look at this document:
- Sum of Allpass filter hints
- The Lab 3 document has been changed a little.
- The simulation section of Lab 2 has been rewritten to use the Motorola Simulator rather than the domain Tech Debugger.
- See the schedule for instructor lab hours below.
- Please turn the lights off and close the door to the lab if you are the last one to leave. Also, make an effort to keep the lab relatively tidy.
- Please disconnect the power feed to the DSP cards when you have finished your work. Also, turn down the gain and turn off powered speakers when you are done with them.
- From the graders:
IMPORTANT: lab documents will be accepted in paper format only.- Be sure to include the motivation and ideas behind your design decisions and conclusions.
- Put source code in the Appendix of your documents.
- Annotate the axes of graphs with labels and numerical scales.
- To download the current Suite56 development tools, with simulator, and/or documentation, follow this link to the Metrowerks website.
- For those interested, one can find Dr. BuB 56000 (the 563xx is backwards compatible) assembler examples here (it is a FGMZIPed tar file).
- See the DSP Development System page for Lab software and documentation.
- Make sure the check the PLL setting in your test code: if it is too fast for the hardware, the processor may malfunction.
- NOTE NOTE NOTE! The Lab room (1B79) is RESERVED for the Control Systems Lab course on Fridays from 2:00PM until 6:00PM.
Course description
Class meets Mondays, Wednesdays 12:00-12:50PM, Room 1B28. First class meeting is on 1/10/2005.This course is a one semester introduction to the design, implementation, and debugging of real time DSP algorithms written in assembly language for an industry-standard DSP microprocessor. The course consists of one lecture per week and approximately 7 laboratory projects. Each student must complete the laboratory projects individually using the lab stations located in room 1B79. The course has an open-lab policy: students may use the lab whenever the building is open except for the times announced for the Controls lab.The lab stations consist of the following:
- DSP development board (Motorola DSP563xx microprocessor)
- Host PC with development software tools
- Stereo amp and speakers
- Signal generator
- Oscilloscope
- Cassette deck
For each of the laboratory projects the students individually prepare a written report, and in most cases demonstrate the software to one of the instructors. Students enrolled in this course for graduate credit (5002) will receive additional project requirements.
Contact Information
- Francois Meyer
ECOT 251.
Lab hours: Monday 4:00-6:00 PM
- Clifford T. Mullis
mullis@schof.Colorado.EDU
ECOT 335.
Lab hours: Tuesday 1:00-3:00 PM, Wednesday 2:00-4:00 PM
Lab policy
The laboratory is expected to be open 24 hours a day, seven days a week, EXCEPT Friday 2:00PM-6:00PM when the room is used by the Controls Lab.
Because there are more students than lab stations, students will be required to share equipment and coordinate individual schedules in a flexible, courteous, and professional manner. No equipment is to be removed from the lab at any time.
Students in this course work individually, not with partners or teams. Learning low-level DSP software development requires concentrated individual effort. Despite the need to share lab stations, each student is expected to work individually and to prepare a unique problem solution. Let there be no misunderstanding: working collaboratively or copying the work of another student and submitting it as your own is wholly sufficient grounds for dismissal from the course.
In no case will abuse of equipment, other students, or instructors be tolerated. If such behavior occurs, an administrative drop will be issued for the student involved.
It is the sole responsibility of the student to maintain backup copies of all source code and other materials developed for each laboratory project, and to prepare the project solution well in advance of the submission deadline. Personal computer equipment is known to fail, and often at the most inopportune moment. Don't let a sudden hardware failure blow hours of your effort!
Grading policy
Grading for the course will be based primarily on the results of the laboratory projects and the quality of the lab reports (80%). Lecture attendance--with active participation--will account for 10% of the course grade, and the remaining 10% of the grade will be based on the student's lab skills as observed during the semester by the instructors.
Important reminder on lab report deadlines
Grading on lab reports is determined by the guidelines listed at the end of each lab document. The guidelines are based on completion of lab tasks. The lab reports document the work students perform and their observations. The submission deadlines for each lab are posted on the schedule page of this website. The submission deadline for lab reports establish the time at which students must present the evidence of their work. Failing to submit a lab report on time indicates that no work was completed for the lab, and that record will apply to the 80% grading criterion. Lab reports submitted after the deadline can apply only to the class participation and lab skills criteria, and they are not subject to detailed evaluation by the graders.