The back and forthing when selecting microcontrollers for my projects

The tools we use not only deliver the experience we wish to build, but also shape the experience. So when I think of what will be the brains of my project, the selection of the board or the chip is a dialogue between what I want to achieve and what can support it, with a dose of what I have in my collection.

Concept first
Most of my projects start with the concept, rather than looking at a board and thinking ‘oh, what can I do with this shiny thing?’ Though, to be fair, I am aware having a board or chip (or set of components) on hand nudges my concepts in specific directions.

Take for example the coronavirus I built. The concept started as ‘I want virus and blinky’. As I explored options, I realized that I would have 12 vertices with LEDs I wanted to blink. I could have blinked them in unison and thus been able to use a board with a few pins. But I wanted to blink them independently (maximum blinkage). So that meant a board with at least 12 IO pins. Also, I knew I wanted to do it all in CircuitPython. Lastly, since I have quite a few boards around, the final parameter was that I would not buy a new board.

In the end, I settled for the ItsyBitsy M0 – it had plenty of pins, runs CircuitPython, and was sitting in my collection, waiting to be useful.

Back and forthing
The dialogue really wasn’t as simple of that, of course. I did consider, had I wanted them to blink in unison, I could use one of my QtPys – also runs CircuitPython, also is in my collection, but has only a few pins. But I also considered if they were blinking in unison, I would not really have needed CircuitPython, so could use one of the ATtinys I have lying around.

Alternately, I could have bought LEDs that blink on their own. But I already had a gazillion LEDs, so was not buying more stuff. So I could have used my non-blinking LEDs I had on hand and just left them on without blinking and been able to leave out the microcontroller completely. But that would not have been fun, right?

Yeah, that’s the kind of dialogue back and forth I mean.

Goes the other way too
For the project pictured above, the design called for a stepper motor, an RTC chip, and an LCD screen. The LCD screen I was considering needed 6 logic pins, the motor 4, the RTC 2 (plus VCC and GND, each). When I looked at the boards I had, I realized that I had a TinyPICO lying around looking forlorn. The TinyPICO has plenty of pins, and could do the motor and screens at the same time.

Where the TinyPICO affected the shape of the project was to help fix an issue where I could only update the screen OR turn the motor. Doing both at the same time caused the stepper motor to chatter and the screen updates to be delayed. The TinyPICO, though, has two cores on its ESP32, so I was able to use one core for the screens and one core for the stepper. ‘Dual core’ was not an initial parameter of the project, but ended up changing how I was doing the project.

Also, because there were still some pins left and the TinyPICO does WiFi, I was able to add a magnet sensor for the stepper and a WiFi component to drive a second screen. Why not?

I guess this is the forth and back – the board nudging the build design.

Never so simple
I do mostly lead with the concept to come up with parameters for the components. But the tools we have determine sometimes what we think. For example, for some reason, I now have two RP2040s (got them free thru different folks). Yes, that board is pressing on my mind to insert itself in a project.

The same for the QtPy. I had bought a pair for the coronavirus project (which, when I decided to blink the LED individually, ended up needing more pins than the QtPy had). Now the QtPys are sitting around looking to be useful.

In a current project I am working on, I landed on using a Feather M0, due to some peripherals I wanted to use and the form factor.* But I’ve been prototyping the project with a QtPy. So, now, I believe I’m going to make a version of the project with the QtPy. For the most part, the code will be the same, just it’ll be a much smaller package.

That’s what happens when the board pushes the project. Haha.

That dialogue
The project that started me obsessing about microcontrollers began with that dialog between ‘i need to do something’ ‘what could that be?’ ‘what do I have on hand?’ and iterating until it became a bioreactor. Though, I did learn to be aware that the dialogue sends you down different paths, based on what you choose. And each of these paths have their own rage of possibilities that affect the project selections (I like to call them ‘adjacent possibles’).

For example, I started the project with an old Arduino Duemilanove, which I happened to have lying around unused for 10 years. That decision, though, stuck me to the Uno form factor. Things were too late to change after I realized the old Duemilanove was underpowered (I upgraded to the Uno).

This choice to use the Duemilanove had a knock-on effect for a subsequent derivative project, as well. For that subsequent project, I wanted to switch the core microcontrollers, but that would have changed many of the peripherals. And due to time constraints, I stuck with the tools we had. We ended up upgrading to the MetroM4, because the project needed more muscle, but we were still stuck on the Uno form factor. Had I been able to design again from scratch and select a different microcontroller, I think I would have left the Uno form factor.

Summary
For me, choosing a microcontroller for a project is usually guided by the concept, but is really a dialogue between the concept and the tools, iterating into something to build. But the more I do this, the more I am aware that the choices send me down paths that have their own adjacent possibilities that constrain the direction of a project. Sometimes this leads to interesting outcomes, other times it can be a pain.

What’s your thought process when choosing microcontroller for a project?

*Ok, I chose the Feather format partly because I just want to frakkin’ do something with a Feather. Especially, the Feather S2. But I chose to do my data logging to an SD rather than the cloud, so stuck with a Feather M0 that comes with an SD slot. Yes, that backing and forthing, again.