Microcontrollers Emulating Other Chips?

Two recent situations that I’ve encountered are:

  1. The supply chain shortages causing havoc on PCB designs
  2. Finding bugs within dedicated purpose but rather simple chips

For number 1, lots of people have experienced this. The manufacturing line is down because any single chip which is needed for a PCB cannot be sourced. Engineers are rapidly redesigning PCBs to use new or different or multiple chips as a short term solution.

For number 2, although sometimes the silicon vendor may document errata, you as a customer have no ability to fix the errata within a dedicated function chip, like for example a real-time clock or an I2C GPIO expander. You’re stuck with the errata and trying to work around it in any boards already produced by modifying the parts of the system which you can control.

What if we could ease both of these concerns by making open source (with something like a BSD or MIT license) firmware for a variety of different low cost and low power microcontrollers?

It shouldn’t be hard to make a firmware which very closely emulates something like an off-the-shelf real-time clock or I2C GPIO expander using any number of microcontrollers on the market today. The total cost of the part wouldn’t be much different from buying the dedicated function variant, but it would possibly make designs much more flexible around supply chain issues (can’t get that RTC? just put down the microcontroller version you can get!) and if you find a bug in the microcontroller implementation you could have a firmware update mechanism to fix the bug!

Many microcontrollers out there may even match pinouts of existing chips or be able to be a superset of the pinout of existing chips they intend to emulate, so that a design could fairly easily accommodate both the real dedicated device as well as one or more microcontroller variants.

Microcontrollers like the Atmel AVR family come in many package types and pin configurations, can have very low power consumption, and are pretty cheap. TI MSP430 family are similar, but from a completely different supplier. There’s now also many small cheap Cortex-M0 micros on the market, too. Being more agnostic to which parts go into any given design and being able to more easily fix a bug in the field could be super valuable! Getting this from a variety of silicon vendors by using a more liberally licensed open source firmware could be very interesting.

Does any such thing exist already at any kind of scale? Would real companies actually use such a thing if it did exist? Do you think opinions of such a thing have changed (or are changing) because of the recent parts shortages?

Obviously this isn’t a business plan, there’s no direct way to make money from people using the firmware. The licensing would need to be very permissive in order to get hardware people to use it, but it could lead to consulting contracts to support new micros, new emulations, entirely new feature sets, or fixing of bugs. For a small consulting company, that might be an interesting and lucrative enough market?

Interesting idea – my mind went to the RP2040 – super cheap and PIOs might be useful for emulating hardware. However the clock tolerance in the 2040 is pretty sloppy without a crystal:

https://forums.raspberrypi.com/viewtopic.php?t=315464

May be OK for some things though. The post implies Atmel parts are better in this regard.

Will have to think on this more …

The RP2040 is definitely interesting, but things like clock tolerance without an external crystal (and possibly very specific frequencies which seem rather odd to me at first glance at the docs) but also power consumption which is unclear from the docs. For something like an ATtiny or a small MSP430, you get a decent enough internal oscillator and in low power mode 1uA is a reasonable expectation. So clearly for some uses the RP2040 wouldn’t be a good fit, but for others and especially when the PIOs can be leveraged, it might be a great fit!

My thoughts around choosing I2C GPIO expanders or real time clocks first is that they’re pretty simple to implement (maybe this is me being naive?) so would allow for quick iteration to implement once for a given chip, then start to abstract things to work on other chips and see how that impacts resource utilization for flash, ram, execution speed, etc. To best leverage reuse across micros, having some kind of hardware abstraction layer would be handy if it would fit.

Then once the basic things are decently understood, moving onto the RP2040 and seeing what dedicated function devices it might be able to replace would be next.

1 Like

Hey Jeff – welcome to TMPDIR – very interested in how your RP2040 bringup goes.

Welcome Jeff ! Thanks for sharing your experiences with rpi mcu so far. Would look forward to more on what you find