I've been developing on my 2368 for a while now. Today, my collaborator Ben came over with his 1768, and I wanted to put my build on his device.

First, we spent a while wondering why nothing worked, and then I realised there was a dropdown in the compiler to pick a target device. Perhaps I am just building for the wrong device (though it would be nice to get some more explicit indication that that was the mistake I was making). But my list only has 2368 in it.

So, I doubleclicked the mbed.htm file, thinking that might introduce that device to the compiler. But, I get a complaint about that key being in use, which is presumably because it is Ben's device.

What on earth is all that about ? Is it really the intention that each device has a single registered keeper, and only that person can build for that device ?

And if that's not the plan (which I hope, since it seems to me to be a pointlessly aggravating plan), how can I build for the 1768 ?

Thanks,

Richard

Um - chaps - I know you're busy, but it would be good to know how we ought to proceed with this.

Am I right in thinking that if we both log in as the same user on two laptops, the IDE will go hilariously wrong ?

Thanks,

Richard

Hi Richard,

Sorry for the delay in replying.

Richard Sewell wrote:
Is it really the intention that each device has a single registered keeper, and only that person can build for that device ?

No, the license key enables the tools for that kind of board/MCU, so you can use it with any mbed board or external MCU of that kind once you enabled it. But you will need a key to enable the tools for a different kind of board/MCU, so it ties in to a purchase to help support them.

If you are collaborating with someone with a different board, they should still be able to publish it and you import it and compile it, or even export it as a zip and import it if you want to keep it private. It is not the slickest approach for now, but that is where we want to look at improving the publishing and version control etc. It should be possible to make it quite lightweight hopefully. We'll be looking for testers at some point.

Richard Sewell wrote:
Perhaps I am just building for the wrong device (though it would be nice to get some more explicit indication that that was the mistake I was making)

Yes, this is not very clear at the moment. The problem isn't widespreadas most people don't have two different boards, but it catches us out too. We're looking at things like it remembering what board you used last, giving you a hint in the download (e.g. <filename>_LPC1768.bin), and have even considered the mbed Microcontroller explicitly barfing at being fed the wrong kind of binary (possibly a step too far!)

Richard Sewell wrote:
Am I right in thinking that if we both log in as the same user on two laptops, the IDE will go hilariously wrong ?

It is certainly not recommended/support (but we won't stop you trying at the moment :) We have even wondered what live collaboration on the same project shared between two users would look like; lets see how google wave pans out!

Hope it is going well!

Simon

Simon - I look forward to being on your collaboration beta program! :-)

It seems to me that you have made a misstep with this license key business. Boards can legitimately be shared, lent, or given away, and you ought to anticipate that and support it. It doesn't increase your costs to enable building for both boards for all users, and it enables real-world use cases.

I was, frankly, indignant when I came across the problem. It struck me as a kind of bone-headed DRM scheme. I know you are probably fed up with discussion about the pros and cons of a web-based IDE, but I did feel sudden lurch in my confidence in the whole idea at that point. It is alarming to have the tools just refuse to cooperate because of this kind of policy. It raises the ugly spectre that there may be other board-identity policies in the future, and other arbitrary restrictions based on them.

This may seem like an overreaction to you. I think it is a reaction to the fine-grained control that you have over what the tools will do for me. If I'm going to have confidence in the system, I need to know that you won't exercise that control in any unwholesome ways. For me, this was an unwelcome first example of an unwholesome way.

For clarity, I am not trying to start a fight here. I still think the mbed, and the web-based IDE, is a great idea. But I think you need to be explicit about guaranteeing access to the tools.

The building-for-the-wrong-board issue has been a nuisance on the Arduino for ages. What I think I'd like is:

- Have each project remember what board it was built for last (since each project will generally correspond to a particular test rig, with a particular board in),

- Have a quick way of realising that I'd put the wrong kind of binary on a board. Perhaps a distinctive flashing LED pattern would do it ?

- I like your filename idea. You could also make the mbed refuse to load files with the wrong name, and again show a distinctive LED pattern when the newest file was for the wrong board. I might prefer a shorter string - myApp.1.bin for the 2368, myApp.2.bin for the 1768, and so on.

We had a good time showing off our mbed project yesterday - I'll post some pictures later today, hopefully.

Richard

Richard Sewell wrote:
- Have each project remember what board it was built for last (since each project will generally correspond to a particular test rig, with a particular board in),

I second that. It would be a very strong improvement, and solve this ticket that I filed earlier: http://mbed.org/projects/tickets/ticket/20

Richard Sewell wrote:
- Have a quick way of realising that I'd put the wrong kind of binary on a board. Perhaps a distinctive flashing LED pattern would do it ?

I second that also.

Richard Sewell wrote:
- I like your filename idea. You could also make the mbed refuse to load files with the wrong name, and again show a distinctive LED pattern when the newest file was for the wrong board. I might prefer a shorter string - myApp.1.bin for the 2368, myApp.2.bin for the 1768, and so on.

I agree with that, but am concerned that it may also create problems around your binary not working just because you (re)named it incorrectly. If implemented, I'd propose to at least do very clear distinction for the error code/display. Also output clear error report to USB Serial so it would show up in the terminal.