New post: umich/w24_373

13 files changed, 1082 insertions, 0 deletions

diff --git a/docs/umich/img/w24_wrapup/373_bike.jpg b/docs/umich/img/w24_wrapup/373_bike.jpg
new file mode 100644
index 0000000..29f7606
--- /dev/null
+++ b/docs/umich/img/w24_wrapup/373_bike.jpg
diff --git a/docs/umich/img/w24_wrapup/373_dhl.png b/docs/umich/img/w24_wrapup/373_dhl.png
new file mode 100644
index 0000000..b9d818b
--- /dev/null
+++ b/docs/umich/img/w24_wrapup/373_dhl.png
diff --git a/docs/umich/img/w24_wrapup/373_fuck_you_st.png b/docs/umich/img/w24_wrapup/373_fuck_you_st.png
new file mode 100644
index 0000000..831776a
--- /dev/null
+++ b/docs/umich/img/w24_wrapup/373_fuck_you_st.png
diff --git a/docs/umich/img/w24_wrapup/373_log_cover.png b/docs/umich/img/w24_wrapup/373_log_cover.png
new file mode 100644
index 0000000..01278af
--- /dev/null
+++ b/docs/umich/img/w24_wrapup/373_log_cover.png
diff --git a/docs/umich/img/w24_wrapup/373_pcb.png b/docs/umich/img/w24_wrapup/373_pcb.png
new file mode 100644
index 0000000..bd1da09
--- /dev/null
+++ b/docs/umich/img/w24_wrapup/373_pcb.png
diff --git a/docs/umich/img/w24_wrapup/373_pcb_back.jpg b/docs/umich/img/w24_wrapup/373_pcb_back.jpg
new file mode 100644
index 0000000..391d958
--- /dev/null
+++ b/docs/umich/img/w24_wrapup/373_pcb_back.jpg
diff --git a/docs/umich/img/w24_wrapup/373_pcb_front.jpg b/docs/umich/img/w24_wrapup/373_pcb_front.jpg
new file mode 100644
index 0000000..514a939
--- /dev/null
+++ b/docs/umich/img/w24_wrapup/373_pcb_front.jpg
diff --git a/docs/umich/img/w24_wrapup/373_pcbway_meme.png b/docs/umich/img/w24_wrapup/373_pcbway_meme.png
new file mode 100644
index 0000000..07811a1
--- /dev/null
+++ b/docs/umich/img/w24_wrapup/373_pcbway_meme.png
diff --git a/docs/umich/img/w24_wrapup/373_protoboard_parts.jpg b/docs/umich/img/w24_wrapup/373_protoboard_parts.jpg
new file mode 100644
index 0000000..dd5a0f3
--- /dev/null
+++ b/docs/umich/img/w24_wrapup/373_protoboard_parts.jpg
diff --git a/docs/umich/img/w24_wrapup/373_protoboard_wires.jpg b/docs/umich/img/w24_wrapup/373_protoboard_wires.jpg
new file mode 100644
index 0000000..9fbd0c7
--- /dev/null
+++ b/docs/umich/img/w24_wrapup/373_protoboard_wires.jpg
diff --git a/docs/umich/img/w24_wrapup/373_this_side_toward_enemy.jpg b/docs/umich/img/w24_wrapup/373_this_side_toward_enemy.jpg
new file mode 100644
index 0000000..f9564da
--- /dev/null
+++ b/docs/umich/img/w24_wrapup/373_this_side_toward_enemy.jpg
diff --git a/docs/umich/w24_373.md b/docs/umich/w24_373.md
new file mode 100644
index 0000000..d55855e
--- /dev/null
+++ b/docs/umich/w24_373.md
@@ -0,0 +1,1081 @@
+# Winter 2024 Course Review: EECS 373
+
+2024-04-30
+
+Course Title: Introduction to Embedded System Design
+
+Rating: 3.5/5
+
+## Instructors (Robert Dick & Matthew Smith)
+
+Robert Dick is ridiculously tall and uses a [Panasonic
+Toughbook](https://en.wikipedia.org/wiki/Toughbook) running openSUSE. He's
+the lecturer of this course.
+
+Pros:
+
+- FOSS advocate
+- Is happy to discuss "what if" scenarios
+- Shares stories of real startups (including his own)
+
+Cons:
+
+- Too much of "here's the thing, learn it" versus "so here's how they came
+  up with the thing"
+- Sometimes too eager to share the insides of a thing (it's useful though)
+
+Matthew Smith is our lab instructor who oversees all lab equipment and
+material purchases. He's a really nice guy, but I sometimes worry about
+his health.
+
+Pros:
+
+- Is willing to talk about any idea
+- Knows everything in the lab
+
+Cons:
+
+- He'll talk with a student for a long time, which may be good or bad
+  depending on you happen to be that student or waiting behind them
+
+## Course topics
+
+The course covered a pool of loosely-related topics, all relevant to
+embedded systems but divergent. I categorized them:
+
+- Microcontroller low-level
+    - ARMv7-M Thumb ISA
+    - ABI (registers, stacks and stuff)
+    - Interrupts (with preemption)
+    - Timers (hardware and virtual)
+    - PWM with timers
+    - MMIO (including GPIO)
+- Buses
+    - APB (advanced peripheral bus, an ARM feature)
+    - UART
+    - I²C
+    - SPI
+- Analog
+    - ADC
+    - DAC
+    - RC filters
+    - Op-amps
+- Things you can put a circuit on and how to put a circuit on them
+    - Breadboard
+    - Protoboard
+    - PCB (intro)
+    - Soldering and desoldering
+- Other peripherals
+    - Memory (EEPROM, flash etc)
+    - Motors and other things that move
+    - Shaft encoders
+    - Antennas (and wireless communication)
+- Power
+    - Integrity
+    - Battery life estimate
+    - Just Add Another Capacitor™
+    - AC-AC transformers
+    - AC-DC rectifiers
+    - DC-DC converters
+- Meta
+    - How to pick a project to e.g. start a company for
+    - How to debug a complex system (spoiler: you take it apart)
+
+Of these, the topic I learned the most from is interrupts. I had used
+interrupts in my previous [Byseekel](../projects/byseekel.md) project, to
+wake up the AVR MCU from sleep mode. But now I know what actually happens
+is the MCU switches to interrupt mode and switches back to normal mode
+once the interrupt handler is done running.
+
+The most boring topic, on the other hand, is APB. It just floated into the
+slides for no reason. I've never heard of it, and it doesn't seem all that
+essential other than to illustrate a point that you can interface with an
+FPGA or something that speaks the same protocol if you want.
+
+The reason why the range of topics is so wide is because we had wildly
+different projects. But first let's talk about labs.
+
+## Labs
+
+We have seven labs, covering different topics. All of them were done on
+a Nucleo board, and some of them required a Tang Nano, which is a cute
+Arduino Nano-esque FPGA.
+
+The worst part about labs is how long the documents were. The longest one
+was 41 pages. It's full of images, yes, but it's hard not to be
+intimidated. In hindsight, though, it wasn't the worst lab imaginable, so
+I must have overthought.
+
+Labs were done in groups of two. I often came to the lab (which is open
+24/7) before our session to work ahead, so we don't run out of time. Once
+I discovered that I accidentally did most of the lab all on my own. So for
+the sake of fairness, but in a questionable and kinda condescending
+manner, I told my lab partner on the lab that I did most of the work but
+I'm gonna let him do it again anyway. So I let him take the keyboard and
+watched him do the lab, providing help every other minute. I still have no
+idea if I did the right thing.
+
+## Project
+
+In the final month of the semester, lectures and labs were over, and the
+focus shifted to the project. We didn't even have a final exam, only two
+midterms.
+
+At the beginning I was looking forward to the project — it was the first
+time I had the chance to make something tangible at UMich. And at the end,
+though everyone suffered, many teams made something that's at least fun.
+Not us. Not us in the least bit.
+
+__If you are reading this article for academic guidance, please keep in
+mind that this is personal opinion and personal experience. It is 100%
+honest but does NOT represent the project outcome. My experience is more
+than one sigma lower than average. If you weren't an egoistic idiot like
+me, you'll do better.__
+
+Or just skip to [Verdict](#verdict).
+
+I hate this project so much. If you are my teammate and you're reading
+this, please don't take this personally. I redacted your names (and mine
+as well). It's about this course and this course only.
+
+This part has no constructive purpose. It's a long story and it's painful
+even to write about it, but I'm glad it's over. Let me start from the
+beginning.
+
+I made the right decision to keep a project log. It grew to be 15 pages
+long. It's extremely helpful when I'm trying to get my shit together in
+this blogpost.
+
+### Brainstorming
+
+Last semester, three friends of mine were thinking about enrolling in 373
+and asked if I wanted to be their teammate. I said sure. Later, two of
+them dropped, so the one left asked me if we should find our own teams, or
+invite two more. I chose the latter. It cannot be said whether the
+alternative would have been the better choice, but it might.
+
+So one day after lecture, we sat down at a table in Pierpont to discuss
+our team project idea. Everyone brought along three proposals, as required
+by Robert. This brings a total of 12 proposals. Mine were:
+
+- "Blinkensleeves": MkIII of the bicycle blinker project, but instead of
+  having a switch, the cyclist can blink the LEDs simply by lifting their
+  arm. The LEDs are worn on, you guessed it, their sleeves.
+- "Optophone": An optical turntable where you encode MIDI in a circular
+  barcode-ish pattern, print on paper, and spin under a light sensor to
+  play it back
+- "Bookmargotchi": A bookmark with a Tamagotchi-like character that you
+  must feed every day by reading the book for an amount of time
+
+(Short note: before I discussed them with my team I talked with Matt Smith
+about my ideas. He was oh so patient.)
+
+Other proposals included
+
+- Kibble dispenser for stray cats (we have no stray cats here)
+- Automatic garbage can (that ties up a full bag and open a new one.
+  I need it)
+- Thing that warns you when a pot is boiling to the brim (helpful but we
+  can't actually boil things in the lab)
+- Shoe dryer (extremely useful in snowy Michigan weather but seems
+  infeasible)
+
+I felt "smart" and suggested that we settle this with a vote, where
+everyone gives each proposal a rating from 1 to 5, indicating how much
+they _want_ to do it, not how feasible it seems. Then we sum up the
+ratings for every project.
+
+And my bicycle blinker project won. Later I recounted the votes with
+a quota on how many total votes everyone has, but my project was still in
+the lead. And I could see that my teammates trusted me, because I showed
+them my previous iteration. We thought it was a safe bet.
+
+### Brief tangent: other people's ideas & fedi interview
+
+Because everyone dropped their files to a single google drive folder,
+everyone can see everyone's ideas. When I read some of them I thought,
+huh, it's already invented, why you gonna reinvent it?
+
+Things someone wanted to reinvent:
+
+- Panic button
+- Tuner
+- Automatic door
+- Guitar pedal
+
+Some proposed projects just because they could. They did admit the market
+for the product is next to none. My turntable proposal is one of them.
+
+Robert Dick made a great deal out of market research and how to run
+a successful startup. He said it was helpful to interview strangers, so
+I did on fedi, targeting specifically the cyclists (fedi is never short of
+cyclists). I asked:
+
+> cyclists of the fediverse: is there any kind of device that does not yet
+> exist, but you wish existed, that would improve your cycling
+> experience/safety?
+
+> would be cool if a team of undergrads could make it in two months for an
+> embedded system course (we're brainstorming)
+
+> boosts welcome
+
+> \#cycling #embedded #electronics
+
+Part of the fedi crowd brought up a variant of the blinker idea without me
+even mentioning, so it's definitely one of the more common things
+a cyclist could ask for. Others proposed:
+
+- Car-detecting radar
+- Accelerometer-based brake light
+
+So I thought it would be a good idea to combine these three ideas and not
+add more to avoid making a overcomplex device nobody asked for that might
+not even work.
+
+It turns out Robert's advice was for people who actually wanted to make
+money, not those who are just doing a course project. The market research
+is actually of no importance in the grading.
+
+There's also project proposals that address real unsolved problems, but
+there's a reason they were unsolved.
+
+Some projects are both novel and useful, but they don't have to be
+embedded. It could run as a regular computer application.
+
+Now that the course's ended, I found that it's ok to reinvent something
+for a course project. There is a very narrow window of ideas that are both
+novel and useful. So it's ok to be only one of them.
+
+My failure begins here.
+
+Stupid thing #1: unrealistic idealism and wanting my project to be both
+novel and useful
+
+### So what were we actually gonna build?
+
+In our project proposal, we wrote (excerpt):
+
+> Customer: Cyclists who wish to improve safety with little extra effort.
+>
+> Value: Cycling is a significant source of accidents in the US [1]. Our
+> product increases visibility of the cyclist with LEDs, detects passing
+> vehicles from behind, and alerts both the cyclist and driver.
+
+> The cyclist can control the LEDs either by raising their arm or by
+> activating a switch near the handlebars. The LEDs can be mounted under
+> the bicycle saddle, on the front tube, or fastened to cycling apparel.
+> They can light up in different patterns (e.g. blink left, blink right,
+> brake, flash, etc) to alert vehicles […]
+
+> Our product can also detect vehicles approaching the cyclist from
+> behind. When the cyclist is at risk, it flashes LEDs as a warning to the
+> vehicle and activates the buzzer to alert the cyclist.
+
+> Similar products exist on the market [2]. Ours is more modular. For
+> example, the cyclist may choose to remove the arm position sensors,
+> relying on switch control entirely.
+
+> Approach: Our product is modular. The user can hot-plug different
+> modules to a hub. There are two hubs in a typical installation: front
+> and back. The front hub is to be installed on the handlebar, and the
+> back hub may be mounted on the bicycle facing backward, or clipped to
+> the cyclist’s back. Each hub has a Bluetooth Low Energy-capable MCU,
+> likely an ESP32. The hubs communicate with each other to ensure
+> consistent output.
+
+> Each module below can be hot-plugged to the front hub, back hub, or
+> both:
+
+> - Switch module: front.
+> - Accelerometer module: back. Is a pair of accelerometers physically
+>   attached to cyclist’s sleeves.
+> - Radar module: back. Consists of doppler radar sensor and buzzer.
+> - LED module: both. Consists of a light sensor and LEDs. Form factors of
+>   LEDs may vary but pinouts are compatible.
+>
+> [1] https://www.cdc.gov/transportationsafety/bicycle/index.html  
+> [2] https://www.amazon.com/dp/B0C27FGHMW
+
+Do you see the problem? I was way too idealistic. I falsely assumed I had
+the ability to build something out of a startup. Not with $200 budget. Not
+with two more EECS courses I was taking this semester. I went too far into
+thinking about so-called "user experience" up front, without the
+fundamental safety check that the basic functionalities work. I was so
+keen on the idea of building something that's not like other groups:
+robots, screens, cliché smart-X, just smack a couple Adafruit breakouts
+together on a breadboard like a high school STEM 101. I wanted to make
+something that, at the demo day, stood out among the others for its
+incredible simplicity, beauty and reliability. I wanted to make something
+that doesn't look like a 373 project. Something that I would use. That
+people would use. Of course that didn't happen.
+
+The primary mistake of our team is that we did not form a feedback loop.
+Throughout the project, it seemed like I was the one dumping all the ideas
+into a pool, and failed to ask for enough input to mold them into
+unambiguous targets we could set milestones for. It's like saying "hey
+let's cook something" but not specifying what we even want to eat. So we
+had different ideas of what the project is about.
+
+I named my proposal "Blinkensleeves" because I had envisioned LED strips
+taped to jacket sleeves; it did not happen. Instead we just slapped them
+on a boring box. I forgot when we abandoned the sleeve idea, but it was
+not my decision, but my compromise. (Our project would have sucked anyway.
+Also, we named our project "BicycLED" instead)
+
+I did ask for their opinions; but since it was the early stage of the
+course, we could not tell what is good enough for the course. Picture
+this: You tell your teammates you once built X, and you are gonna build
+X II. You have an idea that you're 50% sure will work. You ask your
+teammates for ideas or alternative. The room falls silent. What happened?
+Is it:
+
+- They agree with you?
+- They can't come up with anything else?
+- They don't understand what you said?
+- They are insecure and internally rejected their potentially better
+  ideas?
+- They think you're a fucking idiot and are just being polite?
+
+I was too good at persuading people that my ideas work. Of course,
+I presented them because I thought they do work. Somehow I have deterred
+the rest of my team from contributing.
+
+Stupid thing #2: Not being specific enough about project goals.
+
+The root cause is that the project was too personal. Having had the idea
+since 2021, I couldn't tolerate a product that deviates from my idealistic
+model. This more or less alienated my teammates, and pressured us all in
+the end.
+
+Despite a "complexity point" requirement in the rubric, I refused to add
+unnecessary features such as a screen. My argumet was that screens on
+a "safety" device is counter-effective. Sure, that may be the case, but
+you're designing a _course project_. Not a fucking body cares, idiot! Just
+add a 1604 LCD and you could stop worrying about those stupid points in
+the final weeks!
+
+Stupid thing #3: Rejecting a screen.
+
+### We did not use ESP32s
+
+You may have noticed that we mentioned ESP32s in our initial proposal, but
+we did not end up using any. Initially I considered the ESP32 because it
+had integrated Bluetooth Low Energy (BLE). But two reasons stopped me:
+
+- The BLE protocol is horribly complex and I didn't understand any of the
+  boilerplate code
+- It seemed we had to use the Nucleo board because that's what the course
+  was about
+
+So I admitted my first defeat and went for the Nucleo. Wireless was done
+over the XBee module, which is a breakout board you talk to via UART and
+it would transmit/receive your payload over 802.15.4. It's just like
+connecting the two MCUs with UART wires. I love it. And it turned out to
+be the part that I worried about the least in the later part.
+
+However I had a brainfart when I first configured them. I had to use
+a program that the XBee company made to flash the firmware, and I needed
+to give each XBee the serial number (like a MAC address but not quite) of
+its peer, but the program only allowed me to touch one XBee at a time. So
+I just typed the serial numbers in a text file. But I made a typo, and
+confused `0xc4db` with `0xc4bd`. This led to probably an hour of wasted
+time (which will turn out to be not the worst).
+
+Using a Nucleo is the best decision. I have no idea what demon would
+unfold if I insisted on the ESP32. I could possibly be the one doing all
+the work, because to my knowledge, my teammates had no prior experience
+with MCUs, so it'd be unrealistic for them to learn yet another tech stack
+(ESP-IDF). And I've never used it either.
+
+### Buying stuff (and getting stuff from the lab)
+
+Now that I'm about to bring up technical names, it may be helpful to
+present an annotated photo of our final product, just so that you know
+what I'm talking about.
+
+![Assembled PCB with an XBee, Nucleo, radar, LDR, expander, NFETs, and
+sockets](img/w24_wrapup/373_pcb_back.jpg)
+
+▲ Back hub
+
+![Similar PCB with no radar but an extra buzzer screwed on the
+board](img/w24_wrapup/373_pcb_front.jpg)
+
+▲ Front hub
+
+(Oh, the PCB, you ask? I designed it. It's the direct source of agony
+later on.)
+
+We had a budget of $50 per person (or $200 for our team of 4). Earlier
+Matt had suggested buying a Doppler radar to realize the vehicle
+detection, partly because he never used one and wanted to see how it was.
+
+Doppler radars (the red spoon-shaped board) are microwave devices, which
+means two things:
+
+- They are more penetrative than light and propagates through thin
+  non-conductive planes like plastic, which makes it possible to keep it
+  inside the enclosure for better water-proofing
+- They're black magic
+
+We asked Matt to buy one on Mouser for maybe $30 or 40.
+
+We got (I got) these tiny Nucleo devkits (L432KC) from the lab. I asked
+for two but neither of the first batch worked. So I asked for two more.
+Matt just gave me two brand new boards. Thanks Matt!
+
+We got (I got) the XBees from the lab. Instead of 2.54mm pitch headers
+they got 2mm ones (I don't understand why), so we got (I got) two adaptor
+boards so we could tack them in the breadboard.
+
+Later we ordered the buzzer because I was dissatisfied about how quiet
+(and how useless as a horn) the 3V piezo buzzer was. This one? It'll blow
+your ears off!
+
+### Early optimism & state synchronization over XBees
+
+I was like "yea im gonna absolutely nail this shit" and did extensive
+research. The idea was to have two "hubs" with an MCU in each. Then, you
+would wire up your LEDs to them. The two hubs communicate wirelessly.
+
+How the hubs communicate to synchronize their states took a bit of
+thinking. I personally think it's the most demanding part of the project
+software-wise.
+
+The essential idea is that each of the two hubs (or MCUs to be precise)
+maintain two states: its own, and its peer's. An input change (e.g. user
+lifted arm) directly changes its own state, not the output. The output is
+determined by both its own state and the peer state. Synchronization
+happens whenever a hub changes its own state, and involves an exchange of
+state over the air.
+
+Imagine two hubs: A and B. All blinkers are off, until user signals left
+on Hub A. Hub A transmits Message 1: `ack=0, peripheral=blink,
+state=left`. (actually this is encoded in a single byte as a bitfield)
+
+Hub B receives Message 1 and takes note that the left blinker of Hub A is
+on. Then it transmits Message 2: `ack=1, peripheral=blink, state=off`,
+which is Hub B's own state. The `ack` stands for acknowledgement; it means
+no reply is necessary. Before I implemented this, the two hubs would keep
+replying to each other forever.
+
+Hub A receives Message 2 and takes note of Hub B's state. At this point
+the state synchronization is complete, and each hub knows both states.
+(They are stored in global variables; our project is full of them. Without
+mutexes or semaphores. Living dangerously.)
+
+Inside each hub, the output function checks both states, and sees that one
+of them wants to turn on the left blinker; so it turns it on. Effectively,
+we can turn on both left blinkers by controlling one side.
+
+Turning off is the same but with `left` replaced with `off`.
+
+One potential issue is, we can't reasonably decide what to do if the user
+gives conflicting commands, like left on Hub A and right on Hub B. Our
+compromise is to just blink both ways, and hopefully the user will notice.
+
+Another interesting thing is that, hubs receive messages in interrupt
+mode, which means it can carry on doing other stuff while waiting for
+a message in the background. We wrote (I wrote) a callback function that
+runs every time we receive something over the XBee. We have a certain
+amount of polling for the switch and stuff, but it's inside of a timer
+interrupt handler. So it's the first embedded project I ever (co-)wrote
+with an empty loop inside of `main()`.
+
+### Checkpoint 1: March 15
+
+It was great to see your prototype working on a breadboard. We managed to
+control some LEDs with a switch in front of the instructors. They asked us
+what we planned to do with the accelerometers. We said (I said) we would
+detect the angle it is held up to relative to ground to trigger the
+blinkers, and deceleration along the "road" axis to trigger the brake
+light. Robert said we managed to eliminate most of the complexity of using
+an IMU (i.e. accelerometer). I asked if it's a good thing or bad thing; he
+said good.
+
+We expressed (I expressed) concerns about us running out of GPIOs on these
+tiny Nucleo boards. Matt replied that we had so-called GPIO expanders, so
+we got one later. It's a PCF8574, running on I²C, which allow
+multiplexing. We use I²C for the accelerometers anyway, so that means
+8 extra pins for free. I noticed that it's pretty unconventional in that
+there's no input/output mode selection; it's kinda scary actually.
+
+Because the output we need are mostly PWM, which is high-frequency, we
+only read GPIO inputs through the expander. This simplifies our driver
+code a lot. (The expander driver, which is 12 lines of code in the most
+permissive definition of code, is one of the few parts in the project not
+authored by me.)
+
+When we left their office, I felt content with our progress. I said:
+"We're gonna make this so even an idiot can use it." Upon which Robert
+replied, "oh, good, so even I can."
+
+A moderate amount of self-deprecation is a healthy communication trick,
+but my arrogance wasn't, especially when it led to me writing this whole
+fucking self-deprecating blogpost. Because you'll see the idiot, in fact,
+is me myself, and I can barely operate the device.
+
+We ordered some light sensors which arrived that day, but later the bag
+containing them was gone, so we ended up replacing them with LDRs (light
+dependent resistors) that did basically the same thing, and arguably
+better on a PCB.
+
+### Anna the Wasp Savior
+
+On 2024-03-17, a wasp got loose in the 373 lab (which may or may not have
+a causal relationship with the presense of a bunch of boy/girl scouts in
+the EECS atrium). I, like many others, was briefly terrified, but calmed
+down to think about a countermeasure.
+
+Anna Huang, the IA, stepped up in a heroic fashion to capture it. She
+grabbed a plastic cup and trapped it against a big box. I offered my
+clipboard and she managed to confine the wasp between it and the cup. We
+walked down the stairs, where I learned that she wasn't about to kill it,
+but to release it. When I asked her where, she initially considered in the
+atrium toward the scouts, but changed her mind and released it outdoors.
+
+She also asked me to take a photo and share it with her, which I did. In
+my final PCB design, I credited her as "IA & Wasp Savior: Anna Huang".
+
+### First Big Mad moment
+
+On 2024-03-17, I wrote the following on the project log.
+
+> Got stuck for 2 hours because
+> 
+> - Amazon says the accelerometer is “LIS3DSH”
+> - The PCB says “LIS3DH”
+> - The chip is marked “DSH”
+> - LIS3DH accepts I2C addresses 0x18 and 0x19
+> - LIS3DSH accepts 0x1d and 0x1e
+> - The chip responds to 0x1d and 0x1e
+> - There is a read-only register on the chip called “WHO_AM_I” that’s
+>   supposed to be 0x33 on DH and 0x3f on DSH
+> - I read it
+> - It’s fucking 0x3b
+> 
+> 17:52: I GOT IT WORKING ON THE BIG NUCLEO WHAT THE FUCK IS DHAPPEBING
+> 
+> 18:05: OK this is fucked up
+> 
+> On the datasheet it says you’d append 0 to the I2C address if you’re
+> writing and 1 if reading
+> 
+> ITS WRONG
+> 
+> I just flipped these and it fuckijng worked
+> 
+> [in huge font size] FUCK YOU ST
+
+In case the text above didn't make enough visual impact, here's what it
+looks like:
+
+![A page of text ending with a giant "FUCK YOU
+ST"](img/w24_wrapup/373_fuck_you_st.png)
+
+### Enclosure & connectors
+
+My teammate and I took a moment to discuss how we wanted to assemble our
+product, and especially how it looks from the outside. I proposed that we
+expose two sockets, on the left & right, for the accelerometers. I forgot
+how the rest of the conversation went, but it involved searching the whole
+lab for vernier calipers. There was none. We ended up using
+a one-meter-long blackboard ruler for a fucking 7x10 cm board.
+
+Earlier in our proposal we mentioned a modular design, where everything is
+hot-pluggable. Halfway through the project, this target began to seem
+unattainable, so we had to make some of them, like the radar and buzzer,
+integrated on the circuit board, be it protoboard or PCB.
+
+3D printing was never my forte, so my teammate is resposible for modeling
+and printing. She did an impeccable job. One problem was that the PLA they
+printed our enclosure with was yellow. Our LEDs are also yellow.
+
+She was like "it's ok, we can tape over the front surface" and she was
+right.
+
+She also laser-cut acrylic with screw holes to hold our circuit boards in
+place.
+
+I planned to use dupont sockets for the accelerometers. STUPID FUCKING
+IDEA. Dupong sockets are good for prototyping, and that's it. There's
+a REASON why you don't see them everywhere. There's a REASON we have
+different cables.
+
+Stupid thing #4: Not using a proper connector.
+
+### Buying more stuff & putting them together
+
+We bought some more stuff.
+
+- Reflective jacket w/ two armbands
+- Velcro
+- Superglue (despite lab rules _technically_ banning them due to
+  insufficient ventilation i dunno bro we got solder irons running full
+  blast here i could inhale this all day (I did inhale this all day
+  later))
+
+In a genius supernova, my teammate(s?) discovered the art of velcro on
+everything. We attached (they attached) the accelerometers to the armbands
+with velcro. It worked fine (mostly).
+
+### Fire alarm!!
+
+On 2024-04-03, at precisely 13:11, the alarm went off so I packed and
+left. Went for a much-needed lunch.
+
+Two days later I bought a bicycle, partly because of this project.
+Spoiler: it wasn't that much useful.
+
+We also demo'd checkpoint two to an IA. We were behind schedule but
+I didn't think it was a big deal. It _was_ a big deal.
+
+### LDR, stupid thing #5, and brainfart #2
+
+My teammate worked on the LDR. Its resistance depended on ambient
+brightness and all you need to do to read it is to wire it up in series
+with a fixed resistor and ADC the voltage between them. We had a lab for
+that.
+
+I found a problem with the implementation: it slowed down the blinking
+considerably. It was because the Nucleo would do an ADC every time we
+enter the output function, which runs every millisecond, and each blink is
+400 ms. ADC takes time and they add up. At this point I knew what problem
+we had. I focused on writing code on my own, without explaining to my
+teammates what I intend to design it. Of course, it led to relatively
+clean code, but it was worthless if nobody understood it.
+
+There are two states of team project code that are acceptable to me:
+
+- Tightly coupled monolith, but everyone understands every line
+- Each person is responsible for one part only, but interface is clearly
+  defined
+
+Our project was neither. It was tightly coupled and almost completely
+authored by a single person. In hindsight, this was catastrophic. It meant
+that in the later part of the project, when time is running out, I was the
+only one who could make software fixes. The core reason is the lack of
+regular team meetups. I sometimes see all four or at least three members
+of certain teams in the lab or in the basement of the Duderstadt. Our
+team, on the other hand, has never had a meeting where everyone was
+present except the brainstorm discussion, the presentation, the evening
+before the demo, and the demo.
+
+I should have motivated my teammates to meet up at least once every week.
+I should have had the motivation to motivate my teammates.
+
+Stupid thing #5: Not meeting regularly.
+
+When did this blog become a landmine of stupidity to embarrass my future
+self? Anyway.
+
+I had a brainfart again. The LDR had higher resistance when it's dark, and
+if we tie one end to VCC and the other end through a 2.2k fixed resistor
+to GND, then less light would give us a lower ADC reading, and if so we
+decrease the brightness of LEDs. Problem was, if the LDR disconnects from
+the circuit (which may happen on a bumpy road), the ADC drops close to 0,
+even if it's the middle of the day. My teammate's workaround is to detect
+if the ADC drops below a certain threshold, at which point we assume the
+LDR dropped out, and fallback to maximum brightness.
+
+My smartass was like, why this complicated? Just reverse the LDR and the
+2.2k, problem solved!
+
+She was like, no…? If I reversed them, then the ADC reading would also be
+upside down, because LDR dropped out == infinite resistance, which would
+be naïvely interpreted as no light either way. So I admitted I was wrong.
+
+### Presentation
+
+A minor part of the project is a presentation, comprised of a pitch that's
+no longer than 30 seconds, and two minutes of slides per person. I skipped
+a lecture to meet with my teammates. A lack of tables prompted us to go
+outside near the swings. It seemed impossible to read the pitch in 30
+seconds so I cut some sentences. I was very much not stressed at all.
+
+Robert used a D4 to randomly pick a person to do the pitch, and he rolled
+a 1, which happened to be me, who stood on the left hand side of the
+classroom. I did it in probably 20 seconds. Nice.
+
+The presentation was quite successful; I did at least one joke about how
+breadboards on bikes make your distributed system a very distributed
+system.
+
+### PCB
+
+On 2024-04-07, according to the project log, I would "now begin working on
+a pcb." A week later, on 2024-04-14, the PCB was "taking shape". The next
+day, I finished and ordered it from PCBWay. But it was already too late.
+
+I have no idea why I did not finish the PCB sooner. It's just plain
+stupid. I should never have trusted the "3-4" days shipping. Production
+took probably one day and a half; shipping was another story. I was too
+optimistic about global shipping. I modeled it as a sphere on an ideal,
+frictionless plane. In reality it's stuck in Shenzhen, stuck in
+Cincinnati, stuck in Romulus.
+
+![DHL shipment updates](img/w24_wrapup/373_dhl.png)
+
+I needed it for demo day; I got it the afternoon after demo day.
+
+Stupid thing #6: Not ordering the PCB sooner.
+
+But at least I had fun designing the PCB, so let's talk about it.
+
+![Front and back of PCB, rendered in KiCad](img/w24_wrapup/373_pcb.png)
+
+The board shape features a notch, just because we can. Take that Apple!
+
+The screw holes align with those on the acrylic my teammate laser cut.
+
+To avoid interfering with microwave black magic, I intentionally shoved
+the antenna part of the radar over the board edge.
+
+We added a couple NFETs in the power paths of some components, including
+the expander and the radar, because they have a criminal record of
+freezing for no reason, rescued only with a hard power cycle.
+
+The silkscreen features two memes:
+
+- "This side toward enemy", stolen from meme below
+
+![An AT&T network interface device, scribbled "this side toward enemy" in
+all caps with a chisel-end
+marker](img/w24_wrapup/373_this_side_toward_enemy.jpg)
+
+- PCBWay, adapted from a meme I made long ago (🎜 just like the hearse you
+  died to get in again 🎜)
+
+![Photo of Gerard Way on a PCB silkscreen, with a blurry "PCBWay" logo
+below for full meme effect](img/w24_wrapup/373_pcbway_meme.png)
+
+Additionally it features the name of everyone in our team, our
+instructors, GSI, and IAs. I feel it is necessary to pay credit to
+everyone who helped. Also you paid for silkscreen you gotta use silkscreen
+
+In terms of timing, I fucked up.
+
+In terms of design, I regret nothing.
+
+### Protoboard (NOTE: avoid at all costs!)
+
+I would pick soldering ten PCBs over one single protoboard. It's just PCBs
+with all the pain and none of the benefits.
+
+Parts? Manual. Wires? Manual. I would NOT like to remember it, no thank
+you. The last time I ever touched a protoboard was in 2022, so
+I apparently forgot how painful it was. A PCB was definitely worth it. So
+why did we solder the protoboard anyway? Well, see stupid thing #6. fml
+
+If I had done the PCB sooner, I could have avoided the protoboard. If
+I just committed to the protoboard (bad idea), I could have avoided the
+PCB work (and money; I hope it can be reimbursed). But I missed the
+chance, and now I had to do both.
+
+Incidentally, this coincided with my obsession with _OK Computer_ (1999),
+notably the track "Let Down".
+
+Project log, 2024-04-19 10:52:
+
+> Woke up to DHL’s email that the ETA of the PCB is Tuesday by end of day.
+> ffs really reconsidering the point of living at this point. Day ruined
+>
+> Backup plan: I’m gonna head to the lab these days and solder up the
+> protoboard with pin sockets, so all the expensive shit are removable.
+
+Devastated, I told my teammates what I did. I was the one who fucked up,
+so I had to take full responsibility. I sat in the lab with my Pinecil,
+and soldered up one (1) board.
+
+Project log, 2024-04-19 22:53:
+
+> God is dead and it was I who killed him with my Pinecil® soldering iron
+> running on 65W USB-PD as I soldered BicycLED on the protoboard
+>
+> This is the worst shit imaginable. Imagine being late by exactly one day
+> and having to devote 2x more work and endure 10x more stress than a PCB.
+>
+> I have to take full responsibility of the PCB not arriving on time, and
+> I am paying the toll with probably one year of my life expectancy for
+> the lead and rosin inhaled today. At my funeral, in lieu of flowers,
+> send fume extractors.
+
+My teammate (the one who did the 3D printing) joined me. I can't thank her
+enough. We spent entire evenings in the lab, just working our asses off.
+The worst part is that, our work is of no worth other than to not miss
+demo day.
+
+Those nights I had _really_ bad insomnia. Like three hours of dread and
+horror. Pressure did not kill me, but I wished it had.
+
+This was the result:
+
+![Protoboard with a bunch of parts soldered on
+it](img/w24_wrapup/373_protoboard_parts.jpg)
+
+![The back side. Bunch of wires, real
+abomination](img/w24_wrapup/373_protoboard_wires.jpg)
+
+### Fuck it
+
+How the fuck have I written 6k words already?? This is way too long for
+a blogpost. If you're still reading you should go for a glass of water or
+something.
+
+### FUCK YOU ST / FUCK YOU NXP
+
+On 2024-04-11, we were working on the lab computer and found a bug where
+it doesn't regenrate template code when we modify the configs. This led to
+the second fuck you in our project log.
+
+> [W]e moved the buzzer to TIM16. But the `TIM_HandleTypeDef htim16`
+> wasn’t showing up, and the GPIO macros for BUZZER remained unchanged.
+> I restarted the IDE, but it refuses to update code no matter how many
+> times I hit “generate code”.
+>
+> I zipped the project and imported it into my machine. It worked
+> instantly.
+>
+> [in huge font] FUCK YOU ST
+
+On 2024-04-21, we were honored to present the third fuck you.
+
+> [Redacted] and I went ahead and soldered the second board with
+> insurmountable pain. But the PCF8574P we got last time did not work.
+> When we hooked up a logic analyzer, it never acks.
+>
+> I noticed that the two chips we have are different. The first one that
+> works is TI; the other is NXP. However, their datasheets are practically
+> the same.
+>
+> I wrote a loop to iterate I2C addresses from 0x20 to 0x80. It replied to
+> 0x38. According to the datasheet, this address belongs to PCF8574A, but
+> the chip we have is marked PCF8574P, the DIP-16 package of PCF8574,
+> without the A.
+>
+> [in huge font and bold face] FUCK YOU NXP
+
+oh wow I went full linus mode
+
+### Final evenings
+
+Things that happened the evening two days before demo day:
+
+- All four of us showed up (surprise surprise)
+- We attempted to power the circuit with 12V on VIN
+- Why is it so hot??
+
+Stupid thing #7: Not testing power earlier
+
+- It turns out if you power the Nucleo with 12V (max voltage), the MCU
+  gets really hot which shouldn't happen if you have a good voltage
+  regulator
+- We tried USB VBUS on the 5V pin next to VIN
+- The MCU just straight out doesn't work
+- ????????
+- Quick, get a buck converter
+- It's bulky
+- Teammate: Fuck it, just power it over USB!
+- Me: No… ok fine
+- Uh oh, we have to make a hole in the lid
+
+Things that happened the evening just before demo day:
+
+- Teammate: Hey here's a lid with a hole I just laser cut
+- Oh look a perfect fit
+- WHY IS EVERYTHING FAILING EVERY OTHER SECOND???
+- OH GOD OH FUCK SOLDER UP A RESET BUTTON
+- MORE VELCRO!!!
+- OK we did it!
+- Me: Let's install it on my bike!
+- [I bring my teammates to my bike and attract a raccoon]
+- We install stuff
+- It kinda works but wonky
+- Fuck it let's not
+- Take everything off, decide to present them on a table instead
+- What about the poster?
+- Teammate: Oh yeah the poster. It's at my apartment. There's a blank
+  space called "assembled product" which we can finally patch
+- Me: yeah let's print it
+- [We go to the color printer at the Duderstadt and print the pictures]
+- Me: hey let's print the project log it's got three big fuck yous it's
+  funy
+- [I did not wait for their approval]
+- The cover:
+
+![BicycLED project log. Warning: explicit language. (parental advisory
+explicit content sticker typically seen on
+records)](img/w24_wrapup/373_log_cover.png)
+
+The bicycle:
+
+![Two clunky boxes barely holding on
+a bicycle](img/w24_wrapup/373_bike.jpg)
+
+### Demo day. Fucking finally
+
+We were glad it was over. We're just… so done, literally and
+metaphorically. Not sure about how other teams were doing, but we were
+dying of boredom.
+
+I got there early and tested out the stuff we had. The accelerometers
+were… still wonky. Then a few wires came off after we set up the table.
+Never would have happend if I had used a proper connector that stays in
+place. Glad I took my Pinecil with me. The faithful iron fixed like three
+faulty wirings. Truly the MVP of the day.
+
+I skipped two lectures for the demo. The professor whose lecture I was
+supposed to be at (💀) showed up and was one of the first to check out all
+the exhibits. He's my 311 (analog circuits) professor. "There's BJTs in
+here. You would be proud," I said.
+
+"I'm already proud of you," he replied.
+
+Then it was time to do two things:
+
+- Avoid attracting attention, and in the case we failed, explain to the
+  curious person what our project does (spoiler: not a lot)
+- The graded demo
+
+We missed a chance to do the graded demo once, because I was fixing the
+wires. Once we got the chance to get the GSI back, we demo'd all the shit
+we did. He was like "huh cool" and scribbled some notes on his clipboard.
+
+Later the instructors came and to our horror the accelerometers failed.
+(tbf they intermittently failed regardless of who we're presenting to.)
+I pressed the reset button a few times hoping they didn't notice, and it
+finally worked once (probably a false positive). Then Matt grew interested
+in the Doppler radar. He tried to trigger it by moving his body in the
+vicinity of the radar. We had set the threshold to the highest possible to
+prevent false positives (it was still sensitive af), to the point the
+buzzer only honks if you're moving within a few centimeters away from the
+radar. We figured as long as it's for a demo, it'd be fine. And it was
+fine. It didn't honk all the time. It honked some of the time. And that's
+good enough.
+
+Like, the project was a failure, so what? There's nothing I could do at
+this point. I really hope we didn't disappoint the instructors. Not as
+much as I disappointed myself.
+
+I was so done with everything. I pulled up the 473 (advanced embedded
+systems) slides and read them to pull me out of this torture.
+
+We wrapped up all our stuff at 14:00 at the first convenience so we can
+say goodbye to this crap.
+
+### PCB (the sequel)
+
+The moment I came back home, I saw the PCB lying at my door.
+
+The next day I went to the lab… I soldered it with my teammate… Then a few
+days later I demo'd it to Matt. I made an excuse that the accelerometers
+were fried (they probably were, but I was too lazy to check). He sent
+Robert an email that the PCB in our report is a real thing that exists.
+
+Then we took (I took) the project apart and returned the public assets
+back into their respective bins. You won't believe how many USB cables we
+used for the Nucleos, logic analyzers, XBee configuration dongles, etc.
+
+Then it's just a matter of submitting a bunch of end-of-project stuff like
+our code and my PCB design files. And the report. In the report we're
+asked to estimate our complexity points. The goal is 4 (1 for every
+person). Here's our estimate (based on a reference the instructors gave us
+early on):
+
+> - Accelerometers: 0.67
+> - Light sensor: 0.25
+> - Doppler radar: 0.25
+> - XBee: 0.50
+> - Synchronization protocol: 0.50
+> - PWM + Transistor: 0.25
+> - PCF8574P/AP: 0.50
+> - 3D printing & laser cutting: 0.50
+> - PCB & protoboard: 0.67
+> - Total: 4.09
+
+This was based on my teammate's estimate, and I adjusted it while keeping
+the sum over 4. The Doppler radar doesn't actually deserve that much
+complexity; it's just two GPIOs. Infineon did all the analog magic for us
+(which disappointed Matt, who thought it would at least expose some of the
+non-microwave signals for us to do some Fourier with).
+
+The PCFs weren't this complex either. Probably 0.33 at best.
+
+Oh, yeah, and my insomnia is healed.
+
+### Mistakes (again)
+
+I finally dumped everything I want to say about this cursed project of
+ours. Now, let us recap my mistakes.
+
+- I am a poor collaborator
+- Taking too many time-consuming courses
+- I did not ask my team to reach a consensus before beginning work
+- An incorrect, idealistic idea about course projects
+- Not using a proper connector
+- Not synchronizing progress with teammates often
+- Not testing power and heat dissipation early on
+- Designed and ordered PCBs too late
+
+So, to address the problems, all I need to do is:
+
+- __Design everything early__
+- Don't take more than 2 EECS courses per semester
+- Meet with majority of team once per week
+- Discuss project goals
+- Clarify every detail about project goal; when in doubt, leave a note or
+  mark as TODO
+- Use a proper connector for everything
+- Test in real environments as soon as possible
+
+### Final word on project
+
+I take the L.
+
+That said, I still sulk over this course. I feel that I did not release my
+full potential. Indeed, it is hard to compete with other teams of four in
+a team of an effective size of 2.5. But only losers blame teammates.
+Victors blame themselves, fengshui, and the phase of moon. I believe the
+solar eclipse may be part of the conspiracy.
+
+## Verdict
+
+Good course, but don't take it with 482. Useful if you want an extensive
+set of knowledge, so that when you need to make some hardware you know
+where to start. The course is not enough to make anything that would
+instantly sell though. That would require expert knowledge in industrial
+operation, market touching, and probably a lot of money.
+
+I re-emphasize that my experience with the project is not representative
+of the typical 373 experience.
+
+## Future?
+
+Halfway through writing this blogpost, I tooted
+
+> tfw you fucked up a project so bad you're writing a blogpost about the
+> mistakes you made and you're at the 6,458 words mark
+>
+> the #1 advice to not fuck up projects is to not do projects. thanks for
+> coming to my ted talk
+>
+> that said i voluntarily signed up for a project very similar in
+> logistics next semester because i have a habit ofovercompensating [sic]
+
+Yes, I enrolled in 473. I only plan to take a maximum of 15 credits next
+semester, and will drop 3 if my IA application is accepted. This should
+make workload reasonable.
+
+Mark Brehob will be teaching 473, with Matt Smith still being lab
+instructor, which is great news because they're both great and I know
+both of them. But probably everyone does.
+
+And now that I have a bicycle, I can ride to north campus whenever I want.
+
+I already have like two ideas brewing in my head. I will look for
+teammates myself based on project interest this time. I really hope it
+doesn't bust again.
+
+Damn it, "Let Down" just came on again. Better wrap this up before the sad
+part.
diff --git a/docs/umich/w24_wrapup.md b/docs/umich/w24_wrapup.md
index 0f4baf7..37e5fad 100644
--- a/docs/umich/w24_wrapup.md
+++ b/docs/umich/w24_wrapup.md
@@ -13,4 +13,5 @@ is impossible to cover all of them in one single blogpost, so I will split
 them up into individual articles, listed below.
 
 - [EECS 482, Intro to OS](w24_482.md)
+- [EECS 373, Intro to Embedded System Design](w24_373.md)
 - Other courses WIP