Bigger, Better, Faster

It’s sometimes/often easy just to buy a “better” part.

Better/faster isn’t always so simple, though.

Shopping around for more and more powerful parts takes time as well.

The Right Thing To Do is to code it right, instead of starting a process to switch to a more powerful microcontroller, which would necessitate switching to some completely new product family from an unknown manufacturer, or FPGA for that matter.

Or default to overly large microcontrollers “just in case”.

You can’t always default to just buying moar power!!!, sometimes you need to know how to utilize the easily available resources in efficient manner.

For example, if you need to drive a large screw, you switch gears of your electric drill instead of saying: “I don’t know how I operate this gear lever, I’m going out to buy one with a bigger motor”.

I operate with the mindset that programming timing and performance critical embedded applications requires expertise and is not trivial. If I don’t know how to do something, I will learn how to do it.

It’s not always easy to detect whether you just need a “bigger part”, or change how you do it.

BTW with microcontrollers you just can’t use the “use a bigger part” mindset because it often happens that the initial “dumb” implementations are so underperforming even the biggest part on market can’t do it. So you are in this “performance of the code matters” game no matter what. Even beginners hit this performance limit very soon when they see their ISRs take too long to complete, this happens even if they start developing with 480MHz Cortex-M7.