diff options
| -rw-r--r-- | docs/umich/img/w24_wrapup/373_bike.jpg | bin | 0 -> 351927 bytes | |||
| -rw-r--r-- | docs/umich/img/w24_wrapup/373_dhl.png | bin | 0 -> 184253 bytes | |||
| -rw-r--r-- | docs/umich/img/w24_wrapup/373_fuck_you_st.png | bin | 0 -> 123750 bytes | |||
| -rw-r--r-- | docs/umich/img/w24_wrapup/373_log_cover.png | bin | 0 -> 41935 bytes | |||
| -rw-r--r-- | docs/umich/img/w24_wrapup/373_pcb.png | bin | 0 -> 240176 bytes | |||
| -rw-r--r-- | docs/umich/img/w24_wrapup/373_pcb_back.jpg | bin | 0 -> 540111 bytes | |||
| -rw-r--r-- | docs/umich/img/w24_wrapup/373_pcb_front.jpg | bin | 0 -> 258387 bytes | |||
| -rw-r--r-- | docs/umich/img/w24_wrapup/373_pcbway_meme.png | bin | 0 -> 219100 bytes | |||
| -rw-r--r-- | docs/umich/img/w24_wrapup/373_protoboard_parts.jpg | bin | 0 -> 321334 bytes | |||
| -rw-r--r-- | docs/umich/img/w24_wrapup/373_protoboard_wires.jpg | bin | 0 -> 358429 bytes | |||
| -rw-r--r-- | docs/umich/img/w24_wrapup/373_this_side_toward_enemy.jpg | bin | 0 -> 30447 bytes | |||
| -rw-r--r-- | docs/umich/w24_373.md | 1081 | ||||
| -rw-r--r-- | docs/umich/w24_wrapup.md | 1 |
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 Binary files differnew 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 Binary files differnew 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 Binary files differnew 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 Binary files differnew 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 Binary files differnew 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 Binary files differnew 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 Binary files differnew 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 Binary files differnew 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 Binary files differnew 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 Binary files differnew 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 Binary files differnew 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. + + + +▲ Back hub + + + +▲ 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: + + + +### 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. + + + +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. + + + +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 + + + +- PCBWay, adapted from a meme I made long ago (🎜 just like the hearse you + died to get in again 🎜) + + + +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: + + + + + +### 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: + + + +The bicycle: + + + +### 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 |
