Hey all:

Just got my mbed and I've started futzing around with it.  Great stuff!

But what happens if mbed.org disappears?  Is the online compiler and its attached libraries available anywhere for download?

Actually, there are plenty of choices that target LPC chips: Keil, RVDS, IAR, Rowley, gcc (CodeSourcery, code red, compile your own) and so on. The nice mbed libraries are not available for them but no one is stopping you from writing your own code.

Hi,

This is a good question, and one worthy of an *official* response.

It would be naive to provide a guarantee that mbed.org will never disappear. We are trying something new, things happen outside our control, and we can't predict everything about the future. There is always a risk.

So, if it did happen, our intention would certainly be to provide everyone with a way to download their code, and an offline alternative to the online compiler.

With that doom-and-gloom out the way, I'd like to highlight that we are very committed to this project - and by this I mean both the people working on it and the increasing number of companies helping to support it.

You may not know this, but we actually started the project in it's infancy late 2005, and were already running it as a service by 2006 for some very early alpha testers. Yet we only released it generally this October 2009; why did it take so long?

Firstly there is the obvious technical reasons - we had it working as a prototype in 2006, but that is only 10% of the way to a product. So there has been a lot of development going on, but this is only one aspect.

Secondly, we wanted to test it worked as a concept. So we grew our alpha test base initially with friends/colleagues, then a beta test base by openning it up to people who somehow found out or were introduced to it. All this helped us improve and learn how to run mbed, whilst properly testing if it actually worked and was a good idea.

Finally, and perhaps most importantly, we wanted to ensure it was commercially sustainable. We've seen many great things come up over the years that ultimately fail as they couldn't sustain themselves - either they never got popular and so died, or became popular but then couldn't afford to support themselves, and hence had to be shot! We set this up as a robust model that if successful, enables ongoing investment in itself.

For example, I've seen some moans by people who don't like mbed that $99 (or $60 atm!) is a lot for a board. Well, I'd say it is a bargain! Even if you only consider all the component parts on the board, manufacture, packaging, logistics, distributor margin etc, its a pretty good deal. But there is also a bit in there to go towards "mbed the service" - that is what the license key represents. For your $99, you're also getting access to the mbed compiler and the mbed world. Put it another way - in return for some of your hard earned cash, we provide tools and a supporting website for your programming pleasure.

We also managed to get it backed by some great companies. ARM is obviously one (that is where we work), NXP is another (the microcontroller the first mbed is based around), distributors like Digikey, Farnell, Future, Mouser (see http://mbed.org/order) who are doing more than just selling it. And we'll be announcing some more in time. All this support and alignment really helps make it sustainable.

So by the start of 2009, we were satisfied we had all these aspects covered. Yes it took a while and much blood, sweat, tears, but we weren't going to commit unless we were really confident.

In conclusion, there is always a risk with something new. It basically comes down to a risk-reward decision that we can't answer on your behalf. If you can't afford the risk, go with something else. If you think the upside outweighs the potential risk, come join in! Hopefully this explanation highlights we've done a lot to mitigate this risk, and will help you make an informed decision.

Simon

Simon:

Thanks for the reply.

The real exposure, of course, isn't the $99 spent on the board, but the thousands of dollars that can be spent developing a prototype, only to lose the ability to compile that code if mbed.org goes away.

Developers wouldn't need to make a tricky risk/reward calculation if the compiler and libraries were routinely published.

It wouldn't need to be open source, but making the compiler and libraries available would be very cheap insurance for your developers.

Then, if the worst case happens and mbed doesn't make it, developers wouldn't have to rely on a company that is rapidly winding down finding time and money to publish the toolchain.

Simon - can you say anything about the mbed libraries ? At the moment they seem to be closed-source, but is that the plan forever ?

I'm not remotely planning to build an alternate toolchain myself, but I can imagine that opening up the library code might assuage some of these worries, since there would then be a clear possible path to migrate away from the mbed tools without a big rewrite if a migration became neccessary.

Thanks,

Richard

Bumping this post up -- Simon or others from mbed.org, any comments on library release or other steps that would help protect developers if the worst case happened?

Hi Patrick,

Patrick Kane wrote:
any comments on library release

The library releases are all versioned and made available via SVN, so all library releases are published by default. This may therefore give some of the "insurance" you describe, but we don't want to promote it as such; if people are relying on that sort of "insurance", mbed probably isn't for them in the first place.

Simon

I'm new here but what is mbed for?  Just evaluation?  Prototype works - go away and buy tools and start writing libraries from scratch?

I understand the potential support burden of users modifying the library but this is trivial to deal with ie "Have you built against the latest library?"

I'm keen to use mbed for real work but closed source is a bit of a turn-off, an object only library seems like it will be a problem if I have to adopt another tool chain because mbed has closed, no opportunity to fix bugs in the library, understand how it works and what its limitations are.

mbed isn't for people who want open source?

mbed is just for hobbyists?

Apologies if I've misundertood.

Patrick Kane wrote:

Hey all:

Just got my mbed and I've started futzing around with it.  Great stuff!

But what happens if mbed.org disappears?  Is the online compiler and its attached libraries available anywhere for download?

Program, kompilled on Keil evaluation ( free ) is loaded and works in mbed modul.
There is a set of files (it is given here) which allows you to create and compile in Keil
programs written in the  mbed medium ( C++ ets...).
Not yet tested driver from mbed UART via USB , but it seems that it drive UART0 in LPC1768.

The other free compler option is the LPCXpresso IDE and Compiler.  You would need to make a .bin file.  For the LPC1768 you would be limited to 128K.

www.nxp.com/lpcxpresso

How about code interchangeability? Can I use bin files from mbed compiler to load it on LPCXpresso 1769 target and vice versa? The pin layout of mbed is a subset of LPCX1769 and what I see from the 'getting started' the Code-red Compiler is more complex to handle. My idea is to write code on mbed compiler and to debug it on LPCX1769 since mbed has no JTAG and the pins 1 to 5 seem to be used somehow on the board. Is it possible?

There's also this post in the forums... Offline GCC compiler works with mbed libraries!

Summary... you download the project, run a .cmd script, and you have a fully functioning offline compiler.

Now, should they release the mbed library source code, the community could begin to flesh it out with control of the various other things the controller can do that aren't in the libraries (yet). Which I'm sure they'd do, even if they hadn't announced it, if mbed.org faced doom.

Yes, you should be able to perform such conversions. objcopy should be your friend to get the files into the right format.

To convert a .bin to hex, you should be able to use a command line like:

arm-none-eabi-objcopy -I binary -O ihex test.bin test.hex

This one should convert in the the other direction

arm-none-eabi-objcopy -I ihex -O binary test.hex test.bin

I have seen some code compiled for the LPCXpresso 1769 not work on the mbed but that only happened when the init code pushed the clock rate up to 120 MHz which isn't supported on the slower 1768. Other than that, it seems to work quite well between the two.

Here is a link to uploading a bin file into the LPCxpresso

http://mbed.org/users/nxpfan/notebook/mbed-led-blink-code-on-lpcxpresso-lpc1768/

The mbed SDK is now Open Source!

• http://mbed.org/blog/entry/mbed-SDK-is-now-Open-Source
• https://github.com/mbedmicro/mbed

Cheers, Emilio