Episode Details

We talk with Matt Trentini, Principal Software Engineer at Planet Innovation, about using MicroPython for professional embedded development—including medical devices. Matt shares how he was drawn back to embedded development after becoming jaded with traditional C-based workflows, and explains why MicroPython's interactive REPL and rapid development cycle have become game-changers for his team.

We explore the practical realities of using an interpreted language on microcontrollers: how Planet Innovation uses it for Class B medical devices, what the performance trade-offs actually look like, and how features like the Unix port enable robust testing. Matt walks us through deployment considerations, explains how to integrate C code when needed, and shares compelling stories about real-time client demos that would be impossible in C++.

Whether you're skeptical about high-level languages in embedded systems or curious about alternatives to traditional development workflows, this conversation offers a grounded, engineering-focused look at what MicroPython can—and can't—do in production environments.

Key Topics

• [03:30] Matt's background and why he left embedded development before MicroPython brought him back
• [08:45] What MicroPython is: a complete re-implementation of Python for microcontrollers with REPL, filesystem, and machine module
• [13:20] How Planet Innovation introduced MicroPython through an OpenMV vision processing project
• [17:15] The game-changing power of the REPL for interactive hardware development and testing
• [21:40] Running MicroPython code on x86 for testing, and the mock machine library approach
• [26:30] Python library compatibility: what works, what doesn't, and memory considerations
• [29:50] Integrating C and C++ code through extension modules for performance-critical sections
• [33:10] Performance realities: 10-100x slower in interpreter, but can always drop to C speed when needed
• [37:45] Tooling: MPRemote, the magical mount feature, and development workflow
• [42:20] When NOT to use MicroPython: cost-sensitive high-volume products and resource constraints
• [45:30] Using MicroPython in Class B medical devices and safety-critical applications
• [49:15] Garbage collection: simple, predictable, and controllable—can be disabled when needed
• [52:40] Real-time client demo story: modifying state machines during a call and showing results immediately
• [56:20] Deployment: frozen code, disabling REPL and filesystem, and OTA considerations
• [01:01:30] Common mistakes: logic errors and inadvertent allocations rather than memory corruption
• [01:05:45] Threading, AsyncIO, and the Global Interpreter Lock across different ports
• [01:08:20] State machine frameworks: StateChart, Yasme, and PyTransitions
• [01:11:40] Junior developer productivity: faster onboarding compared to C/C++ embedded development
• [01:15:10] Getting started: board bring-up as an ideal first use case for MicroPython
• [01:17:50] Hardware-in-the-loop testing as a low-risk way to try MicroPython

Notable Quotes

"It's hard to overstate how game changing the REPL is. Particularly as an embedded engineer, once you see that you can interactively talk to a peripheral, you can generate your own I2C, squirt it across and see what the peripheral does with it—suddenly driver development has just become easy to experiment with." — Matt Trentini

"My trite answer is that MicroPython is slow—10 to 100 times slower than C in the interpreter. But my flip side answer is that it can always be made as fast as C because you can always drop into C to write things." — Matt Trentini

"There was a moment in a recent project where we were discussing the workflow of a state machine with the client, and while we were on a call, anoth