Mother of Components: Processor Expert with NXP Kinetis SDK V2.0 Projects

Unfortunately, now the NXP Kinetis SDK V2.0 does not include Processor Expert support (see “First NXP Kinetis SDK Release: SDK V2.0 with Online On-Demand Package Builder“). But at the Lucerne University we are using more than 150 different custom Processor Expert components we would like to use with that new SDK. So how to make them working with the Kinetis SDK V2.0? Using a Processor Expert as “the mother of all components”:

NXP Kinetis SDK V2.0 and Processor Expert Side-by-Side under Eclipse

NXP Kinetis SDK V2.0 and Processor Expert Side-by-Side under Eclipse

Processor Expert

Processor Expert is a plugin in Eclipse which is used to create embedded applications for Freescale and NXP microcontroller. It has the concept of software blocks and components: I add software components and blocks to the project, configure them and it will generate normal source code I can use in my applications. If you are unfamiliar with Processor Expert, have a read at Overview: Processor Expert.

The core of Processor Expert is a knowledge base: it knows about the pins, peripherals and clocks of the microcontroller used. For example when I add the UART or I2C component, it knows about the microcontroller capabilities for UART and I2C and can configure the component. That knowledge is in the ‘CPU’ component.

CPU Component and Settings

CPU Component and Settings

CPU Package

CPU Package

Component Development Environment: User components

I can create my Processor Expert components and we have created more than 150 at the university: from simple device drivers up to complex networking stacks) using the ‘Component Development Environment’ (CDE). These are ‘user’ components as they are not provided by NXP/Freescale.

Such user components can inherit from existing components. For example a user LED component can inherit functionality from the build-in BitIO

LED Component Inheritance

LED Component Inheritance

Or a user sensor can inherit functionality from an I2C or SPI component to use it to use a shared bus.

Until the advent of the Kinetis SDK, there were two types of APIs and components:

  1. Non-LDD’ components or ‘Beans’: they the ‘original’ and first ones. A simple and straight forward API, easy to use.
  2. LDD’ (Logical Device Driver’ components: these components are using mostly a ‘device handle’ in the API: in general, more powerful and usable in a multithreaded system, but more difficult to use especially in a bare metal system.

To support both types of APIs from a user component is possible, but requires a dual interface. Over time most of the McuOnEclipse components can support and use both types of components (see There is a Time and Date for both Worlds).

Dual Component Interface for FatFS

Dual Component Interface for FatFS

Kinetis SDK V1.x and Processor Expert

And then, there was yet another change with the introduction of the Kinetis SDK. Up to that time the Processor Expert components were producing full drivers source code: all the source files and header files. With the Kinetis SDK this changed: The Kinetis SDK is providing the driver source files. The Processor Expert component does not generate the driver code any more, it generates the configuration structures and files for it.

Kinetis SDK V1.3 Project with Processor Expert

Kinetis SDK V1.3 Project with Processor Expert

With some tweaking, I was finally able get some user components (e.g. the one for FreeRTOS to work with Kinetis SDK V1.x) because NXP still was providing CPU components for the devices supported by the Kinetis SDK, plus components e.g. for UART and GPIO. Because the SDK API is different from SDK V1.0 to V1.1 to V1.2 and V1.3, different components had to be used for each SDK version.

Kinetis SDK V2.0

The new Kinetis SDK V2.0 (see First NXP Kinetis SDK Release: SDK V2.0 with Online On-Demand Package Builder) made an even bigger change: From that version on there is no CPU component and no components e.g. for GPIO and UART: all is in plain C source files and header files. So how could I continue to use all the user components with the Kinetis SDK V2.0: using the SDK V2.0 drivers combined with the ease-of-use and configuration power of Processor Expert component?

Approach

The problem is this: there is no CPU component or the possibility to create a Processor Expert component for the Kinetis SDK. But I could use a Processor Expert project (for any Processor) to create source code, and use them in a normal Kinetis SDK V2.0 project J. That works pretty well for pure software drivers (like the Utility component) where there is no dependency on the hardware. But as soon as there is an interface to the hardware (timer, pin, peripheral, clock) I have to provide and use the API of the Kinetis SDK.

Kinetis SDK Component

So the McuOnEclipse components have to deal with multiple API’s: the component itself can already differentiate between non-LDD and LDD components. But for the SDK I need to tell the component(s) what kind of API I’m using. For this I have created the ‘KinetisSDK’ component were I can specify the SDK to be used:

Kinetis SDK Component in a Project

Kinetis SDK Component in a Project

Inside that component, I specify what SDK version shall be used:

Version of the SDK used

Version of the SDK used

💡 SDK v1.3 support is now experimental only.

From the other components I’m referencing that SDK component:

Link to SDK Component

Link to SDK Component

That way the component has all the information needed.

One problem remains: how to use the microcontroller peripherals from my user components? One really cool thing with these Processor Expert components is that they can inherit from an another component using a common interface. I can replace say the Processor Expert BitIO component with a GPIO component which uses the Kinetis SDK instead. The SDK_BitIO component is such a component: it is a replacement of the NXP provided BitIO component:

BitIO Component

BitIO Component

 

SDK_BitIO

SDK_BitIO

For the LDD and non-LDD components, because there is the CPU data base and knowledge base behind it, I can select the pin used from the available pins:

BitIO Pin Selection

BitIO Pin Selection

Because there is no CPU component data base for the SDK, the pin used has to be specified directly by the user:

Port Pin for SDK BitIO

Port Pin for SDK BitIO

Wherever I could use the BitIO component, I can pick and choose the SDK_BitIO component one: For example in the LED component I choose the SDK BitIO one:

Selecting SDK_BitIO Component

Selecting SDK_BitIO Component

That way a component can use the SDK version of a GPIO pin:

LED with SDK BitIO

LED with SDK BitIO

Processor Expert ‘Mother’ Project

To generate the code for the SDK project, I need a ‘mother’ project: a dummy Processor Expert project which I can use to configure the components and to generate the code. The generated code is then used in SDK project.

Mother project on the top with the SDK project on the bottom

Mother project on the top with the SDK project on the bottom

That ‘Mother’ project is used as the host for Procesor Expert and the components, and will generate the source files. In the above picture I’m linking to the Generated_Code folder from the SDK V2.0 project. With that approach I need to tell the compiler where it finds the header files in the project settings of the SDK V2.0 project:

Include Settings in SDK Project to find the Processor Expert Headers

Include Settings in SDK Project to find the Processor Expert Headers

Inside the Processor Expert ‘Mother’ project I have added my components and configured them to use the SDK V2.0 as a setting in the KinetisSDK component:

Version of the SDK used

Version of the SDK used

What to Exclude

The ‘mother’ Processor Expert has no knowledge about the SDK V2.0, except the things I tell it with my KinetisSDK component. Therefore there are as well files generated in the mother project which I cannot use. To avoid that they are included, I exclude them from the build:

Exclude Resource from Build

Exclude Resource from Build

Typical files to exclude are Cpu.c and PE_LDD.c:

Disabled Processor Expert Files for SDK Project

Disabled Processor Expert Files for SDK Project

Some Processor Expert have a PinSettings component in it by default: For SDK V2.0 projects disable it with the contex menu so it has the ‘x’ in the icon:

Disabled PinsSetting Component

Disabled PinsSetting Component

What is not covered

There are several things which are done in the Cpu component which now is not available with the SDK V2.0 approach outlined here. Instead, the ‘normal’ SDK V2.0 functions have to be used from the application code:

  • Vector table: I have to set-up the interrupts and the interrupt table
  • Pin Muxing: muxing of pins need to be performed as part of the initialization
  • Port clocking: any clock gates need to be enabled

Because all the Freescale/NXP provided components (BitIO, InternalI2C, AsynchroSerial, …) are not open and I cannot edit them, they are still not usable for SDK V2.0 projects.

Summary

Processor Expert really makes my life easier and I’m more productive. I need to get there with using the SDK V2.0 as well, and re-using Processor Expert for that SDK definitely helps. I think I have found a reasonable way how to continue using Processor Expert with the Kinetis SDK V2.0. That approach works very well for the McuOnEclipse user component, but it does not allow me to use the closed Freescale/NXP components. Enabling my components for the SDK V2.0 is still work in progress (see “McuOnEclipse Components: 8-May-2016 Release“). If time permits, I could come up with some SDK V2.0 components for UART, I2C, SPI, USB, maybe?

I’m woring on a step-by-step tutorial to use the approach outlined in this article, so that tutorial should be published next, stay tuned!

I appreciate any comments on this ‘mother project’ approach.

Happy Mothering 🙂

Links

Advertisements

34 thoughts on “Mother of Components: Processor Expert with NXP Kinetis SDK V2.0 Projects

  1. I admire your work Eric 🙂

    I am a bit concerned though. You seem to know a lot about what NXP plans for the future. Since you have spent a lot of effort (and appear to still need more effort going forward) on hacking Processor Expert to work with SDK v2, does this mean you don’t see NXP releasing their replacement for PE any time soon – if ever ?

    Like

    • Hi Geoff,
      I have several research projects at the university ramping up which are considering devices like the K82 which are supported by the SDK V2, and for which we would like to use our existing components.
      I cannot predict the future, but I have I need something which can leverage the investment we did into these components (several man years) and get them working with the SDK v2.0, and now. And I think/hope/expect that the presented approach will work for the future. At least for us it worked so far pretty well: not ideal, but does the job so we can re-use the component code in an easy way.

      Like

    • Just got done with NXP FTF. They demoed some new, unreleased tools to make life easier (see kex.nxp.com, especially the grayed out options in the “tools” dropdown), but the PEx component replacement (Peripherals), while on the roadmap seems a long way out.

      Like

      • Yes, these tools look very promising, and yes, they are just the start with the Pins and Clocks. I guess we have to use the ‘normal’ SDK approach until the one for the peripherals/components comes out.

        Like

  2. Hi Erich, seems like SDK2.0 alignment of CPU component will help your goal to reuse the already made components with the mother of components (like!!!!), true ?

    Best Regards
    Stanislav

    Like

    • Hi Stanislav,
      not sure what you mean? I believe the SDK V2.0 structure has much improved over the SDK v1.x, so I definitely want to use that one. What would make things simpler if there would be seomething which I could use in my components to select say the peripheral. Right now I have to type in ‘GPIOA’ and cannot select that from a list, because the component don’t know what is ‘available’.

      Like

      • Hi Erich,

        you mentioned specific isuess (Interrupt Vector Table,…) not working here, typically supported by CPU component. So that’s what I addressed, CPU component should be SDK 2.0 aware to help here.

        Like

  3. Hi Erich,

    I like your PE components. You obviously spent a lot of time to create this solid and useful building set. I used some of the components in my last project too. It saves a lot of time for me and I could concentrate my time for the real application. Also for me it is frustrating, if in each new project all has completely changed. It makes definitely no sense to reinvest the wheel always new. I appreciate your workaround for SDK V2.0 to keep the huge investments.

    Thanks
    Michael

    Like

    • Hi Michael,
      yes, that’s exactly my motivation too. Software in my view lives much longer than hardware and needs to be migrated and maintained over the year. For hardware you make one revision, and you swtich to the next revision (if any) while there are much more steps and a longer life for software. So I would like to re-use my components as much and as long as possible.
      Erich

      Like

  4. Hi Erich,
    Love your work. Thanks for trying to bring sanity to what seems a clueless management decision…
    I, for one, am still wondering whether we will continue to use NXP/Freescale parts. PEx was one of the motivating factors for us moving up from the 8 and 16-bit parts. We were able to move forward quickly without a lot of re-learning. When the SDKs started coming out, we discovered (sadly) that the MKE series parts were not (and are not) supported. Now they’ve effectively orphaned the PEx as well. What motivation do we have to stay with this environment?

    Like

    • Processor Expert is still here for all devices it supports, and this was confirmed today at FTF. NXP is (and has) consolidated on using the SDK as their standard way to deliver runtime software. Which is a good thing to me, given the multiple ways, APIs and implementations before that. So making things consistend and using a stable API (that was said today as well that SDK v2.0 is considered as ‘golden’ and won’t change in the foreseable future) is a good thing, and from that perspective the ‘beans’ and ‘LDD’ API in Processor Expert has to be a thing of the past: it does not make sense to carry forward multiple driver versions and implementations.
      I think that the new tools (see previous) comment will fit well into that SDK strategy, and make things easier to adopt. I’m an Eclipse lover (and many others are), but to be realistic: Eclipse does not work well for everyone. And so far to use Processor Expert you had to use Eclipse. Now with the new tools not tight to Eclipse I think the adoption rate of code generation tools will be much faster and larger which is a good thing for me. And the new tools work with any IDE, including Eclipse. And it was said today as well that these tools will cover LPC *and* Kinetis *and* Cortex M devices in i.MX: This is a great motivation for me to stay in this environment as it greatly expands the number and performance range of devices where I can use these tools.
      I agree with you that with the SDK V1.x I had a huge learning curve and it was difficult to use it. But the same time I see that with the SDK v2 things are much improved, so I really want to use it. There are clearly some gaps, but NXP showed today that they are going to close it, so I feel positive about it.

      Like

  5. Hi Erick,

    Thanks for your effort to keep your components working, they become ubiquitous on my projects. Like other users I’m asking why NXP are tracking this path. It seems that Processor Expert will be no longer part of future KDS releases, Am I right? I am not an expert on KSDK so if possible I would like to hear what is your opinion about this strategy to take off PEx support (assuming they are going to take it off).

    Thanks again for your huge contribution to keep things smart and easy!
    Regards,

    Like

    • Today at the NXP FTF conference I attended FTF-DES-N1957 and FTF-DES-N1958 which included a demonstration of the new tools (next generation of Processor Expert). And this looks very promising. Slide material and recordings should be available after the conference. Basically there will be new tools (Pins, Clock and Peripherals or Components) which augment and extend the Kinetis SDK for what the Processor Expert was used in SDK V1.x and earlier. Unlike Processor Expert where it tries to do ‘everything’ and having control of everything, the new tools are designed to do their job (e.g. muxing pins or configuring the clocks) while connected with each other. So a much more scalable and efficient way of doing things. Additionally the tools are available both as web (browser) and as locally installed (desktop) tools, and you can easily switch between the two. As big plus things are now working with version control systems (something which is a pain in Processor Expert). Unlike Processor Expert these new tools are as standalone (outside Eclipse) applications, but eventually there could be Eclipse versions of it.
      As for KDS (and LPXCpresso): the say is that both are here and maintained and supported, but going forward there will be a new ‘best of two world’ version of that. So KDS still does and will include Processor Expert.
      My opinion about this is that it will take some time until this new concept with smaller but smart tools are fully rolled out (Pins and Clocks are supposed to come out in the very near future). I feel NXP learned from what was not so good in Processor Expert and carries forward in new tools the best of it. Clearly it means changing things, but the demo today with the new Pins and Clocks tool were really awesome. The Pins tool makes it easy with a Processor Expert kind of view to configure the pins and to generate the SDK v2.0 code for it. The clocks tool has a graphical view of the clock tree and clock distribution with all the prescalers and settings, and again it generates the source code to be included into KDS (or any other toolchain) project. So my feeling with the new tools is that yes, things will be different and not work the same way, but long term that approach might be better scalable and more efficient and easy to use, especially with the new multicore and more complex parts coming up.

      Like

      • Thanks Erich, that is good to hear (and very timely, given the discussion on this post !).

        Like

      • Just had a look at the presentations. Nice to see how the roadmap pans out over the next year, given I am 100% dependant upon PE, it looks like there should be something useable for me based around 2.0 in the second half of 2017.

        Would be good for NXP to post links to these up in the KSDK and SDK areas of the forum for all to see.

        Like

  6. Hi Erick.
    First of all thank you for sharing your effort. As I wrote in another post, I´m knew to this world. I´m coming from MSP430 with FreeRtos using IAR.

    After reading this post, I´m a little more bit lost than I was. My first goal is to mount FreeRTOS on FRDM-KL46Z and driving the ADC. All of this, knowing what I am doing. If you could help guiding me to choose the correct way. KSDK 1.3 VS KSDK 2.0 VS PROCESSOR EXPERT I will be very pleased.

    Regards

    Like

  7. Hi Erich and all,
    First of all, many thanks for nice words about Processor Expert. I never thought in 1994 that this idea will live for more than 18 years. Just some notes – first online version (cloud) was established in 2005 as part of Embedded Workbench, had more than 100 customer designs per month for simple 8bit Mcu programmed even in asm! Up to 2009 PE was kept as simple configuration tool, we developed integration with Simulink from Mathworks. Npi support – more than 80 mcus annually, integration of different families with specific requirements like dsc family in Freescale time was priority, leaving not so many space to develope middleware components, external devices components. Integration of internal tools including automotive ones went over initial simplicity of the tool. Just to react to Erich’s comment about PE aim to do everything. And you Erich know it pretty well!😄 Hopefully PEx best features DNA went to new KEx tool, all you will have possibility to judge yourself. Your feedback will definitely help to build next gen. Thank you so much ! Stanislav Cerny

    Like

    • Thanks to you Stanislav and your team for all the fantastic work that went into PE over these 18 years. I just hope that the new tools work as well as PE did for me.

      Like

  8. Hi Erich.

    Do you suggest install your P. E components into KDS 2.0 and use it?
    Or is a better idea using the new pin mux tool?

    I think we must use the new KSDK 2.0, because this have not relationship and compatibility with old KSDK versions, e.g 1.3.

    Thanks for your attention.

    Best regards from South America.

    Like

    • Hi Juan,
      I do not recommend KDS 2.0 (that’s a rather old version), I recommend and use KDS v3.2.0.
      I have used the approach outlined in this article in a few projects and that works fine so far. I wish I have more time to make some components for the low level drivers like UART, SPI, I2C and so on.
      But at the end this is kind of temporary and intermediate solution only. Not sure how long Processor Expert will stay.
      Best regards from the heart of Europe 🙂

      Like

      • Hi Erich.

        I must correct it, i did mean KSDK 2.0 not KDS 2.0.

        I´m a complety begginer with kinetis MCUs. I´m a FRDMK64F board and I want learn to program trying to understand the MCU how to works . I´ve read some pdfs about PE and at the first view I considered it a good tool. But with the SDK 2.0 the PE support go out from NXP. So I must make choice: Try to install your PE components into SDK 2.0, or definitivily use the SDK 2.0 API.
        Obviusly I don´t want use mbed….

        ¿Which are your suggestions?

        Come on Alpes 😉

        Like

      • Hi Juan,
        I recommend you start with the SDK v2.0 API. You don’t need Processor Expert to understand the CPU, but I agree with you, it is a cool and good add-on.
        Using just the SDK 2.0 is what I recommend for your to start with. Once you are familiar with it and want to explore new things, you could add the new Pins Tool which does the muxing for you (but you can do this by hand too if you read the reference manual).
        I hope this helps,
        Erich

        Like

  9. Hi Erich,
    Just started the software for a new project using the K22, and I figured I should move up to KDS 3.2 and KSDK 2.0. I did like using PE in KDS 3.0, and am already missing it.
    So I am very interested in your technique above.
    I need to use USB CDC virtual com port on my device, I have built and run the example included with the KSDK 2.0 on the freedom K22 board (waiting for my hardware to be built).
    The problem I have with the example code is that it just echos characters over the USB.
    What I want is to have the USB vcom port look like a standerd IO port to my embedded code,
    so that I can use printf and scanf on it (or at least putc and getc).
    The example code doesn’t port to that easily, however I see your CDC PEX components (which I assume are on sourceforge) and I would like to use them because I think you may have solved making the vcom use more normal IO functions.

    I’ve downloaded the stuff on sourceforge, I guess I need to install the stand alone PEX?
    I am a little confused how to get your xxBeans_29.05.2016.PEupd files I downloaded into my KDS and KSDK setup.

    It would be wonderful if you had a blog post describing how to do it all, and how to use your CDC component – I assume it is free to use. And your blog can start by saying to do everything in this blog first, and then do XXXX to get the USB CDC device working.

    Brynn

    Like

    • Hi Brynn,
      yes, I have received many requests in the last weeks and months. It is just that my time is limited and I have not completed that work (yet). I just have added some support to the FSL_USB_Stack for SDK V1.3 for another project. It is on GitHub, but not on SourceForge yet. And yes, it is all free to use. But I have not done the same yet for the SDK v2.0. Still there is one thing you would have to do: basically initialize the USB peripheral like what the USB_Init does. In SDK V1.3 this is much easier than in the SDK V2.0 I think.

      Like

  10. Trying to compile the PEX project with Just the FSL_USB_CDC_Device component gives some errors in CDC1.c, it is missing the includes “hidef.h”, “derivative.h”, and “types.h”

    Same thing if I include the FSL_USB_Stack component. Do I need the stack component also, if I am using the USB stack in KSDK 2.0 (which I hear is BSD code instead of someone elses – do you components work with the new stack?) ?

    Like

  11. Hello Erich,

    If I set the Kinetis SDK to “none” when creating a KL03 processor expert project with KDS 3.2, there is no processor expert option for chosen.
    Does that mean that I can’t use your method to creat a KL03 KSDK 2.0 project?

    Best Regards,
    Kent

    Like

    • Hi Kent,
      there is no ‘only Processor Expert’ support for the KL03. But you can create a SDK V1.3 project (say for the FRDM-KL03Z) because there is Processor Expert for/with the SDK V1.3. But the more generic approach would be that you simply create a normal Processor Expert project for a Cortex-M0+ (e.g. KL25Z). You anyway won’t be able to get the device specific components/settings/code with my approach discussed in this article. So you can use a ‘generic’ Processor Expert project instead (that’s actually what I’m doing if the device does not match).
      I hope this helps,
      Erich

      Like

  12. Hello Erich, today I updated my component repository from “Components 2016-02-07” to the latest “Components 2016-10-30” and there was a compile error that I tracked down to stdbool.h inclusion in the header file of a new generated component KSDK1, so I commented that inclusion and disabled code generation of that component to get it compiling successfully.

    I’m not using any SDK in this project, it’s a KE06 with MQX Lite and Processor Expert.

    This is the part of KSDK1.h that was modified:

    #ifndef __HIWARE__ /* Hiware compiler (S08, S12) only supports C89 */
    #include /* uint8_t, int16_t, … */
    //#include /* bool, true, false, … */
    #endif

    I don’t like this type of code-bodges, any clues on what I’m doing wrong in the first place?

    Thanks!

    Like

    • Hi Carlos,
      yes, I have faced similar issues. The problem comes from the fact that Processor Expert has its own typedefs/defines for bool, and the Kinetis SDK is using stdint and stdbool header files. Depending on the order of includes, one or the other wins and causes inconsistent types :-(. I’m in the process of fixing this, but this means many components which have been updated to work with the Kinetis SDK need to be updated too. I hope I can complete the update towards the next weekend and publish the new components (I hope). Until then, another workaorund would be to use ‘-include’ option (Project properties > C/C++ Build > Settings > Cross ARM C Compiler > Includes) to include the stdbool.h header file: that way alwayst he bool define from stdbool is used. The bool define in PE_Types.h only defines it if there is no bool defined already.
      I hope this helps,
      Erich

      Like

  13. Pingback: Tutorial: Using Eclipse with NXP MCUXpresso SDK v2 and Processor Expert | MCU on Eclipse

What do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s