Hi Adam,
Sorry for the delay; lots of travelling :)
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!).
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
I may have misunderstood, so I apologise if I am asking ill-informed questions.
I thought mbed was intended to be Open Source.
Which parts will be released under Open Source-style licenses (e.g. GPL, Creative Commons, etc.)?
The tool chain? The libraries?
The schematic? The PCB ECAD? The PCB Gerber file?
GB