editor's blog
Subscribe Now

Sensor Driver? Sensor Fusion?

Not long ago, coincident with Sensors Expo, Freescale announced their new Intelligent Sensing Framework, or ISF. From the initial descriptions I saw, I was frankly a bit confused as to how this is different from a driver and from other sensor fusion solutions. A conversation with Freescale’s Jim McGlasson helped add some color to what’s going on.

As a starting point, we can remind ourselves that a driver is a piece of code running on a host (or AP or whatever) that lets that host access a resource. In the case of a sensor, the driver can poke and prod at the sensor to configure it or retrieve data. The API and other hooks are typically defined by the operating system; this lets the sensor behave in a way that the OS is expecting, and it abstracts the sensor details from the upper layers.

While the ISF is described as providing sensor abstraction, it does not behave like a driver. By definition, the ISF isn’t intended to run on the host: it runs on the sensor.

“How,” you ask, “can code run on a sensor??” The short answer is, “It can’t.” Unless there’s a microcontroller in there. Which there is in Freescale’s “intelligent” sensor line.

Originally, the existence of that microcontroller wasn’t made evident to users, and, even if they knew about it, it wasn’t there for them to program. Its role was to give Freescale a way to take a single sensor and configure it into different products. A classic way of managing different OPNs (ordering part numbers) that can be handled with a single chip.

But, at some point, they opened up the microcontroller, and so this is where the ISF runs. It is particularly intended for systems where there may not be a host and OS; the ISF provides an API and hooks for working with the sensors and other data inputs.

Microcontrollers are increasingly being used as sensor hubs, whether integrated with a sensor or external, both for providing a low-power way of managing sensors without involving the host and as a place to execute sensor and data fusion algorithms. And that’s the ISF’s goal: provide a platform to simplify the creation of systems involving multiple sensors that require some sort of fusion.

If the system also has a host and OS, then a driver would still be needed to access the ISF.

So, details aside, the main point is that the ISF and drivers are separate entities, and you might have one or the other or both. The ISF provides a framework for sensor fusion that’s done below the level of the host. You can find out more in Freescale’s release.

Leave a Reply

featured blogs
Jan 20, 2020
As you probably know, discrete wire component data is quite a bit different than just standard socket and terminal mating relationships. When we look at how Samtec approaches discrete wire products, there are several components involved. We not only sell the assemblies, but w...
Jan 20, 2020
My latest video blog is now available. This time I am looking at operating systems for embedded applications and how you go about selecting one. You can see the video here or here: Future video blogs will continue to look at topics of interest to embedded software developers....
Jan 17, 2020
I once met Steve Wozniak, or he once met me (it's hard to remember the nitty-gritty details)....
Jan 17, 2020
[From the last episode: We saw how virtual memory helps resolve the differences between where a compiler thinks things will go in memory and the real memories in a real system.] We'€™ve talked a lot about memory '€“ different kinds of memory, cache memory, heap memory, vi...

Featured Video

Automotive Trends Driving New SoC Architectures -- Synopsys

Sponsored by Synopsys

Today’s automotive trends are driving new design requirements for automotive SoCs targeting ADAS, gateways, connected cars and infotainment. Find out why it is essential to use pre-designed, pre-verified, reusable automotive-optimized IP to meet such new requirements and accelerate design time.

Click here for more information about DesignWare IP for Automotive