Using Eclipse With MCUXpresso SDK v2 and Processor Expert

OK, to be 100% correct, It is not ‘full’ or ‘native’ support of Processor Expert in a MCUXpresso project, but I show a way to get the benefits of Processor Expert (code re-use, graphical configuration, software component packaging, and redistribution) in an MCUXpresso SDK Eclipse project.

pe file is recognized by Eclipse as Processor Expert: We have enabled Processor Expert for the NXP SDK v2 project:

The project now shows the Processor Expert components and settings, although it is for the ‘wrong’ microcontroller/processor (e.g. KL25Z instead of the KL27Z).

Using Processor Expert components with that project, they need to know that they shall work with the NXP MCUXpresso SDK.

For this, the McuLibConfig is added to the project: From the ‘Components Library’, add the component to the project and configure it to use the MCUXpresso SDK:

Next, add an LED component to the project:

By default, the LED component uses the normal Processor Expert BitIO component.

Followed by the blinky code:

I’ve generated Processor Expert code, built and debugged the project, and I have a added a ‘blinky’:

While Processor Expert is not supported with NXP MCUXpresso SDK v2 projects, there is a way to add Processor Expert code generation to such projects.

Getting MCUXpresso SDK v2, Processor Expert, and Eclipse to play together is tough, but Processor Expert’s myriad benefits should not be so easily set aside. @craigbrownphd: Using Eclipse With MCUXpresso SDK v2 and Processor Expert #IoT #Cloud #BigData

To me, software and tools are by far more important than the microcontroller. Silicon is a ‘one time kind of thing,’ whereas the software has to be maintained over a longer time. And, at least when it comes to my software, it usually needs to be ported to a new device, so portability, available software, and tools are critical to me.

The combination of the MCUXpresso SDK (formerly Kinetis SDK) and Processor Expert is, unfortunately, not supported by NXP. But I have found a way to get them work together in a nice way, and this article is about making that combination possible.

If you are not using Processor Expert or the NXP MCUXpresso SDK v2, then you can move on. Otherwise…. and if you are still curious about how things work in Eclipse, read on and I’ll tell you how to do something like this in Eclipse.

OK, to be 100% correct, It is not ‘full’ or ‘native’ support of Processor Expert in a MCUXpresso project, but I show a way to get the benefits of Processor Expert (code re-use, graphical configuration, software component packaging, and redistribution) in an MCUXpresso SDK Eclipse project.

I believe one of the best-selling NXP Freedom boards is the FRDM-KL25Z:

It is inexpensive (~USD 15), has reasonable speed (48 MHz) with decent FLASH (128 KByte) and RAM (16 KByte). The students at my university love that board, too, and a distributor at Embedded World in Nürnberg told me that he thinks this is because of Processor Expert and all the tutorials on McuOnEclipse.

But recently, the university ordered FRDM-KL27Z boards for student projects instead of FRDM-KL25Z. Shouldn’t make any difference, right? Well, it actually does: The FRDM-KL27Z is supported by the MCUXpresso SDK v2, and MCUXpresso SDK v2 projects are not supported by Processor Expert. When students realized that, they wanted to return the boards because, with Processor Expert, it is much easier, simpler, and faster to use the FRDM boards. So I offered for them to exchange the FRDM-KL27Z boards with the FRDM-KL25Z ones I have in my classroom inventor.

Of course, I soon had a pile of FRDM-KL27Z boards that students did not want to use:

That triggered an idea: Maybe there was a way to make these boards usable with Processor Expert so students would again use them in their projects.

In Mother of Components: Processor Expert with NXP Kinetis SDK V2.0 Projects, I presented an approach to use Processor Expert with the NXP/Kinetis SDK (now MCUXpresso SDK). That approach used two projects: a master and a slave project. I have now found a way that uses a single project: enabling Processor Expert for an SDK project and having the ProcessorExpert.pe XML file in a single project:

This article describes how to use Processor Expert for NXP SDK projects, for which Processor Expert is not supported by NXP. Using that approach, it is possible to use ‘generic’ or ‘non-CPU’ components for the SDK. This approach allows carrying over many of the good aspects of Processor Expert, such as code re-use and power software configuration and distribution. In this article, I’m using the NXP FRDM-KL27Z board with Kinetis Design Studio V3.2.0. I’m using Processor Expert components from the McuOnEclipse project.

The approach uses the following steps:

In this article, I’m using NXP Kinetis Design Studio v3.2.0 with the MCUXpresso SDK for the FRDM-KL27Z board, but certainly, any other Eclipse version or SDK version could be used, too. You need:

You can use an existing NXP SDK project for Kinetis Design Studio (KDS) V3.2.0. Or create a new one. To create a new project, use the menu: File > New > Kinetis SDK V2.x project.

Create a normal project. I recommend turning on all drivers, but not enabling FreeRTOS, as the Processor Expert component for FreeRTOS is more capable. So have it set to ‘all drivers’ (so we do not need any drivers afterward) and ‘none’ for RTOS (as we can use Processor Expert for this later).

Next, add a Processor Expert .pe file to the project. For this, I created a ‘dummy’ project just to have a ProcessorExpert.pe file available.

I usually create a new (empty) Processor Expert project using the menu: File > New > Processor Expert project. Select a processor that is supported by Processor Expert (e.g. KL25Z).

Select from the list of Processors (not from the list of Boards):

Select ‘none’ for SDK and turn on ‘Processor Expert’:

Then copy the .pe file from the dummy project into the SDK project:

After that, the ‘dummy’ project is not used anymore and can be deleted.

The .pe file is recognized by Eclipse as Processor Expert: We have enabled Processor Expert for the NXP SDK v2 project:

The project now shows the Processor Expert components and settings, although it is for the ‘wrong’ microcontroller/processor (e.g. KL25Z instead of the KL27Z).

Processor Expert thinks it is for the KL25Z, but we want to use it for our KL27Z SDK project. The ‘CPU’ component kind of represents all the knowledge about the device (memory map, vector table, peripherals like UART, I2C, SPI, etc.). So with such a Processor Expert-enabled project, I use all components that do not depend on that information. That works for pure software components like the RingBuffer or Utility component, or for any of the McuOnEclipse components I have enhanced with the capabilities to work with the SDK v2 API. This includes components like SDK_BitIO, Shell, and FreeRTOS. And the number of supported components is growing, with the goal to port as many existing projects to the SDK v2 and beyond.

So, I have a Processor Expert project for the KL27Z, and I can generate code for it like for any normal Processor Expert project:

However, the non-matching files need to be ignored for the SDK project.

Processor Expert creates the following folders:

To exclude files from the build (so they are not part of the SDK project), use the context menu on the file/folder and enable ‘Exclude resource from build’ (menu Properties > C/C++ build > Settings > Exclude resource from build, see Exclude Source Files from Build in Eclipse):

Do this for the following folders:

Alternatively, the generation for the ‘Project_Settings’ can be turned off in the Build options of the CPU component:

In the generated code, there are three files that are not matching the device of the SDK project. Exclude the following files from the build:

I can now generate code, build, and debug the application:

So this is not much different from any other project. But now I have the power of Processor Expert enabled for the SDK v2 project, which is what I’m doing next: Using Processor Expert to extend the project to blink a LED (‘blinky’).

Using Processor Expert components with that project, they need to know that they shall work with the NXP MCUXpresso SDK. For this, the McuLibConfig is added to the project: From the ‘Components Library’, add the component to the project and configure it to use the MCUXpresso SDK:

Next, add an LED component to the project:

By default, the LED component uses the normal Processor Expert BitIO component. Change it to use the SDK_BitIO component, available in the drop down for the ‘Pin’ settings:

This now uses a generic BitIO component, which uses the SDK API:

Checking the schematics of the board, I can see that the Red LED is on PTB18 (GPIOB, PORTB, Pin 18):

With turning on the ‘Do Pin Muxing’ option, I don’t have to care about the muxing.

The component cares about the muxing, but not about the clocks. So I have to add the following inside BOARD_InitPins(). Otherwise, I will run into a hard fault:

Because I want to delay the blinking of the LED, I add the Wait component, which allows me to burn CPU cycles:

In normal Processor Expert projects, the components get initialized in PE_Low_Level_Init(). For the SDK project, I have to call the Init functions in my code.

I include the component header files:

Inside my code, I initialize the components:

Followed by the blinky code:

I’ve generated Processor Expert code, built and debugged the project, and I have a added a ‘blinky’:

While Processor Expert is not supported with NXP MCUXpresso SDK v2 projects, there is a way to add Processor Expert code generation to such projects. It adds re-use of software components and a way to graphically configure software and drivers. It works with ‘software’ components or components of the McuOnEclipse projects, which have been enabled to be used with the SDK v2. This approach closes a gap the NXP SDK v2 has created with no graphical driver or peripheral configuration.

An extended example project used in this article can be found on GitHub. It also shows the subset of currently supported components and drivers, which is growing and growing: