6.115 Microcomputer Lab! by Audrey C. '24

I can’t wait to write one of those class tier list blogs before I graduate, and I know for sure that 6.115⁠01 or 6.2060 according to the new numbering system, which does not deserve rights Microcomputer Lab, taught by Prof. Steve Leeb, will sit high and mighty in the S-tier. Sometimes classes at MIT feel difficult for the sake of being difficult, but 6.115 hit the rare sweet spot of being laborious and difficult yet so so worth it.

I signed up for 6.115 because I needed a lab class to fulfill a course 6-9 requirement. 6.115 is known as the hardware appreciation class, and having little prior experience with this kind of stuff, I wanted to appreciate hardware. It helped that a handful of my friends felt like signing up for hell⁠02 more on this later ;-; too — to quote Bianca ’24, “why is everyone and their mom taking 6.115 this semester??”

I walked into the first lecture wondering, what even is a microcontroller (or microcomputer)? When Steve asked the class that question, people responded with answers along the lines of “a small computer” or “a single chip designed to do things” or “[insert hardware jargon that I don’t remember because I had no idea what they meant at that time].” Steve immediately rattled off counterexamples for every single definition. Apparently there’s no specific feature that makes a processor a microcontroller, versus just a CPU, as microcontrollers are so vaguely defined. (Thank you Callie for reminding me exactly what Steve said here; her ability to retain content from lecture was unmatched).

I still don’t know what a microcontroller is, but no one really does either.

Steve had a very distinctive style of lecturing that I can only describe as an ~experience~. His incredibly animated personality and propensity to call electronic components “dude” made me want to absorb everything he was saying. But he went fast. I looked down for five seconds to jot down some notes. I looked up and he was talking about an entirely new topic. I was feeling unsure of myself after having understood approximately 1.28% of what was said in lecture, but it was reassuring to know that some of my friends were in the same boat.

Lab was a whole ‘nother experience. I easily put 20 hours/week into 6.115 labs, structuring my eating schedule, sleeping schedule, my life around the lab hours. Basically whenever I wasn’t at another class or at a Spinning Arts related thing or sleeping,⁠03 I once fell sleep on the narrow, hard, not-ergonomically-suited=for-sleeping bench outside of the 6.115 lab and another time napped on a couch inside the nearby bathroom... I do not miss those days I was on the 6th floor of Building 38 wrestling with this black suitcase that seriously looks like a bomb:

don’t bring this to the airport

I often joked that 6.115 in a nutshell was, “how do you make something that takes 10 minutes on an Arduino take 10 hours on an 8051 microcontroller instead?” The point was to strip things we often take for granted, like how Arduinos can read analog values, down to the bare bones of creating pulses of electricity for the right amount of time at the right place. And through that we truly understand what’s going on under the hood in a microcontroller.

the very climatic result of 20 hours of work: turning on a fluorescent lamp

My friend Shruti, who took the class a year ago, told a career fair recruiter about programming in 8051 assembly in 6.115. To which the recruiter responded, “Are you sure you worked with 8051s? …because those are really old.” After roasting the recruiter and the general tendency for men to question whether feminine presenting people actually know what they’re working on, we laughed about Steve’s philosophy of rejecting modernity.

The 8051 microcontroller family was invented in 1980, not long before Steve started his undergrad at MIT in 1983. As a result, 6.115 hasn’t changed much since Steve first started teaching it. This was confirmed by a conversation with someone who took 6.115 over ten years ago. What sounded like the biggest difference between then and now was that they had to lug around a lab kit stored in a wooden box about waist height, while we got the luxury of suspicious looking suitcases.

The class website explains the rationale behind Steve philosophy best:⁠04 well yea duh, because it's in his own words

This class is not particularly about learning how a specific microcontroller is programmed, or about designing circuits, or about wiring chips together. We do a little of all of these things, but our real goal is to introduce you to a palette of tools and techniques that let you build what you can imagine. These techniques are much more general than the details of a single processor or programming language. Chips come and go, but successful approaches for engineering design have a life that spans many iterations of a particular technology.

When he says “palette of tools and techniques,” I think a lot of it is learning how to learn.

At one point a TA asked me, “Have you used a multimeter before or are you more of a 6-3?” Ah yes, the two genders. The class was pretty split between seasoned hardware enthusiasts and 6-3 software bros⁠05 used in a gender neutral way here wanting to broaden their horizons. While I’ve used a multimeter before in another intro electronics class, I’ve never had to design and debug circuits/hardware systems in the way this class just expected you to.

The labs taught you how to… by just making you do it. My friend Alicia asked a TA if there was supposed to be a schematic attached to the lab handout, to which the TA responded, “oh you’re supposed to draw one yourself.” We learned that microcontrollers and other electronic components all came with datasheets, which held answers to how to wire and use them.

Figuring out the circuits was one thing, but making them work was another. I’ve always thought of hardware debugging to be some sort of black magic— how do you figure out which one of your countless components is borked? I couldn’t just throw print statements everywhere in the same way that I would with a software program. It turned out that the hardware equivalent of print statements was using an oscilloscope, a device that plots the voltage of an electrical signal over time. I learned how to predict what the shape of the electrical signal should look like through reading datasheets and intuition built over time. If there were discrepancies between my expectations and the oscilloscope reading, then I’ve (probably) found the bug, whether that be incorrect wirings or a blown out chip. As I did this more and more, the scattered pieces of what I managed to gather from lectures started to come together.

Everything about the labs fostered collaboration. The office hours were severely understaffed⁠06 shoutout to the TA/LAs who overstayed shifts by over 3 hours ;-; (unfortunately this is common issue across EECS classes often beyond the control of the course staff), so it was simply faster to get help from a classmate. There was an unspoken understanding that I would gladly help you with a section that you’re struggling on not only because chances were that you would be able to help me with a different section, but also because this class was just so darn difficult. Giving and receiving help felt like a mutual acknowledgement between you and I that we were in this together.

don’t ask how much time and how many people i had to ask for help to get this stupid LCD screen to work

The last three weeks of the semester were dedicated to the ✨final project✨, where we could make anything that integrated hardware and software systems and used a Cypress PSoC development board. I decided to make a mechanical DoodleJump out of addressable LEDs (the same RGB strip lights that you might put up in your room) because I wanted an excuse to play DoodleJump for “research purposes.”

The PSoC (pronounced “pee sock”) is the most poorly documented development board known to mankind, which we had the sheer luck of using because Cypress funded a significant portion of 6.115. Maybe that was the point though. Because the PSoC had very few prewritten libraries, we had the immense honor and privilege⁠07 /s of writing our own from scratch.

It turns out that like many electronic systems, RGB strip lights are controlled by a series of square waves. A square wave of a certain timing is interpreted as a 0 bit, and a square wave of another timing is interpreted as a 1 bit.

see how keeping the signal at high for a tiny bit shorter gives you a 0 and a tiny bit longer gives you a 1?

A sequence of 24 bits determines the color of a single LED — the first 8 determine the red value, the second 8 determine the green value, and third 8 determine the blue value. To control multiple LEDs in a strip, you would just send a second set of 24 bits to control the second LED, and so on and so forth.

After five hours of staring at square pulses lasting fractions of a microsecond on an oscilloscope, I …*drumroll*… turned on an LED! I only have Cypress to thank for this riveting learning opportunity.

Here’s the rest of my project! If you haven’t played the mobile game DoodleJump before, you tilt your phone to get the little jumper dude to jump on platforms of increasing heights. In my mechanical version, the player instead uses clicky pen controllers retrofit with parts I machined on a lathe to control a jumping red dot. If the player dot jumps to another side of the LED cube, a motor spins 90 degrees such that the player dot is always on the side facing you. I had handwritten a beautiful seven page report documenting the process in my lab notebook, but I forgot to take pictures before turning it in.

The following picture carousel includes the hardware schematic, software flowchart, and mechanical CAD drawing for you nerds who care:

pretty lights!

fun fact Winnie found the motor in the Stata loading docks dumpster

cross section of the motor driven base. The is able to rotate because of a tapered roller bearing (the bottom pink part), which is good at supporting axial loads (i.e the LED cube + a PSoC board). Also Anhad, who also lives on Tetazoo, just happened to have a tapered roller bearing lying around when I was in dire need of one. It pays off to live with a bunch of MechEs. The gap in the orange area, which was 3d printed, houses a slip ring, which allows wires to rotate without getting tightly tangled around each other (which would be concerning!)

Here's the schematic for the clicky pen controller. the ends of each clicky pen controller contain a magnet, which changes the voltage output of a hall effect sensor depending on the distance from the magnet to the sensor. this signal is amplified using op amps, which then gets processed by the PSoC to change the LED cube display

close up on the clicky pen controllers! I machined down an aluminum rod to fit inside the casing and then press fit a welding rod into the aluminum rod to create a part that could extrude outside the end of the pen. The welding rod is glued to a 3d printed part that houses the magnet.

Here's the schematic for the motor base. I needed the base of my cube to rotate exactly 90 degrees every time. I made what's called an encoder to ensure that my motor was able to stop at exactly 90 degrees of rotation. I attached four tape flags to the rotating axis in 90 degree increments. Whenever the tape flag hit a stationary photosensor, we know that the 90 degree rotation has been completed and the photo sensor's voltage output would change.

close up of my super high tech tape flags!

schematic of doodlejump software logic

Previous Next

Here’s a video of my jumpy boi in action:

In my first draft of this blog, I wrote something along the lines of “6.115 taught me how to persevere through things that are hard.” But I already knew how to persevere. I’ve already made it through countless classes whose problems set my brain cells on fire prior to taking 6.115. I can confidently say that everyone here is good at persevering, by the nature of how academically and emotionally demanding MIT is.

Instead, I’ll say that 6.115 reaffirmed my ability to persevere, except this time I knew not to beat myself up in the process. While I couldn’t resist mentioning in every other paragraph just how many hours I spent on certain parts of this class, sometimes those hours led to nowhere. Sometimes my system wouldn’t work no matter how much I probed and poked at it. Of course, it was disappointing to admit to the lab grader that your system didn’t work, but so what? I know that given enough time, I am capable of solving the problems that I wasn’t able to this time around because I have collected a spectacular palette of tools and techniques over the last semester.

And if I encountered a similar system or problem in a research or workplace or other Real Adult setting, I’d know exactly where to start.