The labs make up a significant portion of both your prog and final grades. You must complete each one (even for zero credit) to pass the course. A disciplined approach to design, implementation, and testing are key to your success! Wiring and coding the entire lab and then trying to figure out why it doesn't work (they almost never do) can be incredibly painful and time-consuming. Our experience shows that students who get behind on the labs need to catch up immediately, else the burden of uncompleted labs builds to inescapable levels.
Lab notebooks are heavily emphasized in this course and constitute a large portion of lab grades. The lab notebook is maintained as a journal of your lab experience and should allow you, or any knowledgeable engineer, to recreate your project.
An example of what to include in a lab report can be found on the 382 Lab Notebook GitHub page. The actual format is flexible. The information included in the lab report must be tailored according to what is important for the specific lab. In general, the idea is that all full lab reports must stand up to the "hit by a bus" standard. Should you die, another engineer must be able to continue your work without trouble.
You are expected to keep your lab notebooks current as you work on a lab. You may lose substantial points if sections of the lab notebook which should be part of your documentation before the demonstration (such as prelab, approach, flowcharts, testing, debugging, etc.) are entered afterwards. Your conclusion section, lessons learned, and your final formatted code (external to report) are not required before your demo.
In this class, we will use an electronic lab notebook. We'll be using the version control software git and your code must be hosted on Bitbucket. Here is the directory structure that must be used if you have more than one code file or more than one image file to be uploaded for a single lab:
ECE 382 Lab Notebook Example - https://github.com/pw4rn3r/ECE_382_Lab_Ex
Your commit history will be used as verification that you've been keeping your lab notebook up to date as you progress. You should commit early and often.
You'll still need to hand in your grading sheet so I will know your achieved functionality and can record grades and feedback for you.
You are expected to use the same structured programming techniques that you were taught in CS110.
You must comment your code where appropriate. This doesn't mean commenting every line you write - that's distracting and unproductive. Comments should be used to convey the general purpose of a block of code or explain a section that may be unclear. You can assume the reader is a knowledgeable engineer.
Use meaningful, readable variable names - variable1 or var1 or loop1 or L1 are unacceptable.
Don't repeat yourself! If you find yourself using the same code over and over, you should abstract it into a subroutine or function.
For each coding file submitted in your lab notebook, ensure you have a header that includes your name, the date, the assignment, a brief purpose of the code, and documentation for that specific file.
For each subroutine you use, include a header just above the subroutine's location. Ensure the author, function, inputs, outputs, and destroyed registers for that (assembly) subroutine are included in the subroutine header.
For constants, you must use
.equ statements and assign them a meaningful, readable name.
Labels should be used in place of memory addresses and assigned a meaningful, reable name.
You should organize your code in such a way that it's easily readable. While not required, a good structure would be:
.equsyntax for all constants!