The Engineering Blog

The current StackCalc engineering record: a shared RPN core, Apple apps, a firmware simulator, an unpowered mechanical calculator prototype, and the StackCalc Learning Lab. Each post distinguishes a working artifact from a planned or unmeasured result.

From OpenSCAD to the Classroom Desk: 84mm Fraction Towers, Logarithmic Prime Blocks, and Unit-Tested Books

Whenever we tell someone we are manufacturing a new calculator alongside 3D-printed math blocks and printed textbooks, the natural question is: "In a world with smartphones and AI, why does the world need another calculator?"

Because even in the age of AI, students still need to know how to think mathematically. Handing a child an AI chatbot—or a standard school calculator where they type nested parentheses (12 + 8) / (5 - 1) = into a black box—hides every intermediate step of reasoning. By contrast, on a stack-based RPN calculator, students learn operator-precedence parsing themselves because they must break expressions down in the right order of operations to enter them onto the stack, seeing every intermediate result step by step. And unlike CAS (Computer Algebra System) calculators—which are banned on the SAT, ACT, IB, UIL, and college math exams—our calculator is purposefully designed to be allowed in testing situations (zero CAS symbolic manipulation, zero QWERTY keyboard, and zero wireless radios on the hardware).

Our goal with the StackCalc Ecosystem is to make every step of mathematical reasoning visible and physical, connecting 3D-printed classroom manipulatives (manufactured in-house and on Slant3D), unit-test-verified reference books, and our SC-6 / SC-32 calculators.

Co-Developing an App Store App and Bare-Metal RP2350 Firmware with a Shared Swift Core and STL-Backed Digital Twin

Waiting for PCB fabrication and 3D-printed enclosures usually creates a painful bottleneck in hardware startups: firmware engineers wait for boards to arrive, while app developers build UI mockups that drift away from the physical device.

To build StackCalc—a kid-friendly, exam-legal RPN scientific and educational calculator that grows with learners from StackCalc 6 (Common Core K–6) to StackCalc 32 (AP Calculus and engineering)—we architected our software and mechanical CAD pipelines so the iOS/iPadOS/watchOS App Store app and our bare-metal Raspberry Pi RP2350 firmware share a single Swift codebase (RPNCore) and co-develop against an STL-backed Digital Twin.

Shipping StackCalc v1.1 on the App Store: A Clean-Room RPN Calculator That Grows With Your Kid (SC-6 to SC-32)

When I trained my own kids to use Reverse Polish Notation (RPN) on a SwissMicros DM41CC, three things became immediately obvious: 1. Kids do not struggle with RPN—they struggle with infix parentheses. Pushing two numbers onto a visible stack and combining them matches the exact order in which children push physical blocks together on a desk. Even better, because there is no hidden infix parser behind an = key, users learn operator-precedence parsing in their own minds in order to decompose and enter expressions onto the stack—appreciating the lessons learned in the past 50 years of computing so they can build the next 50 years. 2. Handing a student a CAS calculator is a trap for exams. Because Computer Algebra System (CAS) calculators are banned on the SAT, ACT, IB, UIL, NCEES FE/PE engineering exams, and university calculus midterms, we purposefully designed StackCalc to be allowed in testing situations (no CAS symbolic manipulation, no QWERTY keyboard, and no wireless transceivers on the hardware). 3. Sending a kid to school with a $250 collector's calculator or a $200 vintage eBay HP-32SII is a terrible idea.

That realization sparked the overarching vision for StackCalc: building a low-cost, kid-friendly RPN calculator and tactile learning ecosystem that grows with a student from first grade through university engineering—starting with our small-batch maker hardware at $89.99 while engineering our production roadmap toward a $29.99 student backpack target.

Today, StackCalc Calculator v1.1 is live on the Apple App Store for iPhone, iPad, and as a 100% standalone Apple Watch app, uniting Visual Learning Mode (StackCalc 6) for Common Core K–6 math with Scientific Mode (StackCalc 32) inside one universal binary.

Notes from the PCBWay Assembly Floor: Header Pins, JST Footprints, and Switch Jumper Routing

Passing local Design Rule Checks (DRC) in KiCad is a satisfying milestone, but it is not the same thing as passing physical assembly on the factory floor.

Shortly after we submitted our initial 4-layer calculator mainboard (calculator.kicad_pcb), BOM (bom.csv), and pick-and-place centroid files to PCBWay for turnkey SMT and through-hole assembly, their engineering team paused the line and sent back a set of real bench inspection photos. Those photos caught four physical integration bugs that a software DRC never flags: through-hole MCU header pins colliding with a front-side tactile switch, a through-hole JST battery header paired with undrilled surface-mount pads, mirrored silkscreen layers, and implicit jumper connections across the 4-pad tactile switches.

Here is what the PCBWay team found on the bench and how we fixed the board layout and jumper routing with Python scripts in KiCad's pcbnew API.

The Postfix Manifesto: Why Human Thought Calculates in Stacks, Not Parentheses

For more than four decades, secondary and collegiate math education has been dominated by legacy in-fix computing architectures.

Generations of students have been handed monolithic graphing bricks, only to encounter endless parentheses soup, hidden order-of-operation syntax errors, and cryptic SYNTAX ERROR screen freezes. Today, that friction is compounded by recurring annual software emulator seat licenses, non-repairable assemblies, and battery corrosion.

StackCalc was born out of an uncompromising thesis: In-fix entry is a pedagogical bottleneck that hides mathematical truth inside a black box. The natural logic of human thought and physical reality is Postfix (Reverse Polish Notation).

The TPU Button Video Is a Design Review, Not a Slow-Motion Test

A simulation is much more useful when it makes a design argument visible. In a static CAD view, a TPU key, a faceplate opening, and a switch location can all look compatible. The difficult part happens between those still images: a keycap drops, tilts toward a wall, transfers motion through the web, and either reaches the switch or spends its travel rubbing somewhere it should not.

That is why we made a cutaway video of the StackCalc TPU membrane. It is a short design-review tool built from the same membrane and faceplate STL geometry used for the prototype, not a claim that the unpopulated calculator has already survived a life test. The RP2350 board is in fabrication; the video lets us inspect the mechanical questions now and gives the first board session specific cases to repeat.

We Pressed One TPU Key 280 Ways Before the PCB Arrived

A calculator key rarely gets pressed straight down in the middle. A thumb catches an edge. A finger comes in from the side. A child presses a corner. The first question for our TPU membrane was not “does it move?” It was “which bad presses leave enough room for the key to reach the switch without scraping the faceplate?”

The StackCalc PCB is in fabrication, so the printed calculator is not yet a powered keypad. We used the interval to put numbers around the geometry that will meet the board: the printed faceplate aperture, the TPU web, the keycap stem, and the proposed tactile-switch interface. That produced a 280-condition press sweep and the plot below.

What the First Printed StackCalc Prototype Can Teach Us

The first useful prototype is rarely the one that looks closest to a product. It is the one that makes the next decision cheaper. The current StackCalc hardware is a 3D-printed, tool-free mechanical prototype. Its KiCad PCB design is complete and fabrication is in progress, but there is no assembled, powered StackCalc board yet. The print lets us ask clearly: does the insertion path make sense, where does a part bind, and which keypad assumptions should be tested next?

From an Origami Box to a Puzzle Stand

Shipping support is usually dead weight: it protects a device for one trip and then disappears into a bin. We wanted the StackCalc packaging support to keep earning its space on a desk or shelf. That changed the design question from “how do we protect a calculator?” to “what can protect it, organize the kit, and become useful after unboxing?”

The first answer was an origami fold. The current answer is a printed puzzle stand: four dovetail-connected corner pieces form an upright shelf stand, while a separate strut becomes a low desktop typing support. The printed pieces and the package envelope are still being refined together, but the change already made the whole product feel more connected—from the first opened box to the way the calculator lives between uses.

A printed StackCalc prototype docked in the shelf-stand assembly.

Fuzzing the Firmware Path in an RP2350 Emulator

The StackCalc calculator board is not assembled yet, but the firmware path is already rich enough to break in interesting ways. A random input sequence can cross number entry, ENTER, stack lift, shifts, menus, modes, clear, correction, and display updates in combinations that a hand-written demo never reaches.

We use the RP2350 emulator to run the firmware image and fuzz those combinations through its keypad contract. That is firmware-emulation evidence, not evidence of a physical switch matrix or display.