MQX lite USB KL27Z

[randylee]

So I want to use KDS (latest version) and Processor Expert.  Using SDK1.3 and want to use MQX lite.  I'd be fine with SDK2.0 but it doesn't support MQX (I could live with FreeRTOS) or (a killer deal) Processor Expert.

Doing this on a KL27 processor (proto using FRDM-KL27Z)

How do I get a USB CDC stack on this conglomeration?

Is there a magical incantation to get PE on SDK2?  Maybe I could just move to FreeRTOS but PE not being there is a deal breaker for me.

[randylee]

"The tools to generate pin configuration and clock configuration are ideally only used at the beginning of the definition of your project. Once you have all the pins and clocks properly defined and configured, you can focus on develop your code using the KSDK 2.0 peripheral drivers or middleware stacks (USB, Filesystem, etc)."

That never happens in real life.  I've had to change up peripherals and configurations of things late into the dev cycle because of finding limitations and problems that I've had to design around.  Assuming that you know exactly how the hardware is going to work prior to doing code is not what reality looks like.

To be fair, the software industry had the same unrealistic expectations 30 years ago. There were application generators that took specs and then generated stuff from it assuming that the creation is the problem, not the maintenance.  It's always the late stage and maintenance that kills you, not the creation.  The extreme example of this is 50 year old programming: flow charts.  It took about the first line of code to make those irrelevant to what was actually going on.

Don't get me wrong -- in the hardware realm, PE (and the tools to come) get you up the learning curve of the part a LOT faster so are invaluable to those of us who don't spend our time being an expert on this one part (I've got several manufacturers parts to know well enough to use!) and so are useful even in the start of the project.  That said, integrated ones are WAY more valuable than starter ones.

So, if there are NXP tools team members listening, let them with ears hear - make those tools part and parcel of the larger tool.  Cypress PSoC Creator is the Gold Standard for integrated tools (with the exception of not knowing about RTOSs).  There is no tool I've seen better than that one for management of parts. Emulate that.  Splitting up PE is a step backwards in my seasoned opinion.

[isaacavila]

Hello Randy,

Coming back to your original request, I had made an USB CDC Device that was created using PEx in KSDK 1.3 for FRDM-K64F (it was created for baremetal implementation but i could work with MQX standard, remember that MQX lite does not support dynamic allocation scheme and USB applications needs to allocate memory dynamically, so I would suggest to use PEx + standard MQX + KSDK 1.3). I would try to create this example and a document that explains the steps needed to get it working.

Will this serve to you? If so, I will thank your patience!

Regards,

Isaac

[randylee]

I greatly appreciate your willingness to put out the effort but what I think I'll do is to go off in a different direction than the MQX Lite way.  I've got a few months of basic testing I can be doing without running into too many limitations of the tools (using other platforms and paradigms) before I really need to be into this hard and heavy.

With some luck the tools will be there when I need them.

Again, I think you for your willingness to put out the effort but it isn't needed just now.

Best Regards,

rjl

[randylee]

Had a conversation with my local FAE yesterday on the subject here.  He presented a NXP timeline that suggests that PE is going to get sliced into 3 different functions all of which would generate code to put into projects (not a great solution but a person can live with it).  the first is supposed to be delivered this month (pin muxing, I think), the second next month (clock tree configuration).  Those two are the biggest deals.  The third (peripheral configuration) would be delivered in August. 

KDS he suggested will know directly about FreeRTOS in debugging very soon if it does not now (3.2).

So, by the end of summer, NXP will have KDS back into a solution (although not a particularly well integrated one IMHO) for the future parts.

MXQ (from his take on what NXP is telling him) will continue to be supported but for a price which means the average engineer should heed the label: "not recommend for future designs"

From a software engineering perspective, Processor Expert is a head and shoulders better solution than the outboard programs that do the same thing.  That outboard configuration causes trouble in the software life cycle as you effectively end up editing intermediate code which means that the "source" code no longer has a relationship to the object code once you're into the heat of implementation of a design. At least not without a lot of manual discipline which means that, in the day to day battle for code, you will have mismatch somewhere.

Short answer: My dilemma will sort itself out in a few months but with a poorer solution than it started with.

[santiago_gonzal]

Hello Randy,

Let me clarify a few points:

- MQX v5 will be a paid solution (you can find more info in: www.nxp.com/mqxv5) that will add MQX Support to future MCUs manufactured by NXP. As of today, almost every MCU is supported by MQX either in MQX 4.2 or in KSDK_MQX 1.3. So, if you want to develop a complex app today with full TCP/IP stack or a powerful file system, MQX is a great solution for free. But the choice is up to each user.

- SDK 2.0 will make more sense in fact if you plan to have control version or different software cycles. The tools to generate pin configuration and clock configuration are ideally only used at the beginning of the definition of your project. Once you have all the pins and clocks properly defined and configured, you can focus on develop your code using the KSDK 2.0 peripheral drivers or middleware stacks (USB, Filesystem, etc).

Since SDK 2.0 is full source code, with no parts generated depending on specific configurations, you have much more control of the code you're using.

Regards,

Santiago

[mjbcswitzerland]

Hi

In case you don't find a suitable solution you can also consider http://www.utasker.com/kinetis/FRDM-KL27Z.html

This has powerful integrated CDC (industrially proven in many products on many different Kinetis and Coldfire parts).

It is an out-of-the-box project solution (rather than examples) - allowing you to also mix CDC with Audio, RNDIS, HID, mouse, keyboard, MSD without any effort - and gives (virtually) all peripheral configrations without any need for PE. It allows the processor and board to be simulated to speed project development and test/debug code and peripheral controls (incl. interrupt and DMA operation).

A reference application at the link can be used to show 3 CDC to UART bridges operating in parallel, together with composite mouse.

You should also find it gives best memory (Flash/RAM) footprint to feature ratio, plus is processor independent (allowing a KL27 application to later be moved to any other Kinetis part with almost no effort) as well as IDE independent (builds with GCC, IAR, Keil, Atollic, Rowley Crossworks, Green Hills etc. as well as Visual Studio) and so doesn't restrict to any environment, or can be moved without effort.

Regards

Mark