avi brown's μblog

thi is a test blog

The idea that organizations will design systems that copy their communication structure. Casey Muratori talks about how this accounts for many of the oddities that appear in enterprise software, such as the existence of 3+ different volume control sliders in Windows 11.

People online arguing about WHAT BETTER ESP32 OR STM32 with people on both sides convinced their side is obviously better. I hate when people argue about perfectly benchmarkable things, things that can be reasoned about. ESP32 (dualcore) is has a comparable CoreMark/MHz score to that of a Cortex M7

experimenting with SoA / AoS in C++, just toy examples I'm trying to hand write to check the differences. In the AoS approach I made an array of Objects that have 3 float members a, b, and c. I initialized 100 thousand of them and stored in an array, then I loop over them and iterate just "a". Then for SoA I made a struct of As Bs and Cs and then looped through just the As and iterated them. Seeing 0.35s for AoS and 0.21 for SoA... Gonna ask an LLM for a better example. Lol

yeah baby 80V@65A

It takes work for the CPU to decode an instruction. So if it's already unwrapping it, we may as well use it on as many data as possible! That number depends on the architecture.

wow the yt algorithm completely nailed it with this video, just yesterday I was thinking that I want to start getting better at back of the envelope math for things like CPU cycles

Watching the Molly Rocket lectures it seems that a good starting point for beginning to think deeply about performance is to separate code into latency-critical processes vs. throughput-critical processes

uops lets you see the number of ops, latency, throughput, etc. for all x86 microarchitectures.

Blue noise patterns emerge in "naturally random" distributions -- such as grass growth patterns -- where points maintain a certain distance from one another. This makes sense because in the case of grass (for instance) each tuft consumes resources and so surrounding tufts can't get too close lest they starve. Turns out this pattern appears like everywhere including in our eyes (the receptors follow a blue noise pattern which gives good coverage). Watching this video which although is not specifically about noise patterns is teaching me a lot about them lol

letting the coffee bloom really makes a difference with pourover coffee brewing! i always thought it was fake news pushed by Big Bloom

she has to edit PDFs and I'm overhearing her to try make sense of Adobe's enterprise slopware

Til now I haven't really understood why FPGAs often ship with dedicated DSP blocks. This always seemed odd to me bc shouldn't any digital logic be implementable directly on the FPGA? While this is true in terms of -functionality- (any DSP functionality can theoretically be implemented in the FPGA lattice) there is likely a lot of resource inefficiency with things like multipliers which may take up hundreds of LUTs. For instance a simple 2-input AND gate may use the same LUT resource as a complex 6-input boolean function.

There is a strain within the maker scene of geeks driven by a desire to democratize everything into plug-and-playable oblivion. I was sucked into this at the start because it enabled me to achieve builds with the semblance of engineering when it reality it required less prowess than a LEGO set. Unjustified dopamine hits locked me within a cage of mediocrity. It wasn't until I began stumbling upon actual engineers that my self-image began to crack and I grew aware of the cargo cult that is the maker scene. That is when I decided to stop making toys and start engineering the messiah.

Modern PCBs use copper pours to fill blank space as opposed to older PCBs which just leave blank substrate, just realizing this is why a lot of newer PCBs "feel" more substantial (among other reasons). Lots of nice benefits to copper pours (some of which I don't fully understand) in the comments of this hackaday article Copper pours reducing inductance for power connections feels intuitively right to me but I need to understand why

I can point to a few key encounters online that made me realize I don't know what I'm talking about. One was when I first stumbled upon geohot's streams on youtube and watched him open up the dissassembly of a program and analyze it. I didn't even know what assembly was. I realized then that I literally did not know what a computer program was or how things ran on computers. It blew my mind open and led me to his "From the transistor" repo which I studied time and time again. Another one was when I was trying to get an ODrive motor controller to work and I clicked into this video by accident. Seeing this guy reverse engineer some bytes to understand the underlying protocol made me realize that I didn't know how devices communicate with each other -- what IS Tx and Rx?! What are protocols?! Another is finding @adammaj's X account when he was designing his own GPU on the SILICON level. This sent me reeling and led me to the Zero to ASIC course which led to many other rabbit holes. There have been so many of these over the years and they are gifts. I pray for many more.

is so readable without skimping on technical details. Reading it feels like talking to an experienced mentor. Like I could read this design guide for fun

I made a little bash script that lets me just type into the terminal and hit enter and this magically appears on my website. I love technology

This blog is just a plain text file on my computer. It looks like this: I set it up with Sonnet 4's help. Basically: - I write blogs separated by three dashes - I push to main - GitHub actions trigger a parser and index.html is generated I will start posting quick thoughts here instead of X.

What is a robust, reasonable, and performant pattern for robotics software? I have become fixated with the idea of "motor schemas" as outlined in Behavior Based Robotics. To put it in my own words: For every data input (i.e. sensor reading) there should be a unidirectional computational flow transforming the input into a motor command. The system as a whole is comprised of parallel flows which are not aware of one another, and whose constituent motor commands are vector summed to yield overall motor behavior. This feels clean and data-driven to me. A natural fit for this approach is flow-based programming which seems like a healthy balance between the composability of functional programming and some light statefulness (state may exist on a component level though there is no global state). A great library for embedded flow-based programming is RAMEN from Zubax Robotics. I've played with it on my laptop and now I'm trying to settle on an MCU with a decent C++20-compatible toolchain with the goal of making a little PoC robot. Now, if we design our system such that the Modules Serve the Network (after all, what is a system if not a network?), and let our robot accept network definitions as input, then things start to get interesting.