Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Kyle Dando (00:10):
Welcome everyone to
the NXP EdgeVerse TechCast, where
you will learn about NXP software,tools, and enablement that supports
NXP processors and microcontrollers.
My name is Kyle Dando, andI'm excited this is our first
episode.
Bridgette, it's great
to have you back.
Bridgette Stone (00:30):
Yeah, happy to be here
and the other half of this hosting duo.
Kyle Dando (00:35):
Yeah, and
we have our first guest.
So, Jimmy, you are number one.
And I've worked with you for the pastfew years and learned to really respect
the, you know, intelligence and thecreativity you bring to the SDK at NXP.
So why don't you take a moment and justintroduce yourself to the listeners?
Jimmy Chen (00:55):
Yeah.
Thanks for having me in this call.
My name is Jimmy.
I am from Shanghai, China,and that's also my location.
I am working as a SDK architect andalso as a team lead for the, we call
Core Software team in the SDK project.
The team covers a lot of stuff likecreating drivers, build system,
(01:18):
process, driving release for the SDK.
Basically all the things tomake the SDK release happen.
I joined NXP 13 years
ago and moved to the SDK
project 10 years ago, since it's day zero.
In the past 10 years, I work with a lot ofcolleagues to define 3 generations of SDK.
(01:41):
It's very nice to grow myselfwith evolving of the SDK following
the change in the MCU world.
Bridgette Stone (01:49):
Jimmy, we're so very
excited to have you and let's dive
right in, and we're going to starthigh level since I'm a non engineer.
As the lead architect for ourMCUXpresso SDK, can you explain the
main users of this tool and its purpose?
Jimmy Chen (02:04):
Sure.
The SDK is software provided by NXP.
That is necessary to get anNXP microcontroller running.
Generally, the SDK includes threelevels, from low level to high level.
The lowest level is the startup code and drivers, low level
setup and configurations.
(02:26):
NXP makes sure customer hasworking example on how to properly
get started with the device.
The middle layer is themiddleware software.
NXP software supports a lot ofvariants, like the audio, Bluetooth,
graphics, AI ML, cloud, and so on.
(02:49):
This software providescustomers well defined APIs.
API is the ApplicationProgramming Interface.
This make it easier for customer toadd this technology to their product.
The highest level is application software.
NXP provides projects that demonstratepopular application, such as
(03:12):
Brushless Motor Control, MQTT,Cloud communication, Matter, ZigBee
end device, and Bluetooth Beacon.
This example project may requireporting standard application to
the SDK middleware like Matter.
However, in some situation, NXP providesmore complex examples that integrate
(03:36):
multiple drivers and the middleware toaccomplish the popular applications.
Kyle Dando (03:42):
That's great, Jimmy.
Got a very clear answer and Iknow you work a lot on these
different levels of the software.
But what we're really excited to haveyou here to talk about is the new SDK.
So you mentioned you've workedon three different generations
(04:02):
of the SDK while at NXP.
So have they all been challenging?
Jimmy Chen (04:07):
Yeah, they're
all quite a challenge.
We introduced quite a lot of changein the new SDK, but there are two main
directions that drive us to the new SDK.
One is to make the technology weuse internally as similar as what
customers use in their environment.
Another one is streamliningthe integration into
(04:29):
standard applications such as
Zephyr and Matter.
There are
three items worth to mention.
The first one is we takeGitHub as the primary source.
It provides a custom online versionof the same code, maintained and
used by NXP internal developers.
(04:49):
The second one is the West Manifest.
With the West Manifest,It's able to distribute the
management or code contributions.
Primary software group are integratedfrom West Git repo, Recipe, or Manifest.
Last one is the CMake and KConfig.
(05:11):
We consolidate to deliver one standardproject format with this technology.
CMake is quite popular.
It's used by many projects.
With this technology, we reducehaving multiple formats in SDK
that are never used by every
customer.
It allows
(05:32):
customer to generate project
to their desired format from CMake seed.
Bridgette Stone (05:40):
This really helps
me understand, Jimmy, all the
great additions and improvements.
Thanks for breaking it down for us.
As we move forward, can you providemore context for any software
developers that are listening?
You know, what are the key benefits ofthese changes to how we are using GitHub?
Jimmy Chen (05:58):
There is popular saying
that GitHub is the largest Social
Network for software developer.
SDK's users are all software developers,so we get a lot of good reason to take the
GitHub as the primary delivery channel.
In previous generation of the SDK, theprimary way of delivery is a zip archive
(06:21):
created from the internal code repo.
GitHub delivery was a convertedversion from the internal repo.
But this is problematic.
This way of GitHub delivery is notefficiency and error prone because
it needs additional convert steps.
(06:41):
And what's worse, it createsdifferent world for external
user and internal developer.
We as internal developer don'texperience the same as the external user.
So a lot of times we ignorewhat users are suffering from.
Now, the new SDK delivery is exactly thesame as the internal repo, the same patch,
(07:07):
the same granularity, the same text.
With this change, we alignthe development experience.
We can easily sync the preview version ofcode base to GitHub for early evaluation.
Users are able to previewa patch, see bugs early on.
We push the preview version of code toGitHub on each first and second month
(07:33):
of quarter and release the ready forproduction code in last month of quarter.
This aligned internal external repo makeanother difference comparing to LexiWay.
Previously, for each job into theGitHub repo, there's a monopatch,
(07:54):
including all the change.
This huge patch contain maybearound 100 or 1, 000 lines.
It's not possible for ourusers to check the change.
Now the patch granularityis the same internally.
So it is in the unit of onesmall feature, one small bug fix.
(08:16):
User are able to use native git commandto get the commit message for each patch.
Commit message is a short summary for thepatch, and user can also understand what
exactly changed for that specific featuresby reviewing the patch file difference.
Also with this change, it make iteasy for users to Dev Ops testing.
(08:39):
Comparing to the zip archive way, if ourcustomer or user want to do the Continuous
Integration or Continuous Validations,they need to download the archive on zip
archive and insert into their project.
It's not that easy because it'snot standard way and for a lot of
(08:59):
times it cannot be automated at all.
With the GitHub delivery, our customercan easily drag the SDK into the
code base with standard commandand do the Continuous Integration.
And they can detect the earlybugs in an automated way.
Kyle Dando (09:19):
Jimmy, the way I look
at it is the archive zip format
has been so popular and a lot ofdifferent suppliers provide zip format.
So, NXP, we're going to continueto provide the zip format.
I mean, it's pretty popular andsome people like the consistency.
But the benefits that you justoutlined for GitHub, we see more
(09:40):
and more customers asking for this.
So, it's exciting nowthat we've added that.
One of the things that I'vethought has been really cool,
Jimmy, is the adoption of West.
So, this is something that hasbeen made popular with Zephyr.
They introduced this West tool.
(10:03):
It really helps peopleuse a lot of repositories.
You've talked about the, using GitHub,can you talk about how we've added West
and the West manifests into the design?
Jimmy Chen (10:17):
Yes, it's about how
we manage a lot of repositories.
If we go back to 10 years ago, SDKs areonly for resource constrained devices,
and there are only two or three engineersworking on the project, so we can put all
the code in one repo, it's easy to do it.
But now, the SDKs support reallypowerful crossover chips, like
(10:42):
the i.MX RT, with a lot of memory,with very high CPU frequency.
And the SDK grows into a bigsoftware collection from several
tens of vertical domains.
Each of the vertical domains get theirown repository, maybe more than one.
It's really a challenging workto connect these 100 plus repos
(11:07):
and make them work together well.
West is a tool to manage multiplerepos from the Zephyr project,
it uses human readable YAMLformat to record different repo.
And the nice thing is it gets verysimple command line to fetch code
from the repo or group of repo.
(11:29):
We don't need to remember avery long, complex command
parameter to achieve this work.
Kyle Dando (11:36):
So that's the default.
West tool.
But Jimmy, what you and yourteam have done is really great.
You've added some West commands.
So why don't you talk about whyyou did that and what benefit
that adds to the NXP SDK.
Jimmy Chen (11:52):
Yeah, that's, uh,
my favorite part of the West.
It's command extension system.
It allow us to create NXP extensionsto glue many steps into single command.
A typical MCU software creation.
Not only writing the code.
It's about the builds the code toimage and flash it and debug it.
(12:18):
Only with all this stuff covered,you can see the hardware is
printing some characters.
So we created the west buildcommand to build source code into
image for different toolchain.
It includes ARM GCC, IAR and MDK.
We also have the flash command toprogram the image into the hardware.
(12:43):
And we have the debug command todebug the image into the hardware.
And this extension system provides usa lot of flexibility to create more
commands to ease the use on the SDK.
Kyle Dando (12:58):
Yeah, one of the commands
that I really like, Jimmy, you just
created was the freestanding project.
So now people have the ability to takethe SDK and with the West command, they
just put in a simple, easy to followcommand and they get a standalone project.
So you guys have done a lot ofgreat optimization to help our
customers use the SDK quickly.
(13:20):
So that's great.
So Bridget, there's one more question.
I want to ask Jimmy, uh,you taking notes here?
Bridgette Stone (13:26):
I'm taking notes.
And one of the key things, thekey takeaways is that software
development requires automation.
And it is so cool to seethe big steps we've taken in
these milestones to get there.
And just like.
Engineers and developersusing our tools to create end
products, increasing automation.
(13:47):
We're doing that with our owntools to help improve their
developing and debugging.
It's very cool to see.
Kyle Dando (13:55):
Yeah, I've had conversations
with customers where, as Jimmy, you
mentioned, the Continuous Integration,the ability now for us to have our SDK,
which is so important, online, up todate, they can see the changes, they're
working with the same changes in thecommitments that our developers are using.
It's going to make our customersway more efficient using our SDK.
(14:19):
So again, great alignment with theautomation in the DevOps that are
becoming more and more important.
But one more key improvementthat we've made with the new SDK.
Jimmy is our closer alignmentwith some of the open standards.
(14:41):
And what we've done is we've reallyleaned in on CMake and Kconfig.
Can you talk about CMake and howthat maybe helps us with choosing
a very popular standard versus somany things for so many people?
Jimmy Chen (14:57):
Yes, I believe all
the MCU vendors providing SDK
need to deal with this challenge.
The challenge is about support differentformat or project such as CMake, IAR, MDK.
Each of this project format get quitea lot of customer stick to it, and
(15:20):
we must support almost all of them.
It's inefficiency to maintainthem separately, and not every
customer use all of them.
Previously, we define a unifiedformat to describe the project.
It's a in house standard.
(15:40):
It works functionally.
But it again place the internal developerand external user on different page.
Internal user is using theinternal format and external
user using the converted format.
In the new SDK, we take the CMakeand KConfig as a unified format to
(16:01):
describe the project and the component.
CMake and KConfig are very, very popular.
Majority of project in GitHub isusing the CMake and KConfig such
as the Zephyr and the Matter.
By using the CMake as a unifiedformat, it speeds up our integration
(16:24):
into the Zephyr and Matter for otherproject format we can take the CMake
as the seed to generate on demand.
Thanks to the flexibility of the CMaketechnology, we can create a customized
CMake extension to provide the furtherfeature on top of native CMake function.
(16:46):
For example, we use CMake extensionto generate other project format from
the CMake with usual CMake parameters.
We also use the CMake extensionto wrap SDK specific configuration
in modular way, so our users don'tneed to read a long, flat CMake
(17:08):
line, and it's much more readable.
Kyle Dando (17:11):
Yeah, that's a big
improvement, and it does follow what
we've seen with other software kits.
Where if you open up our CMake now,it's it's very abstracted and so
people can dig in and understand whatthey're writing, but they don't have
to look at hundreds or almost 1000lines of configuration for the project.
It's built upon those CMakeextensions and those CMake
(17:34):
commands that you just described.
So we're excited.
I think it's going to be somethingthat a lot of the customers enjoy.
Uh, Bridget, is there anythingelse that you want to ask Jimmy
before we let him go on his way?
Bridgette Stone (17:51):
I just want
to thank him for his time.
This was a lot for me to learn andit's, it's just really neat to see the
innovation that we're doing and howwe're making the lives of the developers
easier using NXP software and tools.
Kyle Dando (18:08):
Yeah, so Jimmy again to
recap what you shared so well is number
one, we're really on board with GitHub.
Our new SDK is taking advantageof some of the things that
our customers been asking for.
And so if they download the latestGitHub repository, they're going
to see some extreme benefits.
You've also added West and thatmakes it much easier for us to
(18:32):
engage large amounts of repositories.
We can organize them into what I call themanifest is like the recipe and so we can
provide multiple recipes or a customercan take it and customize their own West
manifest and pull in our software, andpull in maybe some third party software.
So taking advantage of West has done that.
(18:53):
And then CMake, Jimmy, you broughtit up that it's one of the most
popular ways to describe projects.
I talk with so many partners,and they all say, Hey, can we
integrate with your software?
And I say, Sure.
And they say, We love CMake.
And so I think this is going toallow Our third party partners, as
well as our customers, look at ourprojects and engage a little quicker
(19:16):
because they're able to understandthe format of the examples and the
middleware that we're putting together.
Well, Jimmy, thanks again for joining.
Is there anything that you'd like to tellall the listeners before we sign off?
Jimmy Chen (19:30):
No Kyle, I
have a great time here.
Bridgette Stone (19:33):
Thanks, Jimmy.
We were so happy to have you heretoday and for being our first guest.
We really appreciate it.
We're excited to keep this going on aregular basis, and we want to make sure to
ask our listeners to like, and subscribeto this tech cast and make sure you sign
up for notifications on new releasesand also please drop us a chat in the
(19:54):
notes or the comments for suggestions onadditional topics for future episodes.
Kyle Dando (19:59):
All right.
Thanks everybody.
And, until next time, enjoy the EdgeVerse.