Sarmad Gulzar

This site now runs on Zola

2026-07-07T00:00:00+00:00
Every few years I rebuild my website, and every few years I swear it’s the last time. This is that time, again.
The new stack is Zola</a> — a static site generator that ships as a single binary. No node_modules</code>, no plugin ecosystem to babysit, no build pipeline that quietly rots while I’m not looking. You write Markdown, it emits HTML, and the whole site builds in a few milliseconds.
`What I optimized for</h2> A short list, in order:`Reading. Text set in a proper serif, a measure around 70 characters, generous line height. Nothing competes with the words.</li> Speed. There is no JavaScript on this site. Fonts are self-hosted. A post is one HTML file and one stylesheet.</li> Longevity. Content is Markdown files in a git repo. If Zola disappears tomorrow, the writing survives untouched.</li> </ol> Dark mode follows your system preference — no toggle, no flash, no cookie remembering your choice, because there’s no choice to remember. If you want the details: the fonts are Newsreader</a> for prose and IBM Plex Mono for dates and code, syntax highlighting is done at build time by Zola’s built-in highlighter, and the feed lives at /atom.xml</a> if RSS is your thing. It usually is, for the right people.



Two things at once: Embassy tasks
2026-06-30T00:00:00+00:00
Part three left us with a program that sleeps beautifully but can only wait for one thing. The fix is to give each independent job its own task: one watches the button, one blinks a heartbeat LED, and the executor interleaves them. The code is crates/03-digital-input-async-multitask</code></a>:</p>
#</span>!</span>[</span>no_std</span>]</span></span>
#</span>!</span>[</span>no_main</span>]</span></span>
</span>
use</span> defmt</span>::</span>{</span>info</span>,</span> unwrap</span>}</span>;</span></span>
use</span> embassy_nrf</span>::</span>gpio</span>::</span>{</span>Input</span>,</span> Level</span>,</span> Output</span>,</span> OutputDrive</span>,</span> Pull</span>}</span>;</span></span>
use</span> embassy_time</span>::</span>Timer</span>;</span></span>
use</span> {</span>defmt_rtt </span>as</span> _</span>,</span> panic_probe </span>as</span> _</span>}</span>;</span></span>
</span>
#</span>[</span>embassy_executor</span>::</span>task</span>]</span></span>
async</span> fn</span> button_task</span>(</span>mut</span> button</span>:</span> Input</span><</span>'</span>static</span>></span>,</span> mut</span> red_led</span>:</span> Output</span><</span>'</span>static</span>></span>)</span> {</span></span>
    loop</span> {</span></span>
        button</span>.</span>wait_for_low</span>(</span>)</span>.</span>await</span>;</span></span>
        red_led</span>.</span>set_low</span>(</span>)</span>;</span> //</span> Red LED ON</span></span>
        info!</span>(</span>"</span>Button pressed!</span>"</span>)</span>;</span></span>
</span>
        button</span>.</span>wait_for_high</span>(</span>)</span>.</span>await</span>;</span></span>
        red_led</span>.</span>set_high</span>(</span>)</span>;</span> //</span> Red LED OFF</span></span>
        info!</span>(</span>"</span>Button released!</span>"</span>)</span>;</span></span>
    }</span></span>
}</span></span>
</span>
#</span>[</span>embassy_executor</span>::</span>main</span>]</span></span>
async</span> fn</span> main</span>(</span>spawner</span>:</span> embassy_executor</span>::</span>Spawner</span>)</span> {</span></span>
    let</span> p</span> =</span> embassy_nrf</span>::</span>init</span>(</span>Default</span>::</span>default</span>(</span>)</span>)</span>;</span></span>
</span>
    info!</span>(</span>"</span>Initializing the onboard Red LED...</span>"</span>)</span>;</span></span>
    let</span> onboard_red</span> =</span> Output</span>::</span>new</span>(</span>p</span>.</span>P0_26</span>,</span> Level</span>::</span>High</span>,</span> OutputDrive</span>::</span>Standard</span>)</span>;</span></span>
</span>
    info!</span>(</span>"</span>Initializing the heartbeat LED...</span>"</span>)</span>;</span></span>
    let</span> mut</span> heartbeat</span> =</span> Output</span>::</span>new</span>(</span>p</span>.</span>P0_02</span>,</span> Level</span>::</span>Low</span>,</span> OutputDrive</span>::</span>Standard</span>)</span>;</span></span>
</span>
    info!</span>(</span>"</span>Initializing the button...</span>"</span>)</span>;</span></span>
    let</span> button</span> =</span> Input</span>::</span>new</span>(</span>p</span>.</span>P0_03</span>,</span> Pull</span>::</span>Up</span>)</span>;</span></span>
</span>
    //</span> Move ownership of the button and red LED into another task.</span></span>
    spawner</span>.</span>spawn</span>(</span>unwrap!</span>(</span>button_task</span>(</span>button</span>,</span> onboard_red</span>)</span>)</span>)</span>;</span></span>
</span>
    loop</span> {</span></span>
        heartbeat</span>.</span>toggle</span>(</span>)</span>;</span></span>
        info!</span>(</span>"</span>Heartbeat: </span>{</span>}</span>"</span>,</span> heartbeat</span>.</span>get_output_level</span>(</span>)</span>)</span>;</span></span>
        Timer</span>::</span>after_millis</span>(</span>1000</span>)</span>.</span>await</span>;</span></span>
    }</span></span>
}</span></span></code></pre>
The button loop is the same code as part three, lifted verbatim into its own function. What’s new is everything around it.</p>
Anatomy of a task</h2>
#[embassy_executor::task]</code> turns an async function into something the executor can run independently. Tasks are statically allocated — no heap, remember — so the macro reserves their memory at compile time. That’s also why the arguments are Input<'static></code> and Output<'static></code>: a task can outlive main</code>’s stack frame, so it can only hold resources that live for the whole program.</p>
The hand-off is ordinary Rust ownership:</p>
spawner</span>.</span>spawn</span>(</span>unwrap!</span>(</span>button_task</span>(</span>button</span>,</span> onboard_red</span>)</span>)</span>)</span>;</span></span></code></pre>
button</code> and onboard_red</code> move</em> into the task. After this line, main</code> can’t touch them — try, and the compiler stops you. The same rule that made greet(name)</code> a one-shot in a desktop program here guarantees that exactly one task drives each pin. No mutex, no “who owns the LED” bug class at all.</p>
Meanwhile main</code> — which is itself just the first task — keeps the heartbeat:</p>
loop</span> {</span></span>
    heartbeat</span>.</span>toggle</span>(</span>)</span>;</span></span>
    Timer</span>::</span>after_millis</span>(</span>1000</span>)</span>.</span>await</span>;</span></span>
}</span></span></code></pre>Cooperative, not preemptive</h2>
Both loops are infinite, and both run. The trick is that neither ever blocks</em>: each runs for a few microseconds, hits an .await</code>, and yields. The executor wakes whichever task’s event arrived — timer tick or pin change — runs it to its next await, and sleeps again. Press the button mid-heartbeat and both LEDs do their jobs, on time, with the CPU asleep for the overwhelming majority of every second.</p>
That’s the payoff of the whole arc. In four small programs we went from a busy-waiting blinky to genuinely concurrent, interrupt-driven, sleep-when-idle firmware — and the concurrency cost us no threads, no RTOS config, and not one unsafe</code> block. From here the same pattern extends to the board’s headline feature: tasks that talk BLE. Watch the repo</a> and the playlist</a> for what comes next.</p>


Waiting for a button instead of polling it
2026-06-27T00:00:00+00:00
Part two ended with a diagnosis: polling burns the CPU to answer a question the hardware could answer for free. The nRF52840 has a peripheral — GPIOTE, “GPIO tasks and events” — whose whole job is to raise an interrupt when a pin changes. Embassy wraps it in an async method, and the fix is two lines. The code is crates/02-digital-input-async</code></a>:</p>
#</span>!</span>[</span>no_std</span>]</span></span>
#</span>!</span>[</span>no_main</span>]</span></span>
</span>
use</span> defmt</span>::</span>info</span>;</span></span>
use</span> embassy_nrf</span>::</span>gpio</span>::</span>{</span>Input</span>,</span> Level</span>,</span> Output</span>,</span> OutputDrive</span>,</span> Pull</span>}</span>;</span></span>
use</span> {</span>defmt_rtt </span>as</span> _</span>,</span> panic_probe </span>as</span> _</span>}</span>;</span></span>
</span>
#</span>[</span>embassy_executor</span>::</span>main</span>]</span></span>
async</span> fn</span> main</span>(</span>_spawner</span>:</span> embassy_executor</span>::</span>Spawner</span>)</span> {</span></span>
    let</span> p</span> =</span> embassy_nrf</span>::</span>init</span>(</span>Default</span>::</span>default</span>(</span>)</span>)</span>;</span></span>
</span>
    info!</span>(</span>"</span>Initializing the onboard Red LED...</span>"</span>)</span>;</span></span>
    let</span> mut</span> onboard_red</span> =</span> Output</span>::</span>new</span>(</span>p</span>.</span>P0_26</span>,</span> Level</span>::</span>High</span>,</span> OutputDrive</span>::</span>Standard</span>)</span>;</span></span>
</span>
    info!</span>(</span>"</span>Initializing the button...</span>"</span>)</span>;</span></span>
    let</span> mut</span> button</span> =</span> Input</span>::</span>new</span>(</span>p</span>.</span>P0_03</span>,</span> Pull</span>::</span>Up</span>)</span>;</span></span>
</span>
    loop</span> {</span></span>
        button</span>.</span>wait_for_low</span>(</span>)</span>.</span>await</span>;</span></span>
        onboard_red</span>.</span>set_low</span>(</span>)</span>;</span></span>
        info!</span>(</span>"</span>Button pressed!</span>"</span>)</span>;</span></span>
</span>
        button</span>.</span>wait_for_high</span>(</span>)</span>.</span>await</span>;</span></span>
        onboard_red</span>.</span>set_high</span>(</span>)</span>;</span></span>
    }</span></span>
}</span></span></code></pre>
Same wiring, same pull-up, same active-low logic. The if</code>/else</code> is gone, replaced by two awaits:</p>
button</span>.</span>wait_for_low</span>(</span>)</span>.</span>await</span>;</span>   //</span> sleep until pressed</span></span>
//</span> ...</span></span>
button</span>.</span>wait_for_high</span>(</span>)</span>.</span>await</span>;</span>  //</span> sleep until released</span></span></code></pre>What actually happens at the await</h2>
wait_for_low()</code> returns a future. When the executor polls it and the pin is still high, the future registers with GPIOTE — “raise an interrupt when this pin goes low” — and returns Pending</code>. The executor has nothing else to run, so it executes a wait-for-interrupt instruction and the core stops. Not “loops quickly”: stops.</p>
When you press the button, GPIOTE fires the interrupt, the interrupt handler wakes the task, and execution resumes on the line after the .await</code>. The log tells the story: instead of Not Pressed...</code> scrolling by endlessly, the terminal is silent until the moment you press.</p>
Note one small signature change: the button is now let mut button</code>. The async wait methods take &mut self</code>, because registering for a pin event mutates the input’s GPIOTE channel state — the type system again tracking who’s allowed to touch the hardware.</p>
The structural win</h2>
Reading top to bottom, the loop is a plain-language description of the behavior: wait for press, LED on, wait for release, LED off.</em> There’s no state machine tracking “was it pressed last time I checked”, because the control flow is</strong> the state. This is the thing Embassy sells: interrupt-driven firmware that reads like blocking code.</p>
One task still has a limit, though: this main</code> can only wait for one thing at a time. If we also wanted a heartbeat LED blinking on its own schedule, this loop has nowhere to put it — waiting on the button means not counting time, and vice versa. Running both at once is what Embassy tasks</em> are for, and that’s the finale.</p>


Structs, enums, and pattern matching
2026-06-15T00:00:00+00:00
Ownership keeps your memory correct. The type system keeps your logic</em> correct — and Rust’s is built around one idea borrowed from functional languages: model your data so that invalid states simply can’t be constructed.</p>
Structs</h2>
Structs are the familiar part — named fields, no surprises:</p>
struct</span> Post</span> {</span></span>
    title</span>:</span> String</span>,</span></span>
    published</span>:</span> bool</span>,</span></span>
    views</span>:</span> u64</span>,</span></span>
}</span></span></code></pre>Enums are the good part</h2>
A Rust enum isn’t a list of integer constants — each variant can carry its own data:</p>
enum</span> Status</span> {</span></span>
    Draft</span>,</span></span>
    Scheduled</span> {</span> publish_at</span>:</span> String</span> }</span>,</span></span>
    Published</span> {</span> views</span>:</span> u64</span> }</span>,</span></span>
}</span></span></code></pre>
A scheduled post has</em> a publish date; a published one has</em> a view count; a draft has neither. There is no way to construct a draft with views. The bug where you read publish_at</code> on a published post isn’t caught at runtime — it’s unwritable.</p>
Match makes it total</h2>
match</code> forces you to handle every variant:</p>
fn</span> describe</span>(</span>status</span>:</span> &</span>Status</span>)</span> -></span> String</span> {</span></span>
    match</span> status</span> {</span></span>
        Status</span>::</span>Draft</span> =></span> "</span>draft</span>"</span>.</span>to_string</span>(</span>)</span>,</span></span>
        Status</span>::</span>Scheduled</span> {</span> publish_at</span> }</span> =></span> format!</span>(</span>"</span>goes live </span>{</span>publish_at</span>}</span>"</span>)</span>,</span></span>
        Status</span>::</span>Published</span> {</span> views</span> }</span> =></span> format!</span>(</span>"</span>{</span>views</span>}</span> views</span>"</span>)</span>,</span></span>
    }</span></span>
}</span></span></code></pre>
Delete an arm and the program stops compiling. Add a new variant next year, and the compiler lists every match</code> in the codebase you now need to update. This is exhaustiveness checking, and once you’ve shipped refactors with it, going back to a language without it feels like removing the handrails.</p>
The standard library runs on this machinery: Option<T></code> is an enum (Some</code>/None</code>) that replaces null, and Result<T, E></code> (Ok</code>/Err</code>) replaces exceptions. You’ve now seen everything they’re made of — which is exactly where the next part picks up.</p>


Ownership, moves, and borrows
2026-06-08T00:00:00+00:00
Rust’s memory model fits in three sentences:</p>

Every value has exactly one owner</strong>.</li>
When the owner goes out of scope, the value is dropped</strong> (freed).</li>
Ownership can be moved</strong>, or the value can be borrowed</strong> — but the borrows have rules.</li>
</ol>
That’s it. No garbage collector pausing your program, no free()</code> to forget. The compiler tracks owners the way a type checker tracks types.</p>
Moves</h2>
Assignment of heap-owning types transfers ownership:</p>
let</span> a</span> =</span> String</span>::</span>from</span>(</span>"</span>hello</span>"</span>)</span>;</span></span>
let</span> b</span> =</span> a</span>;</span>                  //</span> ownership moves to b</span></span>
//</span> println!("{a}");         // error: value borrowed after move</span></span></code></pre>
If you actually want two copies, say so explicitly with a.clone()</code>. Rust makes the expensive thing visible instead of doing it silently.</p>
Borrows</h2>
Most of the time you don’t want to give a value away — you just want to let a function look at it. That’s a reference, written &</code>:</p>
fn</span> shout</span>(</span>text</span>:</span> &</span>String</span>)</span> -></span> String</span> {</span></span>
    text</span>.</span>to_uppercase</span>(</span>)</span></span>
}</span></span>
</span>
let</span> word</span> =</span> String</span>::</span>from</span>(</span>"</span>hello</span>"</span>)</span>;</span></span>
let</span> loud</span> =</span> shout</span>(</span>&</span>word</span>)</span>;</span>    //</span> word is borrowed...</span></span>
println!</span>(</span>"</span>{</span>word</span>}</span> -> </span>{</span>loud</span>}</span>"</span>)</span>;</span> //</span> ...and still usable here</span></span></code></pre>
Borrows come in two flavors, and the rules are asymmetric on purpose:</p>

Any number of shared</strong> borrows (&T</code>) may exist at once — readers don’t conflict.</li>
A mutable</strong> borrow (&mut T</code>) must be exclusive</em> — one writer, and no readers while it lives.</li>
</ul>
let</span> mut</span> nums</span> =</span> vec!</span>[</span>1</span>,</span> 2</span>,</span> 3</span>]</span>;</span></span>
let</span> first</span> =</span> &</span>nums</span>[</span>0</span>]</span>;</span>       //</span> shared borrow</span></span>
//</span> nums.push(4);            // error: can't mutate while borrowed</span></span>
println!</span>(</span>"</span>{</span>first</span>}</span>"</span>)</span>;</span>        //</span> borrow ends here</span></span>
nums</span>.</span>push</span>(</span>4</span>)</span>;</span>               //</span> now it's fine</span></span></code></pre>
That push</code> error is the borrow checker preventing a real bug: pushing might reallocate the vector, leaving first</code> pointing at freed memory. In C++ this compiles and corrupts; in Rust it doesn’t compile.</p>
The discipline feels strict for a week. Then you notice you’ve stopped thinking about a whole category of bugs, and it starts feeling like a seatbelt. Next: how structs and enums let you model data precisely.</p>


Why Rust, and how to think about it
2026-06-01T00:00:00+00:00
Every language makes a trade. Python trades speed for ergonomics. C trades safety for control. Rust’s pitch is that one of those trades was never necessary: you can have memory safety without</em> a garbage collector, if the compiler is willing to do a lot more work at compile time — and if you’re willing to tell it more about your intentions.</p>
That second clause is the whole learning curve. Rust isn’t hard because the syntax is exotic; it’s hard because the compiler enforces rules about who owns what</em> that other languages leave implicit. Once you internalize those rules, the errors stop feeling like fights and start feeling like code review from a very fast, very pedantic colleague.</p>
Setup</h2>
One command installs the toolchain:</p>
curl</span> -</span>-proto</span> '</span>=https</span>'</span> -</span>-tlsv1.2</span> -</span>sSf</span> https://sh.rustup.rs</span> |</span> sh</span></span></code></pre>
That gives you rustc</code> (the compiler), cargo</code> (build tool and package manager), and rustup</code> (toolchain manager). You will almost never invoke rustc</code> directly — cargo</code> runs the show:</p>
cargo</span> new</span> hello</span> &&</span> cd</span> hello</span></span>
cargo</span> run</span></span></code></pre>The first program worth reading</h2>
Skip “Hello, world” — you can guess it. Here’s the smallest program that shows Rust’s personality:</p>
fn</span> main</span>(</span>)</span> {</span></span>
    let</span> name</span> =</span> String</span>::</span>from</span>(</span>"</span>Sarmad</span>"</span>)</span>;</span></span>
    greet</span>(</span>name</span>)</span>;</span></span>
    //</span> greet(name);  // <- uncomment this and the program stops compiling</span></span>
}</span></span>
</span>
fn</span> greet</span>(</span>name</span>:</span> String</span>)</span> {</span></span>
    println!</span>(</span>"</span>Hello, </span>{</span>name</span>}</span>!</span>"</span>)</span>;</span></span>
}</span></span></code></pre>
Calling greet(name)</code> moves</em> the string into the function. After that line, main</code> doesn’t own it anymore, and the compiler will refuse to let you use it. That refusal — checked entirely at compile time, costing nothing at runtime — is the core of the language. Everything else in this series is a consequence of it.</p>
Next up: what “ownership” means precisely, and how borrowing lets you share values without giving them away.</p>


A tiny LRU cache, from scratch
2026-05-14T00:00:00+00:00
Python gives you an LRU cache for free:</p>
from</span> functools</span> import</span> lru_cache</span></span>
</span>
@</span>lru_cache</span>(</span>maxsize</span>=</span>256</span>)</span></span>
def</span> expensive</span>(</span>x</span>:</span> int</span>)</span> -></span> int</span>:</span></span>
    ...</span></span></code></pre>
That’s the right answer in production. But “least recently used” is one of those ideas that feels obvious until you try to implement it, so let’s build one — partly for fun, mostly because the implementation is a beautiful use of a data structure you already know.</p>
The trick is the dict</h2>
Since Python 3.7, dictionaries preserve insertion order. That’s the whole trick. An LRU cache needs two operations to be fast:</p>

Look up a key</strong>, and mark it as recently used.</li>
Evict the oldest key</strong> when the cache is full.</li>
</ul>
An ordered dict gives you both. “Mark as recently used” is just delete and re-insert</em> — the key moves to the end. “Evict the oldest” is pop the first key</em>. Both are O(1).</p>
class</span> LRUCache</span>:</span></span>
    def</span> __init__</span>(</span>self</span>,</span> maxsize</span>:</span> int</span> =</span> 256</span>)</span>:</span></span>
        self</span>.</span>maxsize</span> =</span> maxsize</span></span>
        self</span>.</span>_data</span>:</span> dict</span> =</span> {</span>}</span></span>
</span>
    def</span> get</span>(</span>self</span>,</span> key</span>)</span>:</span></span>
        if</span> key</span> not</span> in</span> self</span>.</span>_data</span>:</span></span>
            raise</span> KeyError</span>(</span>key</span>)</span></span>
        value</span> =</span> self</span>.</span>_data</span>.</span>pop</span>(</span>key</span>)</span>   #</span> remove...</span></span>
        self</span>.</span>_data</span>[</span>key</span>]</span> =</span> value</span>       #</span> ...and re-insert at the end</span></span>
        return</span> value</span></span>
</span>
    def</span> put</span>(</span>self</span>,</span> key</span>,</span> value</span>)</span> -></span> None</span>:</span></span>
        if</span> key</span> in</span> self</span>.</span>_data</span>:</span></span>
            self</span>.</span>_data</span>.</span>pop</span>(</span>key</span>)</span></span>
        elif</span> len</span>(</span>self</span>.</span>_data</span>)</span> >=</span> self</span>.</span>maxsize</span>:</span></span>
            oldest</span> =</span> next</span>(</span>iter</span>(</span>self</span>.</span>_data</span>)</span>)</span></span>
            del</span> self</span>.</span>_data</span>[</span>oldest</span>]</span></span>
        self</span>.</span>_data</span>[</span>key</span>]</span> =</span> value</span></span></code></pre>
Twenty lines. The recently-used order is the dict’s insertion order; we never store it separately, so it can never go stale.</p>
Why the real one is different</h2>
CPython’s lru_cache</code> is implemented in C with a doubly linked list threaded through the hash table entries, plus a lock for thread safety. The linked list avoids the pop-and-reinsert dance — it just splices nodes. Same idea, fewer allocations.</p>

The best way to appreciate a standard library function is to write a worse version of it yourself.</p>
</blockquote>
If you want homework: add a hits</code> / misses</code> counter and a cache_info()</code> method, then compare your numbers against the real decorator on the same workload. They should match exactly — and if they don’t, finding out why is where the actual learning is.</p>


Reading a button, the obvious way
2026-03-27T00:00:00+00:00
Output was easy; input is where wiring details start to matter. This part connects a push button to the board and lights the onboard red LED while it’s held down. The code is crates/02-digital-input</code></a>:</p>
#</span>!</span>[</span>no_std</span>]</span></span>
#</span>!</span>[</span>no_main</span>]</span></span>
</span>
use</span> defmt</span>::</span>info</span>;</span></span>
use</span> embassy_nrf</span>::</span>gpio</span>::</span>{</span>Input</span>,</span> Level</span>,</span> Output</span>,</span> OutputDrive</span>,</span> Pull</span>}</span>;</span></span>
use</span> {</span>defmt_rtt </span>as</span> _</span>,</span> panic_probe </span>as</span> _</span>}</span>;</span></span>
</span>
#</span>[</span>embassy_executor</span>::</span>main</span>]</span></span>
async</span> fn</span> main</span>(</span>_spawner</span>:</span> embassy_executor</span>::</span>Spawner</span>)</span> {</span></span>
    let</span> p</span> =</span> embassy_nrf</span>::</span>init</span>(</span>Default</span>::</span>default</span>(</span>)</span>)</span>;</span></span>
</span>
    info!</span>(</span>"</span>Initializing the onboard Red LED...</span>"</span>)</span>;</span></span>
    let</span> mut</span> onboard_red</span> =</span> Output</span>::</span>new</span>(</span>p</span>.</span>P0_26</span>,</span> Level</span>::</span>High</span>,</span> OutputDrive</span>::</span>Standard</span>)</span>;</span></span>
</span>
    info!</span>(</span>"</span>Initializing the button...</span>"</span>)</span>;</span></span>
    let</span> button</span> =</span> Input</span>::</span>new</span>(</span>p</span>.</span>P0_03</span>,</span> Pull</span>::</span>Up</span>)</span>;</span></span>
</span>
    loop</span> {</span></span>
        if</span> button</span>.</span>is_low</span>(</span>)</span> {</span></span>
            info!</span>(</span>"</span>Pressed...</span>"</span>)</span>;</span></span>
            onboard_red</span>.</span>set_low</span>(</span>)</span>;</span></span>
        }</span> else</span> {</span></span>
            info!</span>(</span>"</span>Not Pressed...</span>"</span>)</span>;</span></span>
            onboard_red</span>.</span>set_high</span>(</span>)</span>;</span></span>
        }</span></span>
    }</span></span>
}</span></span></code></pre>Why Pull::Up</code></h2>
A button is just two contacts. Wire one side to a GPIO pin and the other to ground, and you have half a circuit: when the button is pressed the pin is connected to ground, but when it’s released the pin is connected to nothing</em>. A floating pin reads garbage — it picks up whatever electrical noise is nearby.</p>
Pull::Up</code> fixes that by enabling the chip’s internal pull-up resistor, which gently ties the pin to the supply voltage. Now the pin has a defined state at all times: high when released, low when pressed</strong>. That’s why the check is button.is_low()</code> for “pressed” — the same inverted logic we met with the active-low LED, this time coming from the circuit rather than the board layout.</p>
What’s wrong with this picture</h2>
It works, and for a first input program it’s exactly right. But look at what the loop does when nothing is happening: it checks the pin, checks it again, and again, millions of times per second. The log output makes the problem visible — Not Pressed...</code> scrolls past faster than the terminal can render it.</p>
On a desktop that’s merely wasteful. On a battery-powered board it’s disqualifying: the CPU never idles, so the chip never drops into a low-power state. And the busy loop doesn’t scale — this main</code> can do nothing else while it’s spinning on the button.</p>
We already know the shape of the fix. In part one, Timer::after_millis(1000).await</code> let the chip sleep through a delay. What we want here is the same thing for a pin: sleep until the button changes</em>. That’s exactly what Embassy’s async inputs do, and it’s next.</p>


Blinky, the async way
2026-03-04T00:00:00+00:00
Blinky is the embedded hello-world, and it earns the title honestly: getting an LED to blink proves your entire toolchain — compiler target, linker script, flasher, debug logging — end to end. Once it blinks, everything after is just more Rust.</p>
The full crate is crates/01-blinky</code></a>. Here’s the whole program:</p>
#</span>!</span>[</span>no_std</span>]</span></span>
#</span>!</span>[</span>no_main</span>]</span></span>
</span>
use</span> defmt</span>::</span>info</span>;</span></span>
use</span> embassy_executor</span>::</span>Spawner</span>;</span></span>
use</span> embassy_nrf</span>::</span>gpio</span>::</span>{</span>Level</span>,</span> Output</span>,</span> OutputDrive</span>}</span>;</span></span>
use</span> embassy_time</span>::</span>Timer</span>;</span></span>
use</span> {</span>defmt_rtt </span>as</span> _</span>,</span> panic_probe </span>as</span> _</span>}</span>;</span></span>
</span>
#</span>[</span>embassy_executor</span>::</span>main</span>]</span></span>
async</span> fn</span> main</span>(</span>_spawner</span>:</span> Spawner</span>)</span> {</span></span>
    let</span> p</span> =</span> embassy_nrf</span>::</span>init</span>(</span>Default</span>::</span>default</span>(</span>)</span>)</span>;</span></span>
</span>
    //</span> Initialize RGB LED pins (active low)</span></span>
    let</span> mut</span> red</span> =</span> Output</span>::</span>new</span>(</span>p</span>.</span>P0_26</span>,</span> Level</span>::</span>High</span>,</span> OutputDrive</span>::</span>Standard</span>)</span>;</span></span>
    let</span> mut</span> green</span> =</span> Output</span>::</span>new</span>(</span>p</span>.</span>P0_30</span>,</span> Level</span>::</span>High</span>,</span> OutputDrive</span>::</span>Standard</span>)</span>;</span></span>
    let</span> mut</span> blue</span> =</span> Output</span>::</span>new</span>(</span>p</span>.</span>P0_06</span>,</span> Level</span>::</span>High</span>,</span> OutputDrive</span>::</span>Standard</span>)</span>;</span></span>
</span>
    info!</span>(</span>"</span>Starting RGB LED pattern...</span>"</span>)</span>;</span></span>
</span>
    loop</span> {</span></span>
        //</span> Red on</span></span>
        red</span>.</span>set_low</span>(</span>)</span>;</span></span>
        green</span>.</span>set_high</span>(</span>)</span>;</span></span>
        blue</span>.</span>set_high</span>(</span>)</span>;</span></span>
        Timer</span>::</span>after_millis</span>(</span>1000</span>)</span>.</span>await</span>;</span></span>
</span>
        //</span> Green on</span></span>
        red</span>.</span>set_high</span>(</span>)</span>;</span></span>
        green</span>.</span>set_low</span>(</span>)</span>;</span></span>
        blue</span>.</span>set_high</span>(</span>)</span>;</span></span>
        Timer</span>::</span>after_millis</span>(</span>1000</span>)</span>.</span>await</span>;</span></span>
</span>
        //</span> Blue on</span></span>
        red</span>.</span>set_high</span>(</span>)</span>;</span></span>
        green</span>.</span>set_high</span>(</span>)</span>;</span></span>
        blue</span>.</span>set_low</span>(</span>)</span>;</span></span>
        Timer</span>::</span>after_millis</span>(</span>1000</span>)</span>.</span>await</span>;</span></span>
    }</span></span>
}</span></span></code></pre>
A few lines deserve a closer look.</p>
No standard library, no main</h2>
#![no_std]</code> opts out of Rust’s standard library — there’s no operating system here to provide files, threads, or heap allocation. #![no_main]</code> opts out of the usual entry point, because there’s no OS to call main</code> either. The #[embassy_executor::main]</code> macro fills that gap: it sets up Embassy’s async executor as the program’s entry point and hands your async fn main</code> to it.</p>
embassy_nrf::init</code> claims the chip’s peripherals and returns them as a struct of singletons. Each pin exists exactly once in p</code>, and moving p.P0_26</code> into an Output</code> consumes it — the type system makes it impossible for two parts of your program to fight over the same pin.</p>
Active low</h2>
The XIAO BLE’s onboard RGB LED is wired active low</em>: the pin sinks current, so set_low()</code> turns the LED on</strong> and set_high()</code> turns it off</strong>. That’s why all three pins start at Level::High</code> — everything off — and why the code looks inverted if you’re expecting high = on</code>. This wiring is common on dev boards; check the schematic before you trust a pin name.</p>
The await that matters</h2>
The interesting line is the one that looks least interesting:</p>
Timer</span>::</span>after_millis</span>(</span>1000</span>)</span>.</span>await</span>;</span></span></code></pre>
A classic bare-metal blinky burns that second in a busy-wait loop, spinning the CPU at full speed doing nothing. Here, .await</code> hands control back to the executor, which programs a hardware timer and puts the core to sleep until it fires. Same behavior, a fraction of the power — and no concurrency involved yet. That’s the quiet pitch of Embassy: the async syntax you already know compiles down to the interrupt-driven, sleep-when-idle code you’d otherwise write by hand.</p>
defmt</code> provides the logging (info!</code>), streamed over the debug probe by defmt-rtt</code>; cargo run</code> inside the crate flashes the board via probe-rs</code> and tails those logs in your terminal.</p>
Next up: input. We’ll read a button — first the obvious way, then the right way.</p>


In defense of boring tools
2026-02-21T00:00:00+00:00
There’s a particular kind of restlessness that disguises itself as diligence: the feeling that your tools are the bottleneck. A faster terminal, a sharper editor, the new framework everyone’s benchmarking — surely that’s</em> what stands between you and the work.</p>
It almost never is.</p>
The most productive engineers I know share one habit, and it isn’t a tool at all: at some point, they stopped shopping. They picked an editor, a language, a way of taking notes — usually nothing fashionable — and then spent the next decade getting frighteningly good at that small set of things. Their setups are boring. Their output is not.</p>
Novelty has a payroll</h2>
Every new tool charges you twice. Once up front, in the hours you spend learning it — and again quietly, forever, in the maintenance: config drift, breaking changes, the plugin that stops working, the migration you’ll do in eighteen months. Boring tools have already collected their fees. make</code> is not going to surprise you. Neither is SQLite, or rsync, or a plain text file with today’s date at the top.</p>
That’s the actual argument for boring: not nostalgia, but predictability</em>. A tool you can predict is a tool you can think with. The interface disappears and the problem is all that’s left.</p>
The escape hatch</h2>
None of this means never adopting anything. It means changing the default question from “is this better?” — almost everything is better in some dimension — to “is this better enough to pay for twice?” Occasionally the answer is yes. Version control was worth it. So were type checkers. When the answer is really yes, you’ll notice, because you’ll keep hitting the same wall every week and the new thing removes the wall entirely.</p>
Everything else is shopping. And shopping, whatever it feels like at the time, is not the work.</p>


What I learned recording 100 videos
2025-11-03T00:00:00+00:00
Somewhere past the hundredth recording, patterns start to show. Not about cameras or microphones — about explanation itself. A few notes, mostly for my past self.</p>
The first take is a draft.</strong> Nobody writes a good essay in one pass, but every beginner (me included) expects to speak</em> one. Record the explanation once badly, listen to where you rambled, then record it again. The second take is always half the length and twice as clear.</p>
Cut the setup.</strong> Every instinct says to begin with context: what we’ll cover, why it matters, what you’ll need installed. Delete all of it. Start where the interesting thing starts. People arrived because the title already told them why it matters.</p>
One idea per video.</strong> The tutorial that covers everything teaches nothing, because nobody finishes it. The ceiling on clarity is set before you record, when you decide what not</em> to include.</p>
Silence is edit points.</strong> Pause deliberately between sentences while recording. It feels unnatural in the moment and invisible in the final cut — and it makes trimming painless.</p>
The meta-lesson, I think, is that teaching is a subtractive art. Beginners add: more context, more caveats, more slides. The improvement curve is mostly a deletion curve. Which sounds a lot like writing, and a lot like code.</p>