← Back to Kevin's newslettersPublished: 2021 November 13

Hi friends,

My millifluidic PCR work is progressing:

A grey roughly 1x4 inch card with engraved surface channels

though I’ve spent the last two months shaving several quite-interesting yaks.

The first has been MSLA (resin) 3D printing; understanding constructable geometry, developing a progress for washing parts, debugging z-axis tolerances, etc. I’ve been shocked by the quality of parts coming off my $500 printer from $40/kg resin; everything is coming in within 0.1mm, which is more than enough for my needs. Note the 0.2mm high embossed labels on the four sections of the millifluidic test card above (USB-C connector at right for scale).

Most of this 3D printing ramp-up took place while shaving the second yak; building a spin-coater:

Close up of a 3D-printed spin coater holding a microscope slide

which I’ve needed for coating glass microscope slides with thin layers of adhesive (to cover open-faced millifluidic channels, themselves 3D printed as above, or perhaps fabricated on PCBs).

So far I’m happy with the $35, terrifyingly fast-spinning contraption shown above. See my design notes for the gory details on various false-starts (vacuum hold-down) and overview of 3d printing process/settings.

The third (most-exciting and ongoing) yak shave has been developing a programming language / compiler. Usually this is either dreadfully boring (“a mixed functional / object-oriented language that compiles to JavaScript”) or a nerd’s cry for help indicating one is about to disappear for a few years before almost certainly returning empty-handed (perhaps with a conference talk or podcast interview consolation prize).

However, rest assured that my language:

  1. Is already being bootstrapped (controlling the spin-coater and a few works-in-progress)
  2. Has been described, unprompted, by all of the so-called who’ve seen it as “not a real language”. Presumably because it lacks features like “control flow”, but that’s needless gate-keeping: A “language” is just custom syntax/semantics and a “compiler” is just a program that translates those into another language which can be run on a machine, and I have both. Chew on that!

Designing languages has never been an interest of mine. This one is borne entirely from my experiences over the past year working on embedded systems, in particular reasoning about hardware and physical-reality-driven constraints like:

I’ve previously discussed my frustrations with solving such problems by fighting Rust’s types and within spreadsheets.

The microcontroller search / pin assignment website from July was a first stab, and the language is a more powerful tool that fits neatly into my existing text-editor and version-control workflows.

At some point I’ll write up details for the language / programming nerds, and eventually put together an online REPL / tutorials a la Sketch.systems, but for now I’m focused on feedback people who’re in a position actually use it in anger.

So, if you’re working on a bare-metal embedded project and want to solve a complex set of pinout / signal / peripheral constraints at compile-time and generate optimal register code, drop me a line! (Especially if you’re working with STM32 chips, though I’m open to extending to Atmel or NXP chips with a motivated collaborator who can test on hardware.)

Misc stuff.