Pinfigurator: A microcontroller search tool

← Back to Kevin's homepagePublished: 2021 June 29Last updated: 2022 May 31

Pinfigurator is a microcontroller search tool: You say something like, “I want USB, 2 USARTs, and 12 ADC inputs” and it tells you not only which microcontrollers meet those criteria, but also their pin configurations. See also the Pinfigurator language for more general constant solving full code generation.

How do I use it?

First narrow down your search by CPU type, package, flash and RAM size, etc. Then select the peripherals you want and which of their signals you need mapped out to pins.

(You don’t always need to map signals to pins — you might want, e.g., a timer for just the firmware to use.)

If the query can be satisfied for a given microcontroller, a ✅ will appear and the peripheral instances and mapped pins will fill in on the query. Results will also appear in tables, grouped by pin (with their alternate function setting) and by peripheral instance.

If the query cannot be satisfied (provably — because the microcontroller doesn’t have that particular peripheral or the desired signals can’t all be simultaneously mapped to pins), a ❌ will be shown.

If Pinfigurator isn’t sure about a particular microcontroller (because it got tired of thinking or was too busy with other people’s problems), it’ll show a ❓. You can click that to have it try again.

How does it work?

Each desired peripheral corresponds a series of existential quantifications: “there exists some unique peripheral having signals X, Y, Z; there exists some pin with an alternate function mapping the pin to signal X; etc.” These quantifications are resolved within the context of a single microcontroller, which typically takes a few seconds.

Background

The problem of selecting a microcontroller with the right peripherals for your application is trickier than it first seems, as microcontrollers tend to have many more peripherals packed into them than they have pins — that a chip has all the peripherals you need is no guarantee you’ll actually be able to use them all simultaneously.

Normally one must consult tables like this in a microcontroller’s datasheet:

which show that, for example, pin PA2 can be mapped to one of: timer 15’s channel 1 (its alternate function 0), USART2’s transmit signal (alternate function 1), timer 2’s channel 3, etc.

If you already have a microcontroller selected, it’s not too bad to print out this table and spend a few hours finding the appropriate assignments for the peripherals you need. (You can also click around in manufacturer-provided GUI configurators like ST’s CubeMX, which is equally tedious but lacks the charming Sunday-newspaper-crossword vibe.)

However, if you are trying to select from scratch or, god help you, optimize questions like “how many distinct timer capture channels will this chip support?” (as I did for my Vive Lighthouse receiver) or “how many ADC inputs can I actually map to pins?” (as I needed to maximize the size of my luxury touchpad) — the manual methods won’t scale up to search the thousands of possible microcontrollers.

This problem lodged in the back of my head about 5 minutes into staring at my first alternate function table, and now in mid-2021 with the tried-and-true “let’s just use a familiar, oversized-for-our-application” selection method in jeopardy from widespread chip shortages (due to misforecast demand at the start of COVID-19 pandemic), I figured it’s the right time to put together a prototype.

I first spent a week designing a sort of pattern matchy relational language for expressing arbitrary constraints, but then a wise embedded programmer reminded me that “most of us are afraid of Python”.

So in the second week I switched to a more approachable “just click on things” web UI, which is what you see today.

Possible extensions / future work

The internal representation and constraint propagation / solving code is quite general and could solve far richer queries than what’s exposed in the UI. I’m interested to hear what sorts of queries practitioners want to express — email or tweet me your suggestions!

A rough, incomplete list of possible Pinfigurator extensions:

• Constrain signals to specific pins (to search for substitute chips compatible with existing PCB layouts)

• GPIO constraints based on pin I/O structure (5V tolerance)

• Numeric GPIO constraints (5 pull-up inputs, 6 open-drain outputs, etc.)

• Optimization of these GPIO (to minimize number of activated ports; group inputs onto the same ports for faster reads, etc.)

• Constraints based on pin cardinal directions or relative locations (timer channel and complementary channel should be physically adjacent)

• Group signals into fungible classes (you don’t really care about timer channels 1, 2, 3, 4 — you just want a timer with X channels)

• Attributes on peripherals (16 vs 32-bit timers; ST’s advanced vs. general vs. basic timers)

• Links to relevant datasheet sections

• Internal signal routings (input pins mapped to an op amp mapped internally to a comparator mapped internally to a timer capture channel)

• Labeling queries with intended peripheral/signal use

• KiCAD schematic export with labeled pins

• Affiliate links, duh. I could probably make hundreds of dollars a year from this!

• Code generation (in C / Rust / Zig) to set alternate functions and GPIO initial pin states (open drain, pull up/down, etc.)

• More than just STM32 microcontrollers

• Include stock information for Digikey, Mouser, etc.

• More powerful search backend (to allow checking more than a few devices at a time)

• Bulk search / API (check query against all microcontrollers, get emailed results later)

Changelog / history

• 2022 May 31: Add link to Pinfigurator language.
• 2021 July 1: Updated to solve MCU-at-a-time rather than grouped; click to retry timeout.
• 2021 June 29: Initial release.