March 25, 2025 • 22 mins
Join hosts Bridgette Stone and Kyle Dando on the NXP EdgeVerse Techcast as they explore NXP's extensive collection of sensor-based applications found in the Application Code Hub (ACH). Special guest Amit Purohit, a pioneer in NXP sensor software enablement, discusses the seamless integration of sensors into the MCUXpresso ecosystem and the middleware innovations that facilitate smarter, energy-efficient systems. Discover how the ACH, CMSIS drivers, and FreeMASTER tool enhance the experience developig with NXP sensors. Amit showcases how the low-power wakeup sensor examples in the ACH are ideal for real-world applications for smarter, sustainable edge devices.
00:00 Welcome to the NXP EdgeVerse Techcast
00:27 Introduction to the Application Code Hub (ACH)
01:01 Meet Amit Purohit: The Godfather of NXP Sensor Software
02:04 Integrating Sensors into the MCUXpresso Ecosystem
03:17 Challenges and Benefits of Sensor Integration
04:53 The Power of Middleware in Sensor Development
07:23 Simplifying Development with Arduino Form Factor
08:58 Real-World Applications and Low Power Design
11:38 Key Sensor Features for Low Power Optimization
14:52 Introducing FreeMASTER: A Unique Tool for Sensor Development
17:40 Future of Application Code Hub and Expansion Board Hub
21:13 Conclusion and Final Thoughts
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Bridgette Stone (00:10):
Welcome everyone to the NXP EdgeVerse Techcast,
where we talk about all thingsedge computing, cool tech, and the
tools that make it all possible.
I'm Bridgette Stone, joined bymy partner in tech, Kyle Dando.
Kyle, what's the big ideawe're diving into today?
Kyle Dando (00:26):
Well, thanks, Bridgette.
Today we're diving into one of my favoritetopics, and that's the Application
Code Hub, or as we call it, the ACH.
If you've ever browsed through it, ithas over 150 applications, and you'll
notice a common theme among those.
And that's pretty much sensors.
Lots and lots of sensors.
(00:47):
So to help us unpack how sensorsand MCUs work together to create
a smarter, more efficient system,we've got the perfect guest.
Amit, thanks for joining us today.
Amit Purohit (00:58):
Thank you, Kyle, for having me.
Kyle Dando (01:00):
Sure.
So Amit, Purohit is basically theGodfather of NXP sensor software.
Amit, before we get into all thecool work your team is doing, why
don't you introduce yourself a bit?
Amit Purohit (01:13):
Sure.
Hi, my name is Amit Purohit and I'massociated with the MEMS Sensor product
line at NXP based in Chandler, Arizona.
I've been part of Freescale and nowNXP for more than 15 plus years.
In my previous roles, I worked on digitalsignal processors and later on to power
(01:33):
PC based heterogeneous architecturesfor wireless protocols development.
As part of my current role, I'm drivingthe Sensors development ecosystem and
tools strategy for NXP sensors business.
My focus has been to help improve theease of use for our customers by providing
a good out-of-box experience duringtheir evaluation phase, and creating
(01:57):
differentiated solutions with NXP sensors.
Bridgette Stone (02:00):
Thanks for the introduction, Amit.
We're so happy to have you.
Now, integrating sensors into theMCUXpresso ecosystem has been a
long journey, and you've been at theforefront of this effort for years.
Tell us how it all started andwhat kind of impact this has had
on the sensor enablement at NXP.
Amit Purohit (02:19):
Yeah, sure Bridgette.
So my journey has been apath of continuous learning.
And it is filled with the satisfactionof helping our customers by improving
their development experiencewith the unified set of tools
provided by MCUXpresso ecosystem.
Also, I feel that integrating sensorsinto MCUXpresso ecosystem had optimized
(02:41):
sensors enablement delivery with quality.
I started Sensors integration intopreviously known Kinetis Expert SDK in
late 2016, and have been involved sincethen to support sensors integration to the
latest MCUXpresso SDK that we have today.
It's been over eight plus years ofgreat collaboration with the SDK
(03:03):
team and now when I look back, Isee how the SDK has matured from the
Kinetis Expert to the MCUXpresso SDK.
It has been built into one of the finestdevelopment ecosystems in the industry.
Bridgette Stone (03:17):
That sounds like a massive evolution, and with every
big shift like this, there are alwayschallenges, but I imagine this has also
been really rewarding for you personally.
What's been the biggest benefit for bothyou and the NXP sensor product line?
Amit Purohit (03:32):
Yeah, that's a great question, Bridgette.
Integrating sensors as a middlewarecomponent into MCUXpresso
SDK has been challenging.
Let me tell you, by the way, the sensorsoftware was the first middleware
successfully integrated into the SDK,and we became a reference at that point.
I strongly believe that it hasadded a lot of value and transformed
(03:56):
the way NXP enables customersto design with our sensors.
Of course, these effortshave also benefited me.
I had a great learning experience workingwith the SDK team across the globe.
I have made very good friends whileestablishing mutual respect for the
jobs that we do, but in my opinion,the most important aspect has been that
(04:18):
this integration has provided excellentopportunities to show more of the
complete solution that NXP can offer.
The sensor product line over thetime started understanding the
importance of attaching sensorswith MCU development ecosystem.
And this effort has made it easier forcustomers to successfully pair these two
(04:38):
products to jumpstart their development.
According to me, this has beena good example of the "Brighter
Together" mindset promoted by NXP.
Kyle Dando (04:46):
That's true.
It is.
I think it's a great example of ourbrand of being brighter together, Amit.
Now Amit, you mentioned that the sensorsmiddleware component is a key part of
the enablement, and I like to thinkthat the middleware is that trusted
bridge between the microcontrollerthat you mentioned, and the sensors
that they may want to use from NXP.
(05:08):
So explain a little bit more about whatit is in that sensor middleware but
also show how you have made it a littlebit more valuable for the developers.
Amit Purohit (05:19):
Yeah, thanks Kyle.
I was hoping that you wouldpose this question to me.
So as you're aware, middleware in anSDK, it acts as a glue layer, connecting
the SDK features to the external systemfor extending certain applications.
We created ISSDK, We call itIOT Sensing, SDK, and it's being
(05:40):
offered as a middleware componentin the MCUXpresso SDK ecosystem.
ISSDK combines a set of robust sensordrivers and algorithms along with
example applications to allow usersto get started with NXP sensors.
What we changed there is, we changedthe sensor driver design to come up
(06:01):
with the CMSIS compatible low-leveldrivers, and then we also created easy
to read functional APIs to improve thecode readability for our customers.
This way, we were able todemonstrate a modular and
separable layer-cake architecture.
In summary, implementing CMSIS compliancesensor drivers to connect to peripheral
(06:23):
drivers provided by SDK was one of thekey features that has helped us a lot for
easy porting across the NXP MCU portfolio.
Apart from that, the way we haveexposed sensor register bitmaps for
easy access to configure sensorsis another useful Design feature.
(06:44):
And last but not the least, isthe concept of Board Shield GPIO
mappings that we have added.
This actually helped us to provide aseamless migration to support multiple
MCUs without changing the sensor drivers.
Kyle Dando (07:00):
Amit, you and I worked quite a bit on the CMSIS drivers, and I know
that the feedback from our engineersand customers is that they really
like how those CMSIS drivers allowthe projects to be a little bit more
portable because that common CMSIS drivercan be used across multiple boards.
So that was huge.
I'd like you to drive a littlebit more into how you simplified
(07:22):
things for the developers.
The sensor team has done a great jobof embracing the Arduino connector
and the form factor, and that has madeit really easier for the customer to
take that one sensor or that one boardand move between different products.
So beyond that hardware, how didyou using the Arduino connector and
(07:43):
the Arduino form factor improve thesoftware enablement with sensors?
Amit Purohit (07:47):
Yeah, and that's a great point, Kyle.
Thanks for reminding me of that.
We decided to adopt the Arduino formfactor for the sensor evaluation boards
to better align with NXP's evaluationkits or FRDM development boards approach.
What I really liked aboutthe MCU board design.
Is the way it extends flexibilityto connect, add-on expansion
(08:09):
boards, and provides the freedomto innovate for our customers.
This approach has certainly helpedsimplify sensors enablement.
As I mentioned in my early comment, theboard shield mapping concept that we
added was built since we were able toutilize the Arduino form factor, which
is a standard expansion pin mappings.
(08:30):
And this allowed us to use sensorshield boards like LEGO blocks.
And what I mean by that is, weare providing this flexibility to
developer that they can swap betweenboards with very minor changes in
the respective board shield and GPIOmappings, and they can run the same
examples with no other change required.
(08:52):
With such stickable expansionboard options, we are
offering freedom to innovate.
Bridgette Stone (08:57):
Thanks, Amit.
I know we were talking a little bitabout the power of middleware, and I
think one of the best ways to talk aboutthis is through real world applications.
With all the work that you'vedone, you must have a favorite,
ACH example that really highlightsthe value of sensor integration.
What stands out to you?
Amit Purohit (09:17):
Yeah, so when we started having the sensor middle integration
and CMSIS driver compliance, it actuallyhelped us to move quickly in bringing
up application specific examples.
With the flexibility to portfaster on multiple Cortex-M based
microcontrollers, and combiningmultiple middlewares available for
(09:38):
those MCUs, we are able to demonstratecool application examples through ACH.
My favorite sensor-based ACH examplesare, of course the one showing the
ultra low power wakeup features ofsensors to help optimize overall
power consumption of the system.
Now you might be wondering, out of somany sensor-based cool applications
(10:00):
available on ACH, why I'm choosingthe low power examples, I always
get this question, why do we needto care about low power designs?
Let's look at some interesting numbersand see whether that answers our question.
So based on some estimations by EDNA.
Which is an initiative of theInternational Energy Agency.
(10:20):
By 2030, there will be more than75 billion connected edge devices.
More than one third, that is morethan 25 billion, will be battery
powered iot devices that willbe deployed in remote locations.
The associated energy use and waste frombatteries will be considerably huge.
(10:41):
There's another study done byENABLE, which is an EU funded
research infrastructure project.
According to them, up to 78million batteries will be
discarded daily around the globe.
In next few years, if we do not improvethe lifespan of batteries or reduce
the energy consumption, powering theseIOT devices, this will cause major
(11:03):
Environmental and economic problems.
Currently we are at the 40% of thecapacity to recycle these batteries.
So this tells you why integratinglow power features are very
critical for iot applications andalso for optimizing system battery
power for a sustainable future.
Bridgette Stone (11:22):
That's truly a compelling use case, and thank
you for sharing that information.
It really ties well into a growingchallenge, power efficiency.
With billions of iot devicesexpected to be battery powered.
Reducing energy consumptionis absolutely critical.
So what key sensor features arehelping to drive these kind of
(11:43):
trends for low power optimizations?
Amit Purohit (11:46):
Yeah, that's another very good question, Bridgette.
So many of the key features of thesensors are demonstrated in the ACH
examples, but I can mention just afew of the most important ones here.
Most of our low power sensorsfeature flexible and configurable
digital competitor embedded function,we call it SDCD, that is Sensor
(12:07):
Data Change Detection function.
For example, SDCD functional block formotion sensors implements an inertial
event detection function with the abilityto detect motion events like motion to no
motion detection, tap free fall shocks,and other transient acceleration events.
(12:28):
Such embedded functions allow users withthe flexibility to configure sensor for
required motion, gesture based wakeup.
They don't need to write complexalgorithms to do the post
processing on the raw data.
This is all done by this embeddedfunction block within the sensor.
Another key feature that we havedemonstrated through these ACH examples
(12:48):
is our Auto Wake/Sleep feature.
This feature allow developers tomake the system totally autonomous.
What I mean by that user canconfigure their wake up based
configurations using the SDCD block.
And by configuring auto wake sleep,the sensor can work autonomously.
It can go back to sleep mode when theconfigured wake up event has not occurred
(13:10):
for continuous configured amount oftime, let's say an example, 10 seconds.
If there's no motion wake up happeningfor continuous 10 seconds sense is
capable of going back autonomously.
Then it can wake up again basedon the wake up condition met.
Finally, the developer can findexamples where sensor is configured
(13:31):
to work in the interrupt mode.
That's a very important feature becausethen all of these SDCD and auto sleep
can be tied in with an interrupt feature.
Sensor can raise an interrupt towake up the host MCU and system, or
alternatively raise the interrupt to putthe host MCU and system to deep sleep
mode using auto wake sleep feature.
(13:52):
Combining all these three features,we showcase how our low power wake
up sensors can play a criticalrole in extending battery life
for the overall system solution.
Also, I would like to take advantageand mention that devices are
getting more and more complex withmore competitive content in them.
(14:13):
The low power design aspect shouldn'tbe afterthought, in my opinion.
Rather, it should be thefirst thought when designing
such connected edge devices.
The low power wake up sensor ACHexamples describes how a developer can
use these key sensor features in theirnext design to enable effective power
management for low power operations.
Kyle Dando (14:35):
I've worked with most of the sensor projects in the Application
Code Hub, and I agree that the low powerwake up feature of these sensors is
really powerful and you do a great jobof showing customers how they can get
started and how to truly take advantageof those features in the sensors.
I did notice though that you alsoinclude FreeMASTER in most of those
(14:56):
sensor projects, and this tool,FreeMASTER may be new to our listeners.
We haven't had an episode covering that.
So can you introduce what FreeMASTERis to the listeners and maybe how
you have included it as a very uniquetool that has helped accelerate
sensor development for the users?
Amit Purohit (15:16):
Sure Kyle.
Yeah, and I agree.
I That's a good observation.
So as part of my current role, I'malways trying to find ways to improve
ease of use for our customers byproviding good out of box experience.
During my involvement in integratingsensors into MCUXpresso SDK, I learned
about another middleware component,
(15:37):
and that is FreeMASTER.
This tool was promoted as a runtime debugging tool.
That means this tool was initially createdto have some kind of debug counters, some
kind of watch variables, and when youprovide a debug release debug version of
your binary to customer, they can actuallydo the field debugging in real time.
(16:02):
When I started to learn more about it.
I thought I could use this tool tocreate an evolution GUI tool for sensors.
Some of the cool features of FreeMASTERtool, like ease of adding watch
variables into the memory mapped targetsite addressable, TSA area, their
proprietary communication interfacewith the host and the ease of importing
(16:24):
the TSA map watch variables on thehost GUI helped me to transform this
tool into a sensor evolution tool.
We have successfully adopted thistool as sensor evolution tool.
We integrated sensors middlewarewith FreeMASTER middleware on the
target side for supported MCUs.
Also on the host side, we havebeen able to create sensors control
(16:46):
page that gives easy access tousers to evaluate our sensor specs.
Like full scale range, ODR,Sensitivity, Offset Noise Measurements,
running self-test diagnostics,and configurable power modes.
We also extended the GUI featuresto include a very extensive
(17:07):
registered page for sensors.
Where user in real time can readall sensor registers, modify bit
fields of sensor registers, andsee the behavior in real time.
This is helping customers tonot go through the data sheet.
They can use this tool andevaluate the part very easily.
(17:28):
Also, this tool providessensor data visualization, data
logging, and many other features.
Bridgette Stone (17:34):
Thanks Amit, we're coming up here to our last question.
I wanna talk a little bit aboutwhat's next and in the future.
And we know that Application Code Huband Expansion Board Hub have already
made it easier for developers toexplore and implement new applications.
So looking ahead, where doyou see these tools evolving?
Amit Purohit (17:53):
Well, I've been seeing the pace at which MCU Enablement is
transforming to meet customer needs.
The Application Code Hub andExpansion Board Hub are great examples
confirming how NXP is extending itsdevelopment ecosystem to allow better
engagements with our customers.
While the MCUXpresso SDK tools andevaluation boards built a strong good
(18:16):
foundation for our customers, therealways have been a strong desire from
Open Source developers community tohave a quick and easy way to search
for application specific examples,supporting specific targeted families
with various expansion boards.
ACH provides a list of applicationspecific examples developed by NXP
(18:38):
in-house experts and provides aneasy way to search available examples
by device, family applicationtype, and other categories.
And Expansion Board Hub provides adatabase of NXP and third party expansion
boards to expand NXP MCU EVK capabilities.
Expansion Board Hub also helpedlinks associated enablement software
(19:00):
for bringing up those chosen targetplatforms and expansion boards.
Looking ahead, I would really liketo see our FAEs, Sales team and our
customers to make use of these tools.
And I believe we can achieve thisby educating them and spreading more
awareness on how to use these tools.
And at this point, I would like to sharea success story that I totally loved when
(19:22):
I heard it firsthand from one of our FAE.
This story confirms how these tools arehelping our NXP teams to cross promote,
cross sell, and gain customers confidence.
So recently, an FAE visited a customersite that is in the healthcare space
to discuss NXP's wireless connectivityoffering based on customer's request.
(19:43):
But when he learned more about the usecase, it took him no time to bring up a
sensor expansion board and an availableACH example to quickly demonstrate to
the customer how the sensor featureadds value to the customer use case.
This quick and live action helpedto gain customer confidence, and
(20:04):
customer immediately showed interestin evaluating the sensor part.
I am sure there are more such examplesavailable where were tools and
integration of multiple technologiesto reduce complexities is making a huge
difference in helping our customers.
With this approach, we are driving atrue value proposition for our customers.
Kyle Dando (20:25):
That's a great story.
As a former FAE I spent 10 yearsin the Bay Area visiting customers.
There's nothing more powerful for acustomer or for an FAE than to be able
to plug a board in, go to an examplethat somebody else put together.
And show quickly that what we'retalking about actually works.
(20:46):
Because as salespeople and as customers,sometimes we're skeptical that all
we're doing is hearing a good story.
I think the Application Code Hub andall your sensor examples is the evidence
that the customers really enjoy.
And NXP has done a great job ofpositioning your products along
with the MCUs to make sure thosecustomers have that confidence.
(21:07):
When we explain to them thatwe have a solution, they can
get it, and they can use it.
So thanks again, Amit,for joining us today.
It's just been a pleasureto have you on the show.
we explored how NXP is workingto make sure that sensors and
MCUs are "Brighter Together".
From seamless middleware integration withprojects in MCUXpresso to providing a
(21:29):
powerful visualization tool in FreeMASTER.
We've learned that the Application CodeHub is helping developers discover the
different use cases for the NXP sensorsand these sensor application examples
are helping them bring their projectsto life faster and more efficiently.
Bridgette Stone (21:47):
Thanks again for your time today, Amit.
And if the listeners enjoyed thisepisode, please be sure to Like,
Subscribe and turn on Notificationsso you never miss an update.
And if there's a topic you'd lovefor us to cover, let us know.
We would really like to hear from you.
Kyle Dando (22:03):
So that's it for today.
Keep innovating everyone and we'll catchyou on the next EdgeVerse Techcast.
Welcome everyone to the NXP EdgeVerse Techcast,
where we talk about all thingsedge computing, cool tech, and the
tools that make it all possible.
I'm Bridgette Stone, joined bymy partner in tech, Kyle Dando.
Kyle, what's the big ideawe're diving into today?
Kyle Dando (00:26):
Well, thanks, Bridgette.
Today we're diving into one of my favoritetopics, and that's the Application
Code Hub, or as we call it, the ACH.
If you've ever browsed through it, ithas over 150 applications, and you'll
notice a common theme among those.
And that's pretty much sensors.
Lots and lots of sensors.
(00:47):
So to help us unpack how sensorsand MCUs work together to create
a smarter, more efficient system,we've got the perfect guest.
Amit, thanks for joining us today.
Amit Purohit (00:58):
Thank you, Kyle, for having me.
Kyle Dando (01:00):
Sure.
So Amit, Purohit is basically theGodfather of NXP sensor software.
Amit, before we get into all thecool work your team is doing, why
don't you introduce yourself a bit?
Amit Purohit (01:13):
Sure.
Hi, my name is Amit Purohit and I'massociated with the MEMS Sensor product
line at NXP based in Chandler, Arizona.
I've been part of Freescale and nowNXP for more than 15 plus years.
In my previous roles, I worked on digitalsignal processors and later on to power
(01:33):
PC based heterogeneous architecturesfor wireless protocols development.
As part of my current role, I'm drivingthe Sensors development ecosystem and
tools strategy for NXP sensors business.
My focus has been to help improve theease of use for our customers by providing
a good out-of-box experience duringtheir evaluation phase, and creating
(01:57):
differentiated solutions with NXP sensors.
Bridgette Stone (02:00):
Thanks for the introduction, Amit.
We're so happy to have you.
Now, integrating sensors into theMCUXpresso ecosystem has been a
long journey, and you've been at theforefront of this effort for years.
Tell us how it all started andwhat kind of impact this has had
on the sensor enablement at NXP.
Amit Purohit (02:19):
Yeah, sure Bridgette.
So my journey has been apath of continuous learning.
And it is filled with the satisfactionof helping our customers by improving
their development experiencewith the unified set of tools
provided by MCUXpresso ecosystem.
Also, I feel that integrating sensorsinto MCUXpresso ecosystem had optimized
(02:41):
sensors enablement delivery with quality.
I started Sensors integration intopreviously known Kinetis Expert SDK in
late 2016, and have been involved sincethen to support sensors integration to the
latest MCUXpresso SDK that we have today.
It's been over eight plus years ofgreat collaboration with the SDK
(03:03):
team and now when I look back, Isee how the SDK has matured from the
Kinetis Expert to the MCUXpresso SDK.
It has been built into one of the finestdevelopment ecosystems in the industry.
Bridgette Stone (03:17):
That sounds like a massive evolution, and with every
big shift like this, there are alwayschallenges, but I imagine this has also
been really rewarding for you personally.
What's been the biggest benefit for bothyou and the NXP sensor product line?
Amit Purohit (03:32):
Yeah, that's a great question, Bridgette.
Integrating sensors as a middlewarecomponent into MCUXpresso
SDK has been challenging.
Let me tell you, by the way, the sensorsoftware was the first middleware
successfully integrated into the SDK,and we became a reference at that point.
I strongly believe that it hasadded a lot of value and transformed
(03:56):
the way NXP enables customersto design with our sensors.
Of course, these effortshave also benefited me.
I had a great learning experience workingwith the SDK team across the globe.
I have made very good friends whileestablishing mutual respect for the
jobs that we do, but in my opinion,the most important aspect has been that
(04:18):
this integration has provided excellentopportunities to show more of the
complete solution that NXP can offer.
The sensor product line over thetime started understanding the
importance of attaching sensorswith MCU development ecosystem.
And this effort has made it easier forcustomers to successfully pair these two
(04:38):
products to jumpstart their development.
According to me, this has beena good example of the "Brighter
Together" mindset promoted by NXP.
Kyle Dando (04:46):
That's true.
It is.
I think it's a great example of ourbrand of being brighter together, Amit.
Now Amit, you mentioned that the sensorsmiddleware component is a key part of
the enablement, and I like to thinkthat the middleware is that trusted
bridge between the microcontrollerthat you mentioned, and the sensors
that they may want to use from NXP.
(05:08):
So explain a little bit more about whatit is in that sensor middleware but
also show how you have made it a littlebit more valuable for the developers.
Amit Purohit (05:19):
Yeah, thanks Kyle.
I was hoping that you wouldpose this question to me.
So as you're aware, middleware in anSDK, it acts as a glue layer, connecting
the SDK features to the external systemfor extending certain applications.
We created ISSDK, We call itIOT Sensing, SDK, and it's being
(05:40):
offered as a middleware componentin the MCUXpresso SDK ecosystem.
ISSDK combines a set of robust sensordrivers and algorithms along with
example applications to allow usersto get started with NXP sensors.
What we changed there is, we changedthe sensor driver design to come up
(06:01):
with the CMSIS compatible low-leveldrivers, and then we also created easy
to read functional APIs to improve thecode readability for our customers.
This way, we were able todemonstrate a modular and
separable layer-cake architecture.
In summary, implementing CMSIS compliancesensor drivers to connect to peripheral
(06:23):
drivers provided by SDK was one of thekey features that has helped us a lot for
easy porting across the NXP MCU portfolio.
Apart from that, the way we haveexposed sensor register bitmaps for
easy access to configure sensorsis another useful Design feature.
(06:44):
And last but not the least, isthe concept of Board Shield GPIO
mappings that we have added.
This actually helped us to provide aseamless migration to support multiple
MCUs without changing the sensor drivers.
Kyle Dando (07:00):
Amit, you and I worked quite a bit on the CMSIS drivers, and I know
that the feedback from our engineersand customers is that they really
like how those CMSIS drivers allowthe projects to be a little bit more
portable because that common CMSIS drivercan be used across multiple boards.
So that was huge.
I'd like you to drive a littlebit more into how you simplified
(07:22):
things for the developers.
The sensor team has done a great jobof embracing the Arduino connector
and the form factor, and that has madeit really easier for the customer to
take that one sensor or that one boardand move between different products.
So beyond that hardware, how didyou using the Arduino connector and
(07:43):
the Arduino form factor improve thesoftware enablement with sensors?
Amit Purohit (07:47):
Yeah, and that's a great point, Kyle.
Thanks for reminding me of that.
We decided to adopt the Arduino formfactor for the sensor evaluation boards
to better align with NXP's evaluationkits or FRDM development boards approach.
What I really liked aboutthe MCU board design.
Is the way it extends flexibilityto connect, add-on expansion
(08:09):
boards, and provides the freedomto innovate for our customers.
This approach has certainly helpedsimplify sensors enablement.
As I mentioned in my early comment, theboard shield mapping concept that we
added was built since we were able toutilize the Arduino form factor, which
is a standard expansion pin mappings.
(08:30):
And this allowed us to use sensorshield boards like LEGO blocks.
And what I mean by that is, weare providing this flexibility to
developer that they can swap betweenboards with very minor changes in
the respective board shield and GPIOmappings, and they can run the same
examples with no other change required.
(08:52):
With such stickable expansionboard options, we are
offering freedom to innovate.
Bridgette Stone (08:57):
Thanks, Amit.
I know we were talking a little bitabout the power of middleware, and I
think one of the best ways to talk aboutthis is through real world applications.
With all the work that you'vedone, you must have a favorite,
ACH example that really highlightsthe value of sensor integration.
What stands out to you?
Amit Purohit (09:17):
Yeah, so when we started having the sensor middle integration
and CMSIS driver compliance, it actuallyhelped us to move quickly in bringing
up application specific examples.
With the flexibility to portfaster on multiple Cortex-M based
microcontrollers, and combiningmultiple middlewares available for
(09:38):
those MCUs, we are able to demonstratecool application examples through ACH.
My favorite sensor-based ACH examplesare, of course the one showing the
ultra low power wakeup features ofsensors to help optimize overall
power consumption of the system.
Now you might be wondering, out of somany sensor-based cool applications
(10:00):
available on ACH, why I'm choosingthe low power examples, I always
get this question, why do we needto care about low power designs?
Let's look at some interesting numbersand see whether that answers our question.
So based on some estimations by EDNA.
Which is an initiative of theInternational Energy Agency.
(10:20):
By 2030, there will be more than75 billion connected edge devices.
More than one third, that is morethan 25 billion, will be battery
powered iot devices that willbe deployed in remote locations.
The associated energy use and waste frombatteries will be considerably huge.
(10:41):
There's another study done byENABLE, which is an EU funded
research infrastructure project.
According to them, up to 78million batteries will be
discarded daily around the globe.
In next few years, if we do not improvethe lifespan of batteries or reduce
the energy consumption, powering theseIOT devices, this will cause major
(11:03):
Environmental and economic problems.
Currently we are at the 40% of thecapacity to recycle these batteries.
So this tells you why integratinglow power features are very
critical for iot applications andalso for optimizing system battery
power for a sustainable future.
Bridgette Stone (11:22):
That's truly a compelling use case, and thank
you for sharing that information.
It really ties well into a growingchallenge, power efficiency.
With billions of iot devicesexpected to be battery powered.
Reducing energy consumptionis absolutely critical.
So what key sensor features arehelping to drive these kind of
(11:43):
trends for low power optimizations?
Amit Purohit (11:46):
Yeah, that's another very good question, Bridgette.
So many of the key features of thesensors are demonstrated in the ACH
examples, but I can mention just afew of the most important ones here.
Most of our low power sensorsfeature flexible and configurable
digital competitor embedded function,we call it SDCD, that is Sensor
(12:07):
Data Change Detection function.
For example, SDCD functional block formotion sensors implements an inertial
event detection function with the abilityto detect motion events like motion to no
motion detection, tap free fall shocks,and other transient acceleration events.
(12:28):
Such embedded functions allow users withthe flexibility to configure sensor for
required motion, gesture based wakeup.
They don't need to write complexalgorithms to do the post
processing on the raw data.
This is all done by this embeddedfunction block within the sensor.
Another key feature that we havedemonstrated through these ACH examples
(12:48):
is our Auto Wake/Sleep feature.
This feature allow developers tomake the system totally autonomous.
What I mean by that user canconfigure their wake up based
configurations using the SDCD block.
And by configuring auto wake sleep,the sensor can work autonomously.
It can go back to sleep mode when theconfigured wake up event has not occurred
(13:10):
for continuous configured amount oftime, let's say an example, 10 seconds.
If there's no motion wake up happeningfor continuous 10 seconds sense is
capable of going back autonomously.
Then it can wake up again basedon the wake up condition met.
Finally, the developer can findexamples where sensor is configured
(13:31):
to work in the interrupt mode.
That's a very important feature becausethen all of these SDCD and auto sleep
can be tied in with an interrupt feature.
Sensor can raise an interrupt towake up the host MCU and system, or
alternatively raise the interrupt to putthe host MCU and system to deep sleep
mode using auto wake sleep feature.
(13:52):
Combining all these three features,we showcase how our low power wake
up sensors can play a criticalrole in extending battery life
for the overall system solution.
Also, I would like to take advantageand mention that devices are
getting more and more complex withmore competitive content in them.
(14:13):
The low power design aspect shouldn'tbe afterthought, in my opinion.
Rather, it should be thefirst thought when designing
such connected edge devices.
The low power wake up sensor ACHexamples describes how a developer can
use these key sensor features in theirnext design to enable effective power
management for low power operations.
Kyle Dando (14:35):
I've worked with most of the sensor projects in the Application
Code Hub, and I agree that the low powerwake up feature of these sensors is
really powerful and you do a great jobof showing customers how they can get
started and how to truly take advantageof those features in the sensors.
I did notice though that you alsoinclude FreeMASTER in most of those
(14:56):
sensor projects, and this tool,FreeMASTER may be new to our listeners.
We haven't had an episode covering that.
So can you introduce what FreeMASTERis to the listeners and maybe how
you have included it as a very uniquetool that has helped accelerate
sensor development for the users?
Amit Purohit (15:16):
Sure Kyle.
Yeah, and I agree.
I That's a good observation.
So as part of my current role, I'malways trying to find ways to improve
ease of use for our customers byproviding good out of box experience.
During my involvement in integratingsensors into MCUXpresso SDK, I learned
about another middleware component,
(15:37):
and that is FreeMASTER.
This tool was promoted as a runtime debugging tool.
That means this tool was initially createdto have some kind of debug counters, some
kind of watch variables, and when youprovide a debug release debug version of
your binary to customer, they can actuallydo the field debugging in real time.
(16:02):
When I started to learn more about it.
I thought I could use this tool tocreate an evolution GUI tool for sensors.
Some of the cool features of FreeMASTERtool, like ease of adding watch
variables into the memory mapped targetsite addressable, TSA area, their
proprietary communication interfacewith the host and the ease of importing
(16:24):
the TSA map watch variables on thehost GUI helped me to transform this
tool into a sensor evolution tool.
We have successfully adopted thistool as sensor evolution tool.
We integrated sensors middlewarewith FreeMASTER middleware on the
target side for supported MCUs.
Also on the host side, we havebeen able to create sensors control
(16:46):
page that gives easy access tousers to evaluate our sensor specs.
Like full scale range, ODR,Sensitivity, Offset Noise Measurements,
running self-test diagnostics,and configurable power modes.
We also extended the GUI featuresto include a very extensive
(17:07):
registered page for sensors.
Where user in real time can readall sensor registers, modify bit
fields of sensor registers, andsee the behavior in real time.
This is helping customers tonot go through the data sheet.
They can use this tool andevaluate the part very easily.
(17:28):
Also, this tool providessensor data visualization, data
logging, and many other features.
Bridgette Stone (17:34):
Thanks Amit, we're coming up here to our last question.
I wanna talk a little bit aboutwhat's next and in the future.
And we know that Application Code Huband Expansion Board Hub have already
made it easier for developers toexplore and implement new applications.
So looking ahead, where doyou see these tools evolving?
Amit Purohit (17:53):
Well, I've been seeing the pace at which MCU Enablement is
transforming to meet customer needs.
The Application Code Hub andExpansion Board Hub are great examples
confirming how NXP is extending itsdevelopment ecosystem to allow better
engagements with our customers.
While the MCUXpresso SDK tools andevaluation boards built a strong good
(18:16):
foundation for our customers, therealways have been a strong desire from
Open Source developers community tohave a quick and easy way to search
for application specific examples,supporting specific targeted families
with various expansion boards.
ACH provides a list of applicationspecific examples developed by NXP
(18:38):
in-house experts and provides aneasy way to search available examples
by device, family applicationtype, and other categories.
And Expansion Board Hub provides adatabase of NXP and third party expansion
boards to expand NXP MCU EVK capabilities.
Expansion Board Hub also helpedlinks associated enablement software
(19:00):
for bringing up those chosen targetplatforms and expansion boards.
Looking ahead, I would really liketo see our FAEs, Sales team and our
customers to make use of these tools.
And I believe we can achieve thisby educating them and spreading more
awareness on how to use these tools.
And at this point, I would like to sharea success story that I totally loved when
(19:22):
I heard it firsthand from one of our FAE.
This story confirms how these tools arehelping our NXP teams to cross promote,
cross sell, and gain customers confidence.
So recently, an FAE visited a customersite that is in the healthcare space
to discuss NXP's wireless connectivityoffering based on customer's request.
(19:43):
But when he learned more about the usecase, it took him no time to bring up a
sensor expansion board and an availableACH example to quickly demonstrate to
the customer how the sensor featureadds value to the customer use case.
This quick and live action helpedto gain customer confidence, and
(20:04):
customer immediately showed interestin evaluating the sensor part.
I am sure there are more such examplesavailable where were tools and
integration of multiple technologiesto reduce complexities is making a huge
difference in helping our customers.
With this approach, we are driving atrue value proposition for our customers.
Kyle Dando (20:25):
That's a great story.
As a former FAE I spent 10 yearsin the Bay Area visiting customers.
There's nothing more powerful for acustomer or for an FAE than to be able
to plug a board in, go to an examplethat somebody else put together.
And show quickly that what we'retalking about actually works.
(20:46):
Because as salespeople and as customers,sometimes we're skeptical that all
we're doing is hearing a good story.
I think the Application Code Hub andall your sensor examples is the evidence
that the customers really enjoy.
And NXP has done a great job ofpositioning your products along
with the MCUs to make sure thosecustomers have that confidence.
(21:07):
When we explain to them thatwe have a solution, they can
get it, and they can use it.
So thanks again, Amit,for joining us today.
It's just been a pleasureto have you on the show.
we explored how NXP is workingto make sure that sensors and
MCUs are "Brighter Together".
From seamless middleware integration withprojects in MCUXpresso to providing a
(21:29):
powerful visualization tool in FreeMASTER.
We've learned that the Application CodeHub is helping developers discover the
different use cases for the NXP sensorsand these sensor application examples
are helping them bring their projectsto life faster and more efficiently.
Bridgette Stone (21:47):
Thanks again for your time today, Amit.
And if the listeners enjoyed thisepisode, please be sure to Like,
Subscribe and turn on Notificationsso you never miss an update.
And if there's a topic you'd lovefor us to cover, let us know.
We would really like to hear from you.
Kyle Dando (22:03):
So that's it for today.
Keep innovating everyone and we'll catchyou on the next EdgeVerse Techcast.
Popular Podcasts
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
24/7 News: The Latest
The latest news in 4 minutes updated every hour, every day.
Therapy Gecko
An unlicensed lizard psychologist travels the universe talking to strangers about absolutely nothing. TO CALL THE GECKO: follow me on https://www.twitch.tv/lyleforever to get a notification for when I am taking calls. I am usually live Mondays, Wednesdays, and Fridays but lately a lot of other times too. I am a gecko.