Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:10):
Hey everyone, and welcome back to theEdgeVerse Techcast, your trusted spot
for everything related to NXP software.
It's the tools and the enablementthat help developers work with NXP
Processors and Microcontrollers.
I'm one of your co-hosts, KyleDando, and today we're gonna dive
into the wireless side of the edge.
(00:31):
And I am Bridgette Stone.
Whether it's WiFi, Bluetooth, ZigBee, orsomething a little less familiar, wireless
connectivity is more essential than ever.
And today we've got a special guesthere to help us break it all down.
Please welcome Max Palumbo who leadsthe team responsible for delivering
NXP's Wireless Software solutions.
Max.
Thanks for joining us today.
(00:53):
Thanks Bridgette.
Thanks for the introduction.
Like you said, I'm a part of theWireless Connectivity team here at NXP
and I'm a Product Management Directorfor our Wireless Connectivity software.
So my team and I are responsiblefor what stacks we deliver how we
deliver those stacks, and then howthat fits into the overall strategy
and ecosystem for software that wedeliver on all of our compute products.
(01:16):
Okay, Max.
You and I talked and there are a lotof important wireless updates that
you want to share with the listeners,but before we jump into that, why
don't we just help some of thelisteners get a better understanding
of NXP's wireless software overall?
Yeah, for sure.
Yeah, I'd love to talk about thedifferent connectivity software solutions
we have available and how that fitswith our hardware portfolio as well.
(01:38):
So Max, imagine you're stuck inan elevator, I'm sure this has
happened before, with a fellowengineer and only have one minute.
How would you summarize thescope of NXP's wireless software?
And after that, could you tell usmore about what you work on directly?
Sure.
So NXP's Wireless Connectivityoffering is super broad.
We cover a lot of the standards basedprotocols like WiFi, Bluetooth, both
(02:03):
classic Bluetooth as well as lowenergy, ZigBee, Thread, NFC, UWB,
and we dabble a little bit in 5G.
We also support proprietarywireless connectivity standards.
Mainly this is sub-GHz and this is morethe traditional Industrial protocols
like Wi-SUN, and Wireless M-Bus.
(02:25):
So we really cover the gamutof all wireless connectivity
that's out there today.
That's underpinned by the Hardwareportfolio that we have to supplement
the Software that we work on.
My team specifically, we cover the2.4 GHz standards based protocols.
And so what that means, it's WiFi,Bluetooth, ZigBee, Thread, and then the
(02:48):
applications that run on top of themlike Alero, ZigBee, of course has its
own application layer as well as Matter.
So that's mainly what my team focuses on.
Okay.
That's a great overview of the software,but you touched on how this spans
the devices that are provided by NXP.
Can you dive into what part familiesdoes the wireless software support?
(03:12):
So at a high level, our WirelessConnectivity software is a part of
the baseline software enablement thatwe provide in the EdgeVerse platform.
And so what that means is that WirelessConnectivity is a part of the Linux
and Android BSPs for i.MX processors.
We also, as a part of the MCUXpressoSDK, and Zephyr Enablement support
(03:36):
the i.MX RT microcontrollers aswell as the MCX microcontrollers.
So quite broad coverage of where oursoftware is enabled from a wireless
connectivity standpoint, mapping that intothe hardware platforms that we enable.
And, and that's a lot of differentwireless applications, right?
(03:57):
Max?
Yeah.
, It really covers a super broad range.
Because it's so broad, why don't wedive into some of the differences.
The ones that I know about, startingat the top, there are Hosted
devices and then there are modules.
Can you explain the differencebetween using the device as a
hosted solution versus thosethat are more modules or radios?
(04:20):
Yeah, definitely.
When we talk about a Hosted or Standaloneis another term you could use for it.
This is really a wireless SOC thatincludes the radio as well as a
microcontroller or microprocessorcore integrated together.
So that would be like our MCXWfamily of devices or our RW610
(04:42):
and 612 family of devices.
So with those devices,everything runs on a single chip.
The module approach is much more of theclassic modem architecture, where you
have a radio that's running some firmwareto provide lower layers of the protocol,
and then that connects to an externalprocessor like an i.MX RT or an i.MX 8
(05:04):
or a 9 processor where the higher layersof the connectivity stack are running.
So at a high level, those are themain differences between the hosted
and the modular based approach.
Okay, so that's the hosted higher-enddevices and the modules and as
you said, your software handles,whether it's running on the host or
(05:25):
communicating to those connected devices.
What about the standalone case though,Max, maybe in more than microcontrollers?
What is the most restrictive elementof that and one of the biggest
challenges of the wireless team withsoftware for the standalone case
where it's maybe like the MCXW family.
The standalone use case is quitean interesting one because you have
(05:47):
to support the radio controller aswell as the networking stack and the
customer application, all on the samecore, or at least on the same device.
From a software requirementstandpoint that does introduce
some quite unique challenges.
When we build our hardware, we have afixed amount of memory on these platforms
(06:08):
that's both Flash and RAM, and so wehave to give customers the right hooks.
You can think about it interms of knobs and levers.
How do I optimize the size of the NXPsoftware so that I have enough space
left over to build my application on top.
In the MCU universe with the standalonedevices, configurability at build time is
(06:29):
a, a, a really big challenge and somethingwe have to help customers navigate.
The other big consideration forthese MCU devices, they tend
to be a little bit smaller.
They tend to be a little bitlower cost than processors running
Linux or Android or the separateradio and processor architecture.
And so power consumption isa big consideration as well.
(06:51):
When we deliver our software, a part ofthe deliverable is a framework for low
power that enables customers to makedecisions on when to go to sleep and for
how long to go to sleep and how that fitsinto what we as NXP deliver to control
the radio, to run the protocol stacksand to do all of the standards compliant
(07:11):
components that come along with it.
So the standalone use case is quiteinteresting from a software delivery
standpoint because of the limitationsthat come from everything being
integrated into a single platform.
Thanks a lot Max, for walkingthrough all the hardware side.
I want to pivot a little bit and goto what you're hearing from customers.
(07:31):
What are some of the most commonrequirements for customers that are
building wireless enabled products?
What are the prioritiesthey come to you with?
You know, lately there's beenquite a few changes in priorities
we've been hearing from customers.
Historically, usually it'sbeen about power consumption.
How do our customers work with usto build the lowest power products
(07:54):
to get the longest battery life?
In certain applications, mainly thisis with ZigBee and Thread, where you
have to have some devices they'realways powered on to act as routers
and really form that mesh backbone.
A lot of the discussion we havewith our customers is around how
do I get good routing performance?
Sometimes that means RF, sometimesthat means optimizing for latency.
(08:16):
So that's more of the traditional set ofrequirements that we get from customers.
The change we've seen recently isthere's a lot of uncertainty in the
industry that we're seeing relatedto Cyber Resiliency Act compliance
coming out of the European Union.
The uncertainty is trying to understandand contemplate what does this mean in
(08:37):
terms of how I bring my product to market,how I offer support and maintenance
over the lifetime of that device.
And so what that's driving is a lot ofshift from FreeRTOS based ecosystems
like MCUXpresso, to a lot moreinterest in things like Zephyr, where
Zephyr comes along with connectivitystacks as a part of the ecosystem.
(09:00):
And NXP, we support our radio devicesand our controllers with those new
stacks in an open source community.
To provide that software resiliency,long-term availability and clear strategy
on how to do bug fixes and maintenancefor cyber resiliency compliance.
And so that's really been a bigchange in the way that we engage
(09:22):
with customers and the types ofquestions that they've been asking us.
All right.
Well that's a great overview.
Thanks for taking the time.
I think half of our listeners just gettingthat understanding of NXP's portfolio and
the challenges and requirements is great.
But now let's jump into those updates.
You mentioned low power, cyber resiliency.
Lots of challenges thatthe customers are seeing.
(09:45):
Let's talk about 25.06.
It's just released.
What are some of the things thatcustomers have been waiting for.
Something that they want to evaluate withthe new Wireless Connectivity software.
Yeah, there's a couple ofhighlights I'd like to mention.
One of the big enhancements that wemade in 25.06, and this is related
more to our WiFi and Tri-radioproducts, is a feature that we're
(10:07):
calling the Kconfig Memory Optimizer.
The build system we use is modeledafter Kconfig in 25.06 in terms of
how do I pick what features I turnon and off when I build my firmware?
Historically, our software, particularlyour drivers, have been somewhat monolithic
in the sense that we build one image.
It's a big superset image that supportsall the features and functions.
(10:31):
Which is great because it meansthat our customers have access
to all of the functionalitythat we enable in our hardware.
But depending on the type of producta customer is building, they may
not need every feature we enable.
What the Kconfig Memory Optimizerallows is at build time you can
disable the stuff you don't want.
And so this really helps a lot toreduce the RAM utilization, reduce
(10:55):
the Flash footprint of our WirelessConnectivity devices in the MCU universe.
And so this feature is really aimedat giving customers the choice to
only build in the features thatthey need, take out the stuff they
don't, so they can save on memory.
Another feature that we'reintroducing is WiFi Direct support.
(11:17):
This is mainly on the i.MX RT devices.
And where this is coming from is there'sa lot of interest in applications
like screen projection and sharingcontent from your phone onto a display.
Where we're seeing a lot of pull forthis is in two wheelers: motorcycles,
electric bikes and scooters.
Where you want to be able to havenavigational data coming from
(11:39):
your phone to do maps, and routeplanning on the cluster in your bike.
This is a really key feature tooptimize that experience for Android.
And so a third new featurethat I'll mention is in our
standalone narrow band devices.
That's just the MCXW devices.
We just achieved ChannelSounding certification.
(12:03):
This is Bluetooth 6.0 compliance.
This is one of the first devices todeliver that, and we're really proud of
achieving that milestone and being able todeliver a production quality solution to
our customers because we've been workingon Channel Sounding for a long time,
for 2 or 3 years behind the scenes, andwe're now at a point where we can release
(12:24):
that for customers to start buildingproducts using this new technology.
Thanks for sharing all those updates, Max.
And speaking of updates, yourteam has done a lot of work
improving how the SDK is delivered,especially with GitHub and West.
Can you walk us through what'schanged and what benefits
wireless developers will see?
Certainly, the core philosophy formy team and for NXP at large is that
(12:48):
Wireless Connectivity is a part ofour baseline enablement strategy.
So this shouldn't be different orspecial versus how we do other enablement
like graphics or machine learning.
It's a part of the architectureand the ecosystem we deliver.
That even includes 3rd party software.
So things like Matter where NXP, we don'twrite our own Matter stack directly.
(13:12):
We take advantage of the open sourcecode that comes from the community.
We wrap that with the build system andtooling that's needed by the SDK to treat
it like middleware, as it rightly shouldbe, and to deliver a really compelling
developer experience for our customerswho want to build products using the
Wireless Connectivity technology, andas well other middleware that comes from
(13:36):
NXP that's not directly owned by my team.
So things like Graphics, AI/ML,voice processing, security tools.
We want Connectivity to fit intothat ecosystem and to have the
same user and developer experience.
The other advantage that this buysus is it makes it a lot easier
(13:59):
to do bug support and securityupdates on Wireless Connectivity
as well as to get early access.
It's a part of the same architectureand workflow that we use to deliver
all software for NXP processors, bothmicrocontrollers and microprocessors.
And so you don't haveto learn a new workflow.
(14:20):
If you're familiar with NXP'sMCUs or Processors, it's exactly
the same as with Connectivity.
The whole philosophy there is we wantthe overall cost of development and cost
of ownership for NXP's connectivity tobe really minimized for our customers.
You can pick up our software, builda product, and use our tools and
(14:41):
enablement in a way that's verynatural and very easy, alongside
everything else that we deliver.
The final component to that isconnectivity now is integrated into the
baseline enablement that we provide.
And so to be more specific, what thatmeans is that for MCUXpresso, we're a part
(15:02):
of the quarterly release process as a partof the main trunk for all MCU software.
Connectivity is a middlewarecomponent that lives in there.
From an i.MX standpointConnectivity is also a part of the
quarterly Linux and Android BSPs.
We are a recipe that's integratedinto the build system and we
(15:23):
update with that cadence thatcomes from baseline enablement.
And I'm going to repeat myselfon this one again because I think
it really is the key message isthat Connectivity is a part of our
EdgeVerse baseline enablement strategy.
It's the same release methodology.
It's the same tools, it's the samearchitecture for middleware, and we
(15:44):
want customers using NXP Connectivityto have access to the full universe
of other software that we providein a way that's very seamless
and really minimizes the cost ofdevelopment in the cost of ownership.
Well said Max.
That was great.
Why don't I do a real quick recap becausewe covered a lot of information here.
(16:05):
To start off, Max, you did a great job.
You explained the WirelessConnectivity software that NXP
delivers for the different standardslike WiFi, Bluetooth, ZigBee.
Then you went into the differences betweenthe platform supported, whether it's
an i.MX, all the way down to a Kinetiswireless part and how they can be either
(16:26):
a host, a standalone device or a module.
So you did a great job there.
Then you talked about the designrequirements, right, where low
power is becoming key, and otherthings that customers are looking
to NXP to deliver and help solve.
You mentioned 3 things I want torepeat for our listeners in the 25.06
(16:47):
release that just landed this week.
The Kconfig Memory Optimization.
This is a really key improvement that wasmade possible by some of the architectural
changes we've made over the last year.
So people are able to get memoryconfiguration and not just the one size
fits all that NXP provided in the past.
(17:08):
You also talked aboutthat WiFi Direct support.
It sounds like something I mightwant to use when I'm streaming
stuff at my house off my phone.
But all those connected devices that useNXP and want to take advantage of our
WiFi and our other wireless connectivity,you guys are delivering improvements
and in this specifically WiFi Direct.
And then finally Channel Sounding.
(17:28):
I walk through the halls of NXP andI hear Channel Sounding all the time.
So having new support andfeatures in 25.06 is great.
I think the listeners should definitelytake a look at this SDK release
and look at those three features.
And then the last thing,sorry, my wrap-ups almost
as long as your covering it!
(17:50):
But the improvements that have beenmade to the SDK have probably been
as equally important as the inclusionof the Wireless Connectivity.
In the last two years, yourteam and the Connectivity team
has really jumped on board.
And the reason they did it was toimprove the customer experience.
(18:12):
And that's important forthe listeners to understand.
We're not doing thesethings just for ourselves.
The feedback from the customers was theywant a seamless development experience.
They want to use the same tools.
They want to get thesame software delivery.
And your team has done that withGitHub, with the CMake adoption.
Simplifying the way that theycan add connectivity along with
(18:33):
those other important things youmentioned, the video, the touch,
other components that NXP delivers.
So kudos to you and the team.
Great job!
I'm gonna take a breath.
Bridgette, why don't youclose out our wrap up
Max, as a non-engineer, I want to thankyou for making wireless a little less
intimidating and a lot more actionable.
We appreciate you walking usthrough all the improvements today.
(18:56):
Well, thanks so much for having me.
I had a great time.
I'd love to answer any questionsthat our listeners have.
If there's anything you'd like to askus, please feel free to leave a comment.
All right, appreciate that Max.
And for our listeners, if you foundthis conversation helpful and useful,
don't forget to hit that Like button andheck, even more important, Subscribe.
(19:18):
Bridgette and I love itwhen our subscriptions
increase and notify yourself.
What would be the worst thing in theworld is that when we drop a new episode
on Tuesday, you don't get notified.
We don't want any of our listeners havingFOMO, Kyle, and please make sure to drop
us a line if there's topics that youwant us to cover in a future episode.
(19:40):
Your feedback helps us keepthings relevant and very useful.
And until next time, everyone, keeppushing those boundaries and we'll catch
you on the next EdgeVerse Techcast.