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 ?

   LikeLike

   Reply ↓

   • 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.

     LikeLike

     Reply ↓

   • 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.

     LikeLike

     Reply ↓

     • 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.

       LikeLike

       Reply ↓

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

   LikeLike

   Reply ↓

   • 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’.

     LikeLike

     Reply ↓

     • 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.

       LikeLike

       Reply ↓

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

   LikeLike

   Reply ↓

   • 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

     LikeLike

     Reply ↓

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?

   LikeLike

   Reply ↓

   • 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.

     LikeLike

     Reply ↓

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,

   LikeLike

   Reply ↓

   • 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.

     LikeLike

     Reply ↓

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

       LikeLike

       Reply ↓

     • 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.

       LikeLike

       Reply ↓

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

   LikeLike

   Reply ↓

   • Hi Fernando,
     there is no SDK v2.0 for KL46Z yet, otherwise I would guide you into that direction. I wrote a tutorial how to use FreeRTOS with the SDK v1.3 here:

     Tutorial: FreeRTOS Projects with Kinetis SDK V1.3 and the SDK Project Generator

     
     As for pros and cons, have a read here: https://mcuoneclipse.com/2015/10/18/overview-processor-expert/
     I hope this helps,
     Erich

     LikeLike

     Reply ↓

     • Thank you. I will read both Tutorials

       LikeLike

       Reply ↓

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

   LikeLike

   Reply ↓

   • 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.

     LikeLike

     Reply ↓

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.

   LikeLike

   Reply ↓

   • 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 🙂

     LikeLike

     Reply ↓

     • 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 😉

       LikeLike

       Reply ↓

       • 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

         LikeLike

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

   LikeLike

   Reply ↓

   • 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.

     LikeLike

     Reply ↓

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?) ?

    LikeLike

    Reply ↓

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

    LikeLike

    Reply ↓

    • 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

      LikeLike

      Reply ↓

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!

    LikeLike

    Reply ↓

    • 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

      LikeLike

      Reply ↓

    • Hi Carlos,
      yesterday night I have released a new set of components which remove the need for the KinetisSDK which caused that problem (see https://mcuoneclipse.com/2016/12/12/mcuoneclipse-components-12-dec-2016-release/). Instead referencing the Kinetis SDK component, now you can reference the McuLibConfig component which solved that problem with the includes on my side. Can you try this out?

      LikeLike

      Reply ↓

      • Yes it works wih the new McuLibConfig component instead of the KSDK one! Thanks!

        LikeLike

        Reply ↓

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.