Is NXP abandoning MQX?

[GudeADS]

Hello,

I found "Document Number: KSDK200MKS22FN256RN" with title "Kinetis SDK v.2.0.0 Release Notes Supporting

the MKS22FN12 Devices" in the KSDK document area.

I am citing: "KSDK 2.0 is the evolution of KSDK 1.x into a more optimized software solution. KSDK 2.0 eliminates

the need for separate HAL and Peripheral drivers, replacing these two layers with a single driver for each peripheral. ...."

"... At the middleware level, RTCS and MFS have been removed, and the USB stack has been replaced with a BSD licensed

solution. KSDK 2.0 has also aligned with ARM® through the integration of mbed TLS with our accelerated cryptography

drivers. This integration ensures the highest level of performance from our on-chip security peripherals. Existing MQX RTOS

support has been deprecated to focus on support of FreeRTOS and uCOs II/III."

Is this the future of KSDK and MQX support?

Best Regards

[j___]

It's a little late to reply to a thread from February, but I just stumbled onto it.

I think that the main reason MQX will not be provided with KDS is that NXP is no longer providing MQX for free. So, they have positioned it as the premier product.

KDS will get the freebies that are openly available on the net or very low cost to them.

[mnorman · Accepted solution]

The MQX kernel, stacks and middleware have been removed from the Kinetis SDK.  However, MQX Software is still a supported software suite from NXP that is available in the MQX RTOS and MQX for KSDK v1.3 products. New ports of MQX following the “Classic” architecture (i.e. similar style to MQX v4.x) will soon be available for newer Kinetis devices.  From here forward, the Kinetis SDK will focus on open-source RTOS solutions.

Regards,

Michael

[fcw]

I don't think Freescale realized how compelling the MQX solution was to smaller organizations with limited budgets and limited staffing: One download for an integrated OS, network stack, network applications, file system, USB, .... The Kinetis uCs are great parts, but our 2012 decision to select Kinetis was maybe 25% hardware, 75% MQX software. Cobbling together a software infrastructure from several known/questionable/unknown sources, verifying no GPL entanglements, integrating/testing the pieces, and dealing with a lack of useful documentation doesn't help get a product to market.

Maybe your article indicates NXP management does see the compelling case, especially if "similar style to MQX v4.x" means same as MQX 4.x and includes stacks and middleware.

If we were starting a clean-sheet development and KSDK was the only supported software option available, Kinetis wouldn't have that 75% edge.

[mnorman]

Hi, Fred,

Please see my response to Robert above regarding the future for MQX - there is one!

Regarding quality of software, I can assure you that delivering high-quality, production ready code is our goal for KSDK and all other enablement software.  KSDK v2 is MISRA:C-2004 compliant and checked using Coverity static code analysis tools.  Our teams are following rigorous professional software engineering processes with a strict coding style guide. The KSDK is tested on all the supported hardware with all the supported toolchains by a separate test and validation team  We also insure that our software is free from any GPL contamination using Black Duck software products.

These are just words in a forum post, so I'd encourage you to download KSDK v2 for your favorite supported platform and have a look at the code. We have a focus on quality that I hope you can see in the product itself.

-Michael

[shanescott]

Just curious why MISRA 2004?  Why not 2012?

[mnorman]

Shane,

C:2004 only due to current tool limitation.  We are planning to update tools to get C:2012 coverage later this year.

-Michael

[randylee]

Ah, so this thought led me to re-read the license for FreeRTOS and according to that license, FreeRTOS isn't exactly GPL or even LGPL.  According to the site (http://www.freertos.org/a00114.html ) You do NOT have to publish your code, only the code for FreeRTOS if you modify it (at least starting in V8.2.3).

Which means that us commercial users can actually use this in products reasonably.

According to the license (http://www.freertos.org/license.txt): "NOTE: The modification to the GPL is included to allow you to distribute a combined work that includes FreeRTOS without being obliged to provide the source code for proprietary components."

So this makes this a viable option at least.  Maybe not so much for people who have put a lot of history into MQX..

[robertboys]

Hello

ARM has another RTOS:  RTX. RTX has a 3 clause BSD license which makes it free.

Its official name is CMSIS-RTOS RTX.

All source code and documentation is provided free:  Main Page

RTX is full-featured RTOS and not a toy. It is really easy to use on any Cortex-M processor.  Getting Started Guide:  www.keil.com/gsg

There are ports for a few Cortex-A processors too...more coming...

Like the free ARM DSP libraries, ARM maintains RTX.

There are ports for Keil MDK, DS-5, GCC and IAR.  You can use any IDE, not just Keil.  Cosmic uses RTX in its tools.

See www.keil.com/rtx and www.keil.com/NXP for more information.

Keil provides the SDK 1.0/1.1 in the Freescale Software Pack (name will soon be change to NXP) and we are looking at creating one for SDK 2.0. 

This also looks interesting:  http://kex.nxp.com

Thanks

Bob Boys

bob.boys@arm.com

[robriggs]

Hi MIchael,

I am really encouraged to hear about this change in direction for the Kinetis suite of tools.  I abandoned Freescale MCUs for STM when it became apparent that there was no possibility of releasing the code for our product under an open source license.  It was incredibly disappointing, given that ARM had released CMSIS under a very liberal license, that this was not an option for Kinetis.  We believe it incredibly important that all of our software be open.  Having the ability to publish and distribute source code for code targeted at Kinetis CPUs will have me taking a second look.

And after working with FreeRTOS, I have to say that you have made an excellent technical choice.

Keep up the great work!

-Rob

[rajbatra]

I'll have to agree with Fred. We selected Kinetis because of MQX (free powerful RTOS w/ USB, TCP/IP, etc.). I spent last 6 months coming up to speed on KSDK with MQX only to see that I have to plan for switching tracks again even before we've shipped our new product. MQX has been out for a long time and is stable; not sure why you wouldn't support something of your own.

The other changes that I'm reading for v2.0 in terms of simplification are appreciated. The number of includes, cherry picking between HAL and peripheral APIs and setting up a project were cumbersome in v1.x line.

-Raj

[robertyork]

Michael,

Unfortunately, your statement only added to the confusion and begs more questions than it answers.

The question was about future support of MQX. You state that MQX is available with KSDK 1.3, however, that is not a current release of KSDK, so that's does not answer the question about future support at all. It even implies that it is not supported on KSDK 2.0. Then you state that new versions of MQX will be supported on new devices, but then go back to say that new versions of KSDK will support open-source RTOSes, again implying that MQX is no longer supported.

Please be direct in answering these questions:

1. Will MQX be supported in KSDK 2.0 and future releases?
2. What RTOS options will a customer have for KSDK 2.0 and future releases?
3. What support will be offered for HTTP, USB, MFS, etc.  in KSDK 2.0 and further?
4. If a customer wishes to use MQX with future NXP parts, what are the supported options?

I work on projects with NXP parts that span several years of development. I can't afford to start a project with the latest tools and supported RTOS, only to have NXP change course in the middle of my project. I am told its still supported, but in reality, issues I come up with are then ignored and pushed off to the side, since it's no longer the 'focus'. This has already affected my projects with Kinetis twice in the past 12 months. This would be a third time.

[mnorman]

Hi, Robert,

Sorry if my post was unclear.  I'll reply to your enumerated questions here:

Q1. Will MQX be supported in KSDK 2.0 and future releases?

A1.  No, MQX will not be support in KSDK v2 or future KSDK releases.

Q2. What RTOS options will a customer have for KSDK 2.0 and future releases?

A2. KSDK v2 today offers pre-integration and examples for FreeRTOS--a high-quality, MISRA-compliant code base that follow strct style guides, leads the industry in adoption and offers safety certified upgrade options.  KSDK v2 also pre-integrated uC/OS-II an III (evaluation version) to show examples for how those or other commercial operating systems can leverage the core of the KSDK. Other RTOS options may be available pre-integrated into the KSDK in the future, but there are no specific plans right now.  We are also working closely with ARM to update and proliferate the mbed Classic and mbedOS Kinetis support to leverage the drivers and services in KSDK v2.

Q3. What support will be offered for HTTP, USB, MFS, etc.  in KSDK 2.0 and further?

A3. USB - KSDK v2 offers a device/host stack today with comprehensive class support.  This is a production quality stack, tested with static analysis tools and USB-IF compliant. File System - FatFS is the only solution planned for KSDK v2 at this time. HTTP - lwIP is the only option today. We have created new demos and examples that show how to do HTTP (e.g. see lwip_httpsrv on FRDM-K64F). We are actively working on our next gen networking stack that will offer IPv4/v6 capabilities and integrate with our broader connectivity stacks. This will appear in future KSDK v2.x releases.

Q4. If a customer wishes to use MQX with future NXP parts, what are the supported options?

A4. Details are being finalized for a continuation of the MQX classic product that will support future NXP Kinetis devices (and other product lines).  This will be compatible with the MQX v4.2 software suite including RTCS, MFS, etc. We'll communicate details as soon as they are finalized.

-Michael

[jhmrd]

I have been using CodeWarrior and MQX for 5 years now. We have done quite a few products using Kinetis parts and like others have said, 75% of the reason we used Kinetis was the OS and the tools. The deeper I have gotten into making MQX work for our products, the less helpful I have found the Freescale support to be. The fact that I have to pay $2000 a year for CW with the lousy support from Mexico has been an annual annoyance. Now it seems NXP has done away with even the Mexican support and expects us to post our support questions to the community. They still gladly accept $2000 a year to prevent CW from telling me my code is too big for the license I have if I don't pay up.

I find this latest shakeup in the Kinetis product very discouraging and hate to imagine how much work it will be, and how much previous work will be obsolete. The promise of "We'll communicate details as soon as they are finalized" leaves me cold.

[fcw]

Off the topic of MQX support, but re. Code Warrior: I avoid buying into any Eclipse-based product, but nonetheless evaluated both Code Warrior and IAR Workbench before selecting Workbench. One Workbench dongle-locked license for all Cortex products, unlimited code size was something over $3000. Annual support is 15% of purchase price. Well-supported with example projects in MQX 3.7 through 4.2. Both East- and West-coast email support and they follow through until an issue is resolved via email, or phone on the difficult ones.

In support of the NXP-ex-Freescale staff that contribute to the forum, I recognize some of the names from the time email support was provided. These folks also followed through on support requests. Again, I think, another example of the upchain management and executives not understanding what was important to their customers.

[robertyork]

Michael,

Thank you for clarifying this situation. It's still another tool-chain headache I have to deal with around Kinetis parts, but hopefully some answers will come out soon regarding NXP's support of MQX for Kinetis. I understand NXP is trying to migrate to better solutions, but over the past year I've had to wrestle with getting a common tool-set for MQX on K22 and K70, and get a graphics library for the K70. In both cases we were sold a solution that is no longer going to be the path forward. We keep getting told they will continue to be supported, but in my experience, support for deprecated tools never works out well.

As Fred pointed out, the reason we chose Kinetis was because of the tools and support. There's half a dozen ARM M* core MCU vendors to choose from, and in the past, Freescale made it so easy to use their parts with good tools, support, and documentation. I hope this continues after the merger with NXP.

[mnorman]

Thanks for the comments Robert. We in the MCU group share your desire for a stable, high-quality platform for Kinetis.

[BTaylor]

Mr. Norman,

You state the following:

"New ports of MQX following the 'Classic' architecture (i.e. similar style to MQX v4.x) will soon be available for newer Kinetis devices."

However, the 'MQX Roadmap' page (MQX Roadmap ) [dated October 2015] states:

"MQX RTOS v4.2 is the last major release planned in the classic MQX product line. Technical support, maintenance releases, and professional services will continue to be available, but no new MCU device support will be added."

These appear to be conflicting statements. As a customer with a significant investment in MQX on Kinetis, I would greatly appreciate you providing some clarity on what appears to be a contradiction.

Thank you.

[GudeADS]

Hello Norman,

my comment from 01/28/16  and the short reply from Aurelien was deleted from this thread without a trace. I understand when you say that it might be wrong what I say, but censoring without comment is not nice! But this is your forum, you can here do what you want.

[williamely]

Thanks for the update Michael. Can you tell me how we will get updates for MQX 4.2 and beyond? Will NXP provide the files?

[mnorman]

Yes, these will be available from NXP.  We are currently planning a maintenance release for MQX v4.2 to fix the critical and major issues.  It's looking my early May for availability, but still some planing to be completed.

-Michael