**6.08 Example Design Project File/Template**
This browser-renderable file is intended to serve as a template for your 6.08 Design Exercise Reports. We want them to be viewable in a standard browser since it provides a nice uniform viewing experience. We'll use documentation like this when it comes to our final projects so it is good get some practice with it.
The file can be written using markdown syntax and then rendered in a browser using the globally-accessible library [Markdeep](https://casual-effects.com/markdeep/). If you've not written in markdown don't worry. It is actually very simple and designed to not get in your way! Markdown is widely used in documenting your work (github READMEs for example) so even beyond the class it is a great thing to be proficient in.
To view your write-up (as you write it), simply view the file in the browser. To work on it, simply edit it in a any sort of text editor (sublime or whatever your favorite is). Some of them like Sublime even have Markdown plugins to help you.
Markdeep, the particular implementation of Markdown that this page uses, has a fantastic demo page found [here](https://casual-effects.com/markdeep/features.md.html). If you control-click/right-click on that page in your browser and select "View Page Soure", it'll bring up the Markdown that generates all the variou stylings. You can search around on that page as needed.
# Expectations
A 6.08 Design Exercise Writeup should guide the grader through your thought process as well as the design[^motivation].
Highlight how you addressed each specification for the design exercise.
Include a video of your working system embedded in the document. For example:
And then address each of the specifications listed and how you approached/solved them. Highlight what you did so it easy for a staff member to say, "Oh yeah they have achieved the specifications." For example, maybe structure the report like the following (using some examples from Week 1's watch Design Exercise):
# Specifications
Below is how I addressed each specification:
## Watch Faces
**Requirement:**
* The watch should have two "faces", with details of the design left up to you:
* A digital readout (for example "8:45") and
* An analog readout. The analog readout should have a hour, minute, and second hand.
**Implementation:**
Briefly explain how this was done.
## Switching Between Faces
**Requirement:**
* The user should be able swap between the two faces using a button connected to input **pin 16.**. Switching between the two faces should be based on pushing-and-then-releasing the button. One push-release sets it to analog. Another to digital. Another to analog. And so on. It cannot be pushed=analog/unpushed=digital for the faces. The button functionality must be sufficiently responsive that its usage isn't impaired at any time during operation (i.e. you should avoid **blocking** code with the exception of the GET request).
**Implementation:**
Briefly explain how this was done.
## Server Time Retrieval and Smooth Updating
**Requirement:**
* In order to get absolute time, your device must make periodic HTTP GET requests to the url here: http://iesc-s3.mit.edu/esp32test/currenttime which will return the current Boston time in a format like the following: `2018-02-11 18:37:29.776430`
* The device needs to only report the time (don't worry about temperature or anything else in the video), but it can't just repeatedly grab it off the server. Instead *at most* it can grab the time once every one minute, and in the time in between in must update based off of its own internal timer.
**Implementation:**
Briefly explain how this was done.
# Other Thoughts
If there's some important code elements you'd like to highlight,(and there almost always is), feel free to bring them out in your report by inserting your code in portions (do not just dump all your code in the file like this. It is no replacement for properly uploading your zipped codebase for the design exercise). We would, however like you to "dump" your code at the very bottom of the writeup in an appendix regardless of whether or not you detail bits of it in your report.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
int special_function(int x){
//some neat code can go here
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Consider adding diagrams to your report _if_ they'll help you explain yourself as well. You can embed images included with the report (consider using relative file paths) or you can also render using ASCII art. Markdeep has a pretty nice built-in ASCII-art-to-SVG generator. Look here's the figure from lab01a. Pretty sweet.
*****************************************************************
* *
* .-------. *
* | Start | *
* | State +----. *
* '-------' | *
* | *
* v *
* .-+-----. *
* .---->+ State | *
* | | 0 | *
* | '---+---' *
* | | *
* getInput()==2| | getInput()==5 *
* | v *
* | .---+---. *
* | | State | *
* | | 1 | *
* | '-+-----' *
* | | *
* '-------' *
* *
* *
*****************************************************************
Do you need some math to explain what you did? Don't worry, you can do in-line math like $x=5$ or centered math like:
$$
y[n] = x[n-1]+0.3x[n-3]
$$
Do not feel the need to go overboard with length of these reports. In fact if you write 2,000 words we'll knock off points as a matter of principle. The point of this is to force you to clearly and succintly explain your design. I would suggest keeping your writeup to be below 500 words.
Questions? Of course always post on Piazza. We will not "pre-grade" or "look over" your report prior to grading, but if you have general questions either about Markdown or content, always feel free to ask.
[^motivation]: This is done in response to past years where students would submit 5-ish-second long videos with no narration and/or just heavy breathing, featuring only a part of the specification, and then complain when they lost points. Thanks, 2018/2019 students.
# Code Appendix
Put all of your code files clearly labeled in code boxes below (yes it makes the document large, but it makes it easier for the graders).
My main file is here:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
void setup(){
//stuff
}
void loop(){
//stuff
}
int other_function(){
}
//etc...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A supporting file is this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
int another_function(){
}
//etc...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~