Should I use MQX?

[sensorEric]

I am in the design stage of a project, and I am trying to make a decision about whether we want to go the MQX route or not.

The application domanin is pretty straightforward. It is a wireless sensor.  The hardware supports USB; however, initially the USB will only be used for debugging purposes . We went with USB, rather than a simpler rs232, in case USB functionality may be needed in future.

I can pretty easily whip up the firmware without MQX, but I am a little worried about the USB stack as I have never done this before. So here is my question:

Does it make sense (cent$) to use MQX just for the USB support?

Does it make sense (cent$) to use MQX if filesystem and USB both need to be supported?

[OldNick]

Not much to offer here, except to unravel some confusion between using Codewarrior, the RTOS, the drivers and the middleware (USB stacks, File system etc.)

Am using Kinetis, and considered CW, but went in favour of IAR because they were first out of the blocks, not Eclipse-based, and well recognised.

A cortex-only eWARm is not very expensive, and their support is really responsive.

One alternative might have been Keil uVision.  Not much to choose between them, I suspect. (At least on paper).

MQX only works on Freescale AFAIK, so although it is great for Kinetis, it locks you out of every other ARM processor. 

RTX, FreeRTOS, uC/OS etc. are all also competing in the small embedded RTOS world.  It is quite crowded out there.

Low-level bare metal drivers come with the example code for virtually any compiler.  Freescale also offer a Processor-Expert, but integrating it with MQX looks a bit complicated.  I have stayed away from that.

The expensive bit is the middleware (Filesystem and USB stack etc.)  MQX is the ony free one that I am aware of.  Every example that I have tried has so far worked first time which is a great confidence builder. (I'll take the other advice that they are buggy into consideration though.)

The downside to MQX is that getting support as a freescale (i.e. freeware) customer is like pulling teeth, and the documentation leaves you floundering in the dark.

If I had the money I would buy ThreadX or something - but us SME's don't have that sort of up-front cash lying around.

Lets hope someone takes the bull by the horns in this market space and enables a quicker and easier route to market for embedded designers soon.

[ARQuattr]

Good input OldNick, thanks.  What OS are you using on the Kinetis?

The expensive bit is the middleware (Filesystem and USB stack etc.)  MQX is the ony free one that I am aware of.  Every example that I have tried has so far worked first time which is a great confidence builder.

That's the main reason I think MQX would be a good choice for the OP.

The downside to MQX is that getting support as a freescale (i.e. freeware) customer is like pulling teeth, and the documentation leaves you floundering in the dark.

AGREED!  I'm glad I'm not the only one with that experience.

[OldNick]

Thanks for that. Currently on MQX3.7, purely because of the USB drivers and SDIO card File access.

Been writing bare-metal systems for years, and even did a USB CDC slave and Kbd /Printer Host on the last project.  But not enough man-months available to do it over again on a new project.

Quite unhappy with the way MQX low-level drivers seem to be "shoe-horned" into some pseudo posix format - but more so with the documentation (which looks like something doxygen could have generated from source-code comments).

I have had to come to the forum on a few occasions to figure out simple stuff like configuring a task to handle a UART,

add a mutex to the i2c API so that MQX doesn't trash the transactions, etc.

Stuff that could (should) have been part of an embedded RTOS for a microcontroller, or at least a real-life example or training material.

MarkP has been a great help.  But in the end, the only way to figure out what MQX is doing to your hardware is to track the device-driver pointers in a debug-session, find the appropriate bit of source code, and reverse engineer it.

Also - beware if you want to program any part of your application in C++ .  MQX does its own memory management, the templated linker files have no heap allocation, and C++ static constructors may link but crash on startup, or throw linker warnings and then appear to run (for a while).  To fix that, you have to patch the MQX startup files. 

Stdio between C and C++ is also a minefield.  I haven't yet found a fix for that.

In short, if I were doing this again, I would NOT use C++ and MQX.  Too hard. 

And like I said, If I had the money, I would have bought an RTOS with a broader processor base and better support.

[jimtrudeau]

Not to dissuade from MQX at all, but to provide "yet another choice," we do have a bare metal USB stack that supports MCF51MM. Click HERE to go to the FSL web page for the USB stack software. Clearly doesn't give you the advantages of an OS, but it is an alternative design choice. It's free.

Hope this helps.

[ARQuattr]

SensorEric,

    There's not a lot of detail about your target processor or application, but I don't see why MQX wouldn't be suitable for a 'straightforward wireless sensor'.   BryGuyH, it's been around for about 20 years and in use by some major companies so I'm not sure why you feel it's not accepted and trusted.

    I've been using it for about a year and I found it relatively easy to adopt, especially for a sophisticated RTOS that it is.  I expected much more trouble when using TCP or USB stacks for the first time, but I found everything integrated and worked quite well.  Of course there is some learning curve, but if you are using a chip for which demo boards and bsp/psps are already available, you should find it quick to get up to speed.  (It took more time for me to assimilate Eclipse than MQX.)

    I tried various USB stacks including the CMX and 'medical' stack offered by Freescale, and while they work, I opted for the one included with MQX mainly because it's already integrated.  The main reason I was considering alternative stacks was to reduce code space, and if you are using a resource-limited chip, that might be a good reason to avoid MQX altogether.  But if you are in the design phase I imagine you can still make a chip selection.  If you are going with MQX, I would suggest something with 256kB Flash minimum.  (Don't be fooled by the claims that you can run a USB stack on the 51JM128, and have enough space left for any meaningful application code.  I learned that the hard way.)  

    I have so far only used the MQX USB in host mode for external thumb drives with filesystem support, and like most of my experience with MQX, it 'just worked'.  Of course I always add a UART port for debugging, and the MQX shell is also great for providing a nice console that can easily be attached to any UART port.

    I've worked with USB on other hardware platforms and I would definitely recommend using an established stack over 'rolling your own'.  

    So to sum up, I would answer 'definitely' to both your questions.

    Hope that helps,

Angelo

[sensorEric]

Thanks a lot  for yuor response. This is not your "typical" design stage as the hardware has been designed,and the software engineer (me) has to work with the given hardware. Fortunately, our EEs are pretty good and they chose a hefty micro (MCF551MM256 ) so there should not be any issues with flash being to small.

[ARQuattr]

There's a tower kit for that processor along with MQX bsp and psp support, so that would be a good place to start if you go with MQX.

[sensorEric]

Are there any free dreescale development environment tools that will build MQX source? Historically, our project managers have been reluctant to purchase licenses so we have either used open source IDEs or free versions. This is my first freescale experience and CodeWarrior seems to be the preferred IDE. Unfortunately, it appears as if CodeWarrior's free version is size restricted and that MQX code will easily exceed the 128Kb limit imposed by the free version. 

Anyone have any suggestions as to IDE's other than CodeWarrior that are free or USB stacks  (also free of course)?

[ARQuattr]

ay, there's the rub...

I understand people have been successful using open source tools like Eclipse and gcc, and there's a topic on this:

https://community.freescale.com/thread/23739

CodeWarrior 10 is Eclipse-based anyway, so I don't see why this wouldn't work.  If you do get that working, please let us know.

There are also some open source RTOS available that you might be able to use, but I would guess it wouldn't go as smoothly as MQX which has driver support for that specific processor.

[BryGuyH]

I would look at FreeRTOS (http://www.freertos.org) then if you can't get them to buy a CW license (they're pretty reasonable now... they are nowhere near as bad as they used to be), not to mention its hard to beat processor expert for getting new chips and architectures running.

There is always eCos available as well... but I don't know how alive that project is anymore.

In general just argue the fact that they can either spend the $ to buy a license to CW or realize that they would probably spend more for you do use anything else (honestly even the $5k for the biggest badest package for CW is less than what it would probably take from a pure hours standpoint for you to use a free open source package).

[sensorEric]

I will have to look into and see how much the CodeWarrior license is. If it is under a 1K it might be a possibility.

. A lot of the problem has to do with the way our projects are billed and accounting. I think that if software is purchased with project money then the software can only be used on the project that originally bought it or else we could slapped if we were ever audited. 

[BryGuyH]

I hear ya (I'm actually stuck with Keil uVision for development because my company is almost strickly ARM for everything - only one of with is Freescale).

You could probably get away with the $995 perm Basic (have to stay under 512KB for the V2 coldfires) or the $995 Subscription Standard (if you go over 512kB)

http://www.freescale.com/webapp/sps/site/overview.jsp?nodeId=01521027263BC5

[BryGuyH]

The core of MQX is solid (as one would expect for its history) and I have no beefs with it, and in comparison to uCos I am quite pleased with how easy it is work with and its performance. However today (as yourself and the OP obviously are dealing with) embedded development is all about peripherals. That is the current weak spot for MQX, some are good, but some aren't. Even the RTCS and USB forums have numerous examples where the official releases are good, but not quite 100% so one must patch and do compliance testing on their own.

Because it is free and not bound by GPL one should realize you are getting what you paid for. If you have the money then it makes sense to go with something guaranteed to be fully vetted. Freescale does provide operating systems that are fully integrated and vetted, they just aren't free.

In less that 2 months with MQX and the Kinetis our team has identified almost a dozen (confirmed by Freescale) critical bugs in the driver code (things from memory leaks in the adc driver, to writing to a null pointer in the flexcan driver).

[ARQuattr]

Very good points, thank you.  I agree the the OS core is it's strength, and that some peripheral driver support has had issues recently.  I have been considering Kinetis for a couple of new projects and am somewhat undecided because of the delays and issues with the release of MQX 3.7.  I have run into some issues as you describe, even with previous versions, but it seems that RTCS and USB on the older silicon are rather stable.

I would also agree paying for an OS would probably be preferable, even for the support alone, but I think MQX is a pretty good product for no cost.  I'm not familar with pricing models for the other OS options so I can't comment on their value.  If paying for an OS is in the budget it would probably be better than RTOS, but I think the OP was mainly debating between MQX and depeloping from scratch, which makes me think paid software wasn't really under consideration.  If I needed to choose between using MQX and writing it from scratch I would take MQX any day.  I think the choice also depends on the hardware selection, as you indicated.

You wrote "in comparison to uCos I am quite pleased".  I haven't used it.  Are you suggesting it has issues, or is overly complicated?

[BryGuyH]

Do you have budget for an OS? If yes then go with something already accepted and trusted - Freescale also sells OsekTurbo and Autosar solutions for automotive products.  Otherwise other options are Wind River or Green Hills.

If you have no budget (and can't use anything GPL) then MQX is acceptable, and with something that simple may work fine. Be prepared to have to rewrite a lot of board level drivers though.

Because you mentioned Wireless and USB you should probably read some of the literature on the MQX USB and RTCS forums before deciding.