G Bulmer wrote:
Which parts will be released under Open Source-style licenses (e.g. GPL, Creative Commons, etc.)?

Hi,

For any open source stuff, we're using (and recomending others use) the MIT license (http://mbed.org/license/mit). The main reason is it is fairly simple, allows easy commercial and non-commercial use, and is generally in the spirit lots of code is intended.

All our cookbook code (i.e. external peripheral libraries/examples) is going under this where possible, and we'd recommend it for others too (although anyone is free to choose).

The core libraries are also free for commercial and non-commercial use, but are just supplied as compiled libraries; i.e. we wont be releasing the source yet - the main reason is we want to maintain responsibility for fixing and supporting them without fragmentation (fork is cheap!), and they aren't quite right yet in terms of architecture.This will ensure the architecture ends up in the right place for the majority.

The schematic should be available soon, but we won't release the gerber for the core module (similar support/control reasons). Some of the baseboards we've done are there, and we will make sure it is clear they use the MIT license (or similar if there is something more appropriate for PCBs?)

So a careful balance of open source and openness, based on what we think will help the project be successful, sustainable and supportable.

btw, Thanks for all the great support we've been getting on this announcement! It makes all the long hours worthwhile!
Simon

Hi,

Could you clarify your intentions for the core library source?

I have no issue with you good folks wanting to control development of the API, but I was really hoping to be able to learn more about programming for the Cortex-M3s and the LPC1768 in particular(I'm a student).  I don't know how to do that very effectively when the device implementations are hidden by the API.  I'd have to look elsewhere for the information.

I am not an expert with microcontrollers or software development(yet),  but what if I want to do something on the device that is not implemented in the API?  I suspect it might be challenging to integrate a desired feature without causing some sort of conflict on the device.  Asking the mbed developers to "PLEASE ADD FEATURE XYZ" doesn't really work unless everyone else wants it as well. Even then there is obviously no "timeline" or "guarantee" as to when it gets added.

With Arduino for instance, I can at least UNDERSTAND the limitations of the current API and judge for myself whether the platform meets my needs or not.  If it doesn't, I can still produce a solution on those devices that will work around the issue without breaking things.

The whole point is to make 32-bit ARM MCUs as easy to use and ubiquitous as 8-bit right? So is there any reason you can't make the core library source "read-only?" I don't understand how the availability of the code itself directly impacts your ability to control the development and or provide support to the mbed community?

To be clear, I wholeheartedly support your efforts in bringing this concept of mbed to the public.  I am thrilled with the ease-of-use and potential for this platform. I can't begin to describe the nerd-gasm I had when I learned how this whole thing works.  I bought one as soon as it showed up on Digi-key and I'm sure I'll have fun once I have more time to sit down and play with it.

Thanks,

Adam

P.S. Can you guys write a tutorial on how you setup & customized your Trac server? What plugins/macros do you use and what did you develop in-house? ;)

Hi Adam,

Sorry for the delay; lots of travelling :)

Adam Helmers wrote:
Could you clarify your intentions for the core library source? I have no issue with you good folks wanting to control development of the API, but I was really hoping to be able to learn more about programming for the Cortex-M3s and the LPC1768 in particular(I'm a student).  I don't know how to do that very effectively when the device implementations are hidden by the API.  I'd have to look elsewhere for the information.

Sure. The intention is that it is closed source at least in the short term as we bring up mbed. It is obviously a trade-off, but it is proving to be the right choice for now. The main focus is to get the API right to cover the 80% of use cases, then look to open it up more once it is stable.

The comments about learning are spot on however. A key focus for '10 is going to be software and libraries, and I'd very much like to ensure resources for how to code from the ground up appear. Perhaps a couple of tutorials about the M3 and how to code for that with references to the resources and examples would be a good start.

btw, I'd definitely recommend The Definitive Guide to the ARM Cortex-M3. Joseph who wrote it worked on the M3, and I find it a really good reference - detailed enough without feeling like a manual (a hard thing to do!).

Adam Helmers wrote:
So is there any reason you can't make the core library source "read-only?" I don't understand how the availability of the code itself directly impacts your ability to control the development and or provide support to the mbed community?

That will be the next logical step. But it is worth highlighting the implications if it was done now, as it would have an impact. For example, if you take a look at problems people have, they are sometimes presented as a problem with the core libraries, but usually can be quickly resolved as a problem with something else. Much of the ability to quickly track this down is due to the stability and confidence we can build up in these libraries. If it does turn out to be a core problem, it can be fixed in one place.

As soon as they are read-only, people will branch them for all sorts of reasons, modifying the behaviour with upsides (the additional features, alternatives) and downsides (incompatibilities, inconsistencies across the architecture, assumptions that mean other things wont work). This means the core libraries come back in to question in any problem report - you need the preamble of what branch of what are you using, and whether that could be the issue. It also makes it very hard to change the architecture under the API, as suddenly there is code relying on the internal architecture, and lots of branches which would all need to be brought up. In the short term, I want to avoid this and get people trying to build on top of the APIs, highlighting the limitations so we can address them; some of this may need re-architect aspects, and I want us to be able to do this as it is for "the greater good". As this is folded in over time, we get closer to that 80% and the upsides/downsides shift; this is where the read-only position may start to become more attractive.

Because the number of peripherals on a micro is a tractable problem, we can start with this position of building an API and developing it to ensure it covers the common case. With the number of peripherals you can connect to a micro, it is not, hence that being open source and community based from the start. But these can all be built on a stable API. We're also looking to introduce better version control and library publishing support for users, and we want to get this in place to help support this transition.

So I'm definitely in agreement that there are downsides, and I expect people to keep saying "it should all be open source". But also there are many upsides at this point in time which are less apparent to an individual user, but are hopefully going to get everyone to a better position in the long run. For now we'll monitor observations/functionality requests on the core library and put up a public release schedule, and concentrate on supporting people doing their higher level projects and peripherals as best we can. We can transition closed -> RO -> RW quite painlessly, but timing and stability is important.

Looking forward to help you in your projects!

Simon

Hi Simon,
my quarterly polling: any news about the open sourcing of the libraries?

Cheers,
Emilio

You have done a wonderful thing with the mbed. It is a joy to use, but as long as the source remains closed, mbed remains what it is, a useful "toy". Please open the source like you said you would. A read-only Subversion repository would be a great start. You can let us submit requests for fixes and improvements. Don't worry about forks. Developers who run off on tangents will pay their own price and learn a hard lesson they won't forget.

Later,

Ron

P.S. If limited time and resources are a factor in your reluctance to release the source, I can help you configure and manage the repository.

Ron,

I haven't visited the forums in a while, but I don't think Chris and Simon have plans to open source mbed any time soon. In the year+ since the LPC1768-based mbed was released they've obviously improved the library and online compiler, but for whatever reason they prefer to keep the long-term development plans to themselves for the most part. I've seen a few "here are some upcoming features" posts on the blog, but that is about as open and transparent as I expect it will ever be.

One of their primary goals is to provide good support to beginners and when they can control the library and compiler it makes troubleshooting much easier. I think it is probably the right choice to keep the library closed and encourage people to develop on top of the API. You or I might disagree for personal reasons, but if you are trying to compete with the Arduino crowd you need to somehow differentiate you product and services without making it more difficult to learn from scratch. Cortex-M3 is so much better than 8-bit AVR, but it will take time to educate the masses.

When I decided I wanted to get more familiar with programming embedded systems I started with mbed but my curiosity quickly led me outside of the "sandbox". It is pretty easy to combine the $30 LPCxpresso board and the Codesourcery Lite toolchain if you prefer GNU/GCC and want to have total control of your source. The learning curve isn't too steep since NXP has a good CMSIS v2.0 peripheral library and ARM has a Cortex-M3 DSP library that can assist with filtering and computation. This is the route I have taken and it has met my needs quite well.

A.H.,

Thank you for your reply. I also use the CodeSourcery Lite toolchain for other ARM products. I'm an Ol' Timer who has been doing embedded systems for 30+ years, and subsequently a little set in my ways. I advised some of my younger colleagues to use C for embedded systems, and to avoid C++, because IMO, C++ has too much overhead and can be difficult to integrate. The mbed API is great, and has made me rethink my opinion of C++ on embedded systems. I and a colleague each purchased an mbed and have been having a lot of fun with them. Chris and Simon have done a great job, and I would love to look under the hood and learn how they did it. However, until I figure out the mbed C++ platform, I have to do things the old way, without mbed, for "serious" ARM based products, because I cannot port my mbed C++ code to other ARM platforms. On the plus side, the mbed "sandbox" is so much fun, I'm looking at ways to use the mbed for "semi-serious" products by treating the mbed as a "chip" sitting on a custom carrier. It looks like others are doing the same.

Later,

Ron

Hi Ron,

I am also an old timer but a generation after yours. I started using C++ in embedded back in 1996. It was by necessity. Back then, people said C++ has too much overhead for embedded. So I was also hesitant. I was writing firmware for a Raid subsystem, IDE raid to SCSI. At first was in C but the IDE chipset changes quickly we ended up supporting many during development phase. It took so long each time to adapt a new chip. So we decide to write in C++. It has reduced the time to support a new IDE chip by half. Not only that, it also allow us to code such a way that we can substitute in the field with a different chipset. The firmware can recognize and use without the hassle of device drivers. C++ does have much overhead has people said. You can do clean & lean code. It's all in how you code it. It is more difficult for compiler to optimize it. The developer has to write lean code. We wrote the RAID firmware in less than 128KB including a RTOS kernel, 100% in C++. Migrating C++ is not more difficult than C. In fact it would be much easier and faster if the new platform support C++ of course. One important thing to remember is that C++ thinking is different. You have to change completely your mindset to think object and not procedural. I know it is very difficult to do but once you past it, everything would come into place. It took me about 2-3 years before I decide to make the switch. It was the necessity of the project that forced me to switch, otherwise I would probably not. Now I am glad that it did happened back then. Now C++ is my first choice and I'll be glad to help you if you wish. Sorry for being of topic, just want to encourage you to use C++ and be afraid of it.

Cheers

Hoan

Hello Hoan,

Thank you for your comments. You make a compelling argument. I will seriously consider C++ on embedded ARM and other platforms.

Later,

Ron

Is there any plan to make the library source code available? In my custom LPC1768 project I need to use 60 GPIO, so a lot more than that mbed modul has. Or can I use the mbed lib function DigitalOut(), DigitalIn() for other pins of the LPC1768 as well (which are not used in mbed modul)?

Hi Mike,

Not at the moment. But you should be able to do what you want. You can use any of the LPC1768 pin names for gpio or peripherals with the objects of the form Pn_n, for example:

DigitalOut pin(P1_7);
Serial port(P2_8, P2_9);

Hope that is useful!

Simon

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