The Name of the Game

On Saturday, August 2, 2025, we kicked off our weekend classes initiative at MPSTME run by DesignBuildFly at MPSTME and AeroXperts and hosted under the ASLS banner, with a first session that did exactly what a good boot sequence should: power on, check the fundamentals, and get every mind on the same clock. The class, Embedded Systems & Programming (Session 1), was led by our co-lead Zarvan Movdawalla, a final-year student and embedded-systems specialist who has spent the last few years living where hardware meets code. While the series is designed primarily for first-years, it’s open to anyone curious about how electronics, ICs, and computers actually work. And yes, we deliberately kept this one conceptual—no code, no breadboards—because getting the mental model right on Day 1 makes everything after that faster, safer, and a lot more fun.

We began with the “why.” Why embedded systems at all? Because the devices you use every day—watches, drones, bikes with smart controllers, headphones, even your phone’s sensors—are governed by small, efficient computers that don’t look like “computers” at first glance. Zarvan framed the field as a stack of ideas rather than a shopping list of components: signals become information; information becomes decisions; decisions become physical action. Once you see that pipeline, the vocabulary—GPIO, PWM, ADC, ISR—stops feeling like jargon and starts feeling like levers you can pull on purpose.

From there, we zoomed into the humble microcontroller. Not a general-purpose processor trying to be everything for everyone, but a focused brain with memory, timers, communication buses, and IO right on the die. The class met “Arduino” as a platform rather than a mystery box: a developer-friendly way to access a microcontroller’s capabilities with predictable pinouts and a sane toolchain. We talked about what really happens when you press Upload—how your code becomes instructions, how those instructions live in flash, how they run from reset vector to main loop, and why the architecture’s interrupt model matters more than any library call you’ll memorize in week two.

If there was a single habit we wanted students to adopt from the start, it was reading the datasheet. Not cover-to-cover, not as a rite of passage—just enough to answer concrete questions: What’s the operating voltage range? What’s the absolute maximum current per pin? How do I configure a timer to get a 1 kHz PWM? Which communication peripherals are multiplexed on which pins? Zarvan’s take was simple: treat the datasheet as a map, not a novel. Learn to find the block diagram, skim the electrical characteristics table, and identify the registers that control the thing you care about. You don’t need to memorize everything; you need to know what to look for and where it lives.

That naturally led to the classic digital vs. analog line—where it is, why it matters, and how crossing it changes your responsibilities. In digital land, your world is clocks, logic levels, and timing budgets; in analog land, your world is noise, impedance, and tolerances that don’t care about your neatly indented code. We explored how an ADC samples a waveform, why reference voltages are sacred, and how ignoring grounding and decoupling turns a clean design into a haunted house. The message wasn’t “analog is scary,” but “analog is real”-and honoring it early prevents late-night debugging later.

We closed the core content by assembling a working mental picture of how a computer is built from parts: transistors give rise to logic gates; gates become adders and registers; registers sit inside a datapath that a control unit steers according to an instruction set; memory holds both data and instructions, and a clock advances the whole show. You don’t need to be a semiconductor physicist to write good firmware, but a sketch of this map helps you reason about performance, timing, and power—especially when your system has to meet the real world halfway.

Then came the fun bit: we rolled in our AeroXperts drone for a live look at an embedded system that actually has to fly. Seeing control loops, sensor fusion, and power electronics show up in one object grounds the theory in something you can hear and feel. During Q&A, the room pulled us into two deep dives: ARM architecture (why the Cortex-M family dominates embedded, what a load/store ISA means in practice, how interrupts and exception priorities are handled) and a high-level tour of the Apple M4 (how big-core vs. efficiency-core design balances performance and power, why cache hierarchies matter, and what “systems on chips” buy you when you care about thermals and latency). The point wasn’t to turn everyone into CPU designers in 20 minutes; it was to illustrate that the same architectural ideas scale from a microcontroller on a dev board to world-class silicon in a laptop.

If you couldn’t make it, here’s what we wanted everyone to walk away with, in plain language woven through the discussion: a clear sense of what a microcontroller is—not a small “computer” in the abstract but a purpose-built control unit with IO on tap; a practical attitude toward datasheets as the single source of truth; a first intuition for where digital stops and analog starts; a systems-level picture of how computers compose from components; and a feel for how programming maps onto hardware—not “magic words make LEDs blink,” but “instructions orchestrate peripherals that talk to the physical world.”

We intentionally didn’t write code this time. That restraint matters. Great tooling can make it feel like you’re productive before you understand what you’re doing; great habits make you productive when the tooling gets out of the way. Starting with concepts gives us a shared language so that, next session, when we touch a register, scope a pin, or hunt a race condition, everyone can see the why behind the what.

“Foundations reduce friction. Once you know how the silicon thinks, every library becomes a choice—not a crutch.”

— Zarvan Movdawalla

Session 2 will keep us in embedded but shift to a hands-on lab: programming and hardware on the bench. We’ll move from mental models to muscle memory—configuring IO, reading sensors, and pushing real-time behavior we can measure. If you’re a first-year curious about where to start, or a senior who wants to refresh fundamentals with intent, you’re welcome. Bring your questions, bring your curiosity, and bring that willingness to look under the hood.

DesignBuildFly at MPSTME, AeroXperts and our weekend classes (currently under ASLS, with a naming refresh on the way) are here to build a learning loop that is weekly, practical, and open. If this first session was our boot sequence, the next ones are our main loop: read, think, act—repeat. See you at the lab bench.