Hi All,

I often get emails from people who don't have an mbed (and so can not post in the forum) asking if I would recommend mbed.

It is hard for me to give an unbiased opinion on this, of course I think it's great :-)

So, I have posted this "would you recommend mbed?" thread to the forum, everyone can have their say about what you like, don't like, what works well, what the short comings are, what features you'd like to see, and so on.

This would be great feedback for us, and a good thread to point would-be mbed users to for a more balanced view.

So, post away and let your opinion be heard!

Cheers, Chris

Hi

My 2 cents!

Lets start with: I think mbed great hardware (analog could be better)!

Only other competitors imo are Arduino and Netduino.

What I like about embed is that it runs a 'normal' programming language (C++).

The same holds for Netduino (and other .net board) that runs the Micro Dotnet Framework and C#. But boards are more expensive and more powerfull most of the time. C# is much easier to program than correct C++ (most of the time it's a mix anyway).

The programming language what I dislike about Arduino (although they seem to have started this affordable type of board trend).

Pro's of mbed are that you get the excellent (online) compiler free and the ease of downloading programs. Drawbacks are the online compiller and the weak/no debug options (dropped at the cost of the easy flashing). The lack of serious debugging costs man hours that are more expensive than slightly more expensive hardware. Only at very large projects board price will matter.

wvd_vegt

The mbed makes a great first impression. I got the mbed in the mail, opened it up, and in a few more minutes, I had my account created on this website, downloaded the HelloWorld binary, and even created a new customized HelloWorld project in the IDE. I have played with other microcontrollers in the past and I have never encountered another that was so easy to get up and running.

Things I really like about the mbed:

1. The web based IDE is one of the best non-professional programming interfaces that I have used. I have used the IDEs from Parallax for some of their chips in the past and I have hated them. The mbed IDE works the way I expect an IDE to work. It doesn't have all of the features of more professional IDEs but it has the core ones that are important for me.
2. For the price of an mbed device, you get access to the RealView compiler tool chain via the cloud interface.
3. The LPC1768 in my mbed device is a pretty powerful little 32-bit ARM processor and gives me a lot more flexibility in the type of projects that I can attempt to prototype with it. Many of the competitors are 8-bit with much less than 32k of RAM and don't even approach the 512K of FLASH for code or 96MHz clock rate.
4. The main mbed library provides a lot of functionality in an easy to use package. From my use of this library so far, I have found it to be well architected for the purpose of getting prototypes up and running quickly and the code behind the scenes appears to be well written.
5. The mbed uses the C/C++ programming language which has already proven itself in the embedded development world. I don't need to lean a new programming language or learn what subset of the standard libraries are available to me on this platform.

Things I don't like about the mbed:

1. I like the main mbed library but I find the rest of the libraries to be a bit of a minefield. I perform a search for a library to help me interface with a particular piece of hardware from the IDE and I get a bunch of hits. I have no idea which one I should go with and when I do pick one for something like TCP/IP, I am not that impressed with the quality. There are way too many forks/versions of the libraries that it makes it hard for a beginner to know which they should use. Having a shared source control system that allows multiple people to make improvements to a library without the need to fork will help out a lot here I think. A nice feature of the core mbed design is that experts have made choices for you based on their experience so that you don't need to. This breaks down with the community provided libraries.
2. I would really like to have a debugger. That said, most beginners find it difficult to use a debugger and it would be even harder if the code they were debugging was the highly optimized code that the mbed tool chain currently generates. Having a good debugging experience would require an option to turn down this optimization for easier source level debugging.
3. While overall I like the IDE, I find it pretty hard to use from a Mac. The keystrokes used in the editor map closer to what I would use with a tool like Visual Studio on Windows and these don't match the keystrokes used in editors on the Mac. I usually just give up trying to use the editor from my Mac and edit the text on a local editor and then copy and paste it up to the IDE.

In a time where the competition (Arduino specifically) is embracing open source software and hardware, the mbed tends a little more towards the closed side which makes it a hard sell to some people. Its not as big of an issue for me. I know that I could use GCC to compile programs for the raw LPC1768 chip and still use the interface chip on the mbed to quickly and effortlessly upload the resulting binaries. I would be stuck with a bad debugging story though since the JTAG pins aren't even accessible to me.

Well well well....:)

hmmmmmmmmm...........

The goooddd.......

I can play guitar in reverse:) hahahaah or talk like I am backward:)

The bad

You need to make sure you add a switch to turn the blue LED or LED's off if not I am gonna come down to your office and play with your nipples.

And also a debugger.

The Good:

-Easy to use board

-Easy to use compiler and library

-Easy to download code to board! (I love not having drivers and ports to worry about!)

-Cross platform

-Powerful uC (32 bit is nothing to shake a stick at!)

-Online compiler!

The Bad

-Somewhat pricy..

-Limited network support

-No Offline support

-Support from the mbed guys has slowly wavered!

-not as much code out there

I'd say the most limiting aspect of the mbed is the price point. Most seasoned guys would be willing to shell out the money for an mbed because they know what the lpc1768 is capable of. However, I can't see someone who is just starting out to choose the mbed over arduino (and the likes) because this individual would not know the crucial differences between the two platforms. They can (more or less) perform the same things a beginner would likely do. So I think it's a hard sell for the new players.

That being said, the price is what it is for a good reason. There is a lot packed into that little guy and it's well worth the money! If you need a dependable general micro controller for prototyping, seriously consider the mbed.

I have been using the mbed for over a year now and this has given me an opportunity to explore it even more and gain a better appreciation for why I have kept on using it for that time and things that I would like to see improved to make it easier to continue using it in the future.

Things I really like about the mbed:

• The main thing I like about the device is the form factor. Being able to plug it into a breadboard and start prototyping has made it really easy to try using the device in different projects.
• The functionality offered by the built-in USB connector and interface chip on the mbed make it great for quick prototypes:
  • Can just power a lot of simple projects from the included USB cable itself. No other power supply is required for many of my prototyping needs. The built-in voltage regulator on the mbed also makes it easy for me to power it from an external power supply if so needed.
  • Programming the device is so easy. Just compile your code (online or offline) and copy it to the mass storage device which mounts effortlessly on my Windows and OS X machines. No special programming hardware is required.
  • The virtual serial port comes in very handy. For other devices, I have had to wire in something like a FTDI device to get data to/from my PC.
• I still like the basic look and feel of the web based IDE. There is room for improvement but I will mention those later.
• The mbed device is a cost effective way to get access to the RealView compiler tool chain via the cloud interface. I continue to be impressed with the code size and quality produced by this compiler. I wouldn't have been able to justify the price of this tool chain for my hobby needs.
• The LPC1768 based mbed device is a pretty powerful little 32-bit ARM processor and gives me a lot more flexibility in the type of projects that I can attempt to prototype with it. Many of the competitors are 8-bit with much less than 64k of RAM and don't even approach the 512K of FLASH for code or 96MHz clock rate.
• The main mbed library provides a lot of functionality in an easy to use package. From my use of this library so far, I have found it to be well architected for the purpose of getting prototypes up and running quickly and most of the code behind the scenes appears to be well written.
• The mbed uses the C/C++ programming language which has already proven itself in the embedded development world. I don't need to lean a new programming language or learn what subset of the standard libraries are available to me on this platform.

There were a few things that I didn't like about the mbed when I first started using it but I have since found solutions to them:

• No affordable offline compiler solution. I was able to create the gcc4mbed project to do this initially and now the mbed team has provided us the ability to export our projects to work with various GCC based tool chains.
• No debugger. I have started my own debug monitor solution to solve this issue. By sacrificing a bit of memory, I am able to get 98% of the debugging functionality that I wanted.

Things I don't like about the mbed:

• Lack of a reliable network stack. This is unfortunate since the ethernet hardware on the mbed-M3 is very impressive.
• While overall I like the IDE, I find it hard to use from a Mac. The keystrokes used in the editor map closer to what I would use with an editor on Windows and these don't match the keystrokes used on the Mac. I usually just give up trying to use the editor from my Mac and edit the text on a local editor and then copy and paste it up to the IDE. A couple of things here would help:
  • Document the control keys that are supported by the editor.
  • Make support for the existing editor/compiler a higher priority. There seems to be more concentration on adding new features to the compiler and editor and not as much priority given to watching the mbed forums for issues that people are hitting with the existing online experience and actively trying to correct them.
• I like the main mbed library but I find the rest of the libraries to be a bit of a minefield. I perform a search for a library to help me interface with a particular piece of hardware from the IDE and I get a bunch of hits. I have no idea which one I should go with and when I do pick one for something like TCP/IP, I am not that impressed with the quality. There are way too many forks/versions of the libraries that it makes it hard for a beginner to know which they should use. Having a shared source control system that allows multiple people to make improvements to a library without the need to fork will help out a lot here I think. The current model promotes forking and also results in too many orphaned works up on the site.
• If a person is just starting out in the hobby of embedded electronics, I would strongly encourage them to purchase the LPC1768 based mbed M3 device and not the LPC11U24 based mbed M0 board. The Cortex-M0 parts might be competition for the 8/16-bit parts but examples like the LPC11U24 also have some of the same limitations like being starved for memory. The lack of more than 1 serial port, ethernet, and USB host support on the mbed M0 make it less than ideal for prototyping most projects that I would consider. With initial prototyping, it is nicer to have as few hardware limitations as possible and just concentrate on getting your code and supporting electronics pulled together. However, if you just can't produce your prototype without the low power consumption abilities of the Coretex-M0 based LPC11U24 device and you know you can live within its hardware limitations, then the mbed M0 based device should be your first choice as a development board.
• Another issues related to the mbed M0 device stems from that fact that so many of the libraries on the mbed site were written to work with the M3 part and the differences in the M0 part are big enough that a lot of novice users get a bad introduction to the mbed device when they try to use such a library on their first M0 device. Having a way for the community to rate libraries and how they work on the different variants might help here. If you are developing for the M0 part then by default it should only list libraries that someone has flagged as working on that part.

Requires people to colaberate on driver binding, most preferably HID and Serial Port USBMouseKeyboardSerial all bound together in one package instead of being singular like so:

USBMouseKeyboard

USBMouse

USBKeyboard

USBSerial

We NEEEEEEED USBMouseKeyboardSerial.h!!!!!! asaaappppppppp!!!!!

Once this is done, I'll be freaking roaring for mbed to stay at the top of the league! I'd even promote it in the products that i make and will sell!