Sensor fusion is algorithms. And these algorithms are typically executed as software. So that should be simple, right?

Just get your sensor fusion libraries from whomever you prefer (could be the sensor vendor, could be one of the sensor-agnostic folks), and then run it in the processor of your choice.

That processor could be the AP in a phone, although more and more that’s deprecated in favor of sensor hubs and other local, less power-hungry resources. Largely microcontrollers. And there shouldn’t really be any dependence on the specific computing platform chosen – as long as it has the resources to handle the algorithms. Right?

So I was a bit surprised when I saw that Movea and ST had collaborated to make Movea’s sensor fusion available on a very specific ST microcontroller: the STM32F401. Wouldn’t Movea’s stuff work on any ST microcontroller? Or anyone else’s, for that matter?

The answer is yes. Turns out that the collaboration alluded to in the announcement reflected work that Movea did to optimize their algorithms for that particular microcontroller. So the implication would be that, although you could run the algorithms on other ST microcontrollers, for example, they would run most efficiently on this particular one. Says ST’s Michael Markowitz, “This is precisely the result of a custom optimization by Movea to perfectly map the F401, which has an architecture that is well suited to performing sensor fusion at very low power.”

And, as such, ST would appear to be positioning that particular microcontroller as its preferred sensor hub platform. But there’s nothing that says you can’t use a different one.

You can find out more about this particular combination in the ST/Movea release.