There are many different aspects of Open Source projects: It is not only about the fact if the sources are available (‘open’). It is about the licensing terms (how permissible is it, what can I do with it), maintenance and continuous development (what has changed between releases), how and where is it delivered (Sourceforge, dedicated distribution, packaging) up to collaboration (how can I contribute or submit issues).

NXP has now published the MCUXpresso SDK on Github:

Something I was waiting for a long time.

NXP provides the SDK (at least the part of it which is NXP IP) with a very permissible BSD-3 license or see this license file on GitHub. The SDK is a set of device drivers (UART, SPI, USB, …), middle-ware (GUI library, RTOS, utilities, …), example projects, documentation and information for flash programming and debuggers.

Zip File Approach of the Past

The current SDK package concept so far used by NXP is basically a zip file which can be configured and downloaded from https://mcuxpresso.nxp.com or directly from the Eclipse based MCUXpresso IDE. That SDK concept is OK for a single project or device. For a more common development flow it is not good:

• Per Device: It requires a separate SDK package/zip file for every device. Using multiple devices means having many SDK zip files, each around 50-120 MByte in size, and the zip files are maybe 90% the same, with just some device specific information being different. I want to have an SDK which includes all the devices I need, not multiple single device SDK.
• Upgrade: You are on version 2.8.0, now 2.9.0 comes out with a new zip file: what are the changes? You have to compare the content of the files, making it really hard (or even impossible) to upgrade a project to a newer SDK version, especially if I had to do patches or changes to the previous SDK. I want to have an SDK which makes it easy for me to switch between versions with just providing a Tag for a checkout.
• Build Integration: the zip file approach means that I have to integrate the SDK myself into my CI build system or build server. It is doable, but painful: I rather would pull all the files from a repository and I’m done. The zip file approach makes it difficult for a distributed engineering team: I have to distribute the SDK zip files and make sure it is built the same: having it pulled from a VCS makes things a lot easier. Sure I can put up the files of the SDK zip file on my own repository, but then again I will hit a wall if a new SDK version comes out. I want an SDK where I can pull things from an official site to be integrated into my builds.
• Issue Tracking: There has been no transparency what has been changed or fixed from one release to another, except with the information in the release notes. How to be sure that the issue I have reported in the forum is addressed in the new release? I want to see what is changed on-going and pull from it if needed, and I want to be able to submit issues and PR’s (Pull Requests) to improve the SDK.

The good news is: most of this automatically gets resolved by hosting the SDK on public VCS like GitHub :-).

MCUXpresso SDK on GitHub

The Github repository not only hosts the sources, but as well the release(s):

The previous ‘zip approach’ does not go away according to the information provided by NXP:

The ‘classic’ Zip file releases (MCUX_* on the bottom of the image) are still there, and they seem to get pulled into the GitHub main branch. I suspect that the engineering development not really happens on GitHub but on another (NXP internal?) repository and the changes get pulled in into the GitHub branch and from time to time released as MCUX_* zip file deliverable. The mainline might not include everything, but it is still massive improvement from seeing just the MCUX_* releases.

Now I have more transparency what gets changed or improved, and I can see and use changes and I don’t have to wait for the next release.

I can fork the repository and add my own changes and then do a pull-request to get my changes integrated. As of today, there are already 9 forks and I expect to be many more in the next weeks:

The big advantage of a fork is that you get your own copy, you can do changes under version control and decide if you want to contribute things back via PR (Pull Request). There are already some PR’s open:

But the Readme.md for now has this:

Currently we are not ready to accept contribution, you could create an issue to suggest a new idea or track a bug. Contribution will be open soon.

So I expect that PR’s will be handled soon too.

Using with NXP MCUXpresso IDE

The SDK includes cmake make files. But it is easier to start with an Eclipse managed make project. The process is basically:

1. Clone the git repository
2. Create a new ’empty’ project and assign the MCU to be used in the project settings
3. Create a CDT Build variable (e.g. GITHUB_SDK) and use it to point to the header file directories
   

   SDK includes

4. Link to the needed source and driver files in the SDK (I prefer to link, but copy is fine too)
5. Create a main.c and call the needed driver initialization

Within a few minutes, I was able to get a basic SDK project created from an empty project and able to debug it with the MCUXpresso IDE 11.3.0:

It is for sure not as straightforward as using the SDK wizard which uses the ‘zip’ version of the SDK, but for a medium or advanced user the above steps are pretty easy. And maybe NXP comes up with a simple wizard to do the above steps soon too. So I believe things will get even easier over time.

Summary

These days developers use version control systems, and having the NXP MCUXpresso SDK hosted on a GitHub repository by NXP makes a lot of sense. I think that step has been long overdue and is a good one to make the SDK better over time. Not sure why usually vendors are reluctant to do this step? Of course distributing things as a zip package or similar is easier, because it is just a one-way distribution way. But to have a successful open source project, you need to consider user collaboration with PR’s and a good ticketing system which GitHub provides. Of course this requires governance and engineering efforts from a vendor, but on the long term this makes software projects successful with a large community.

Happy Githubing 🙂

Links

• GitHub repository: https://github.com/NXPmicro/mcux-sdk
• MCUXpresso Software and Tools – New Releases Avail… – NXP Community
• MCUXpresso web site: https://mcuxpresso.nxp.com
• MCUXpresso IDE 11.3.0