First, is there harm in building a bin for one MBED and running it on the other?  I can state with certainty that the couple times I've tried it (accidently) the bin doesn't run.

Second, is there a way to prevent this from happening?  In my case the default when I bring up the compiler is the beta MBED, while I'm using the new one.  Perhaps the compiler setting can be sticky?  Is there a way that the compiler page can check for an attached MBED and configure itself correctly?  How about if the bin is coded with the target, and the runtime startup checks to be sure the hardware and the image match?

Best:  Can the bins be made universal?

--steve

Firstly, the processors run 2 completely different instruction sets so no they cannot be made universal under the current methodology. (LPC2368 runs either ARM32 or Thumb, LPC1768 runs Thumb2)

Secondly the processor architectures are quite different so even with the same instruction set, the programs are pointing to the wrong things when attempting to execute the various instructions.

There are techniques to do this, but they invariably compromise the runtime efficiency of the system. (It wouldn't be target compiled, but interpreted with a runtime environment as in certain forms of Java)

ETA: This is not a simple task, OS/Runtime environment, 'compiler' and a plethora of extra bits are required.

Whether or not damage has been done depends on a number of things, one of the devs may be able to answer this better.

Hi Steve,

Steve Ravet wrote:
First, is there harm in building a bin for one MBED and running it on the other?  I can state with certainty that the couple times I've tried it (accidently) the bin doesn't run.

You'd be pretty unlucky i'd think! (but no guarantee...)

e.g. if you run code from the LPC2368 on the LPC1768, it'll pretty much load the first instruction vector (on ARM7) but interpret it as the stack pointer (M3), then fetch the second instruction vector (ARM7) and interpret as the address of the reset handler (M3). So then it'll try and jump to that address, and probably bomb out on a usage fault (called prefetch abort on ARM7). I'm not going to guarantee anything (i.e. don't do it), but *I* wouldn't worry.

Steve Ravet wrote:
Second, is there a way to prevent this from happening?  In my case the default when I bring up the compiler is the beta MBED, while I'm using the new one.  Perhaps the compiler setting can be sticky?  Is there a way that the compiler page can check for an attached MBED and configure itself correctly?  How about if the bin is coded with the target, and the runtime startup checks to be sure the hardware and the image match?

I think on all of these comments, i'd say yes, all this is possible. We've discussed all of them in fact.

Near term, I think we'll aim to put in stickiness (and also give a hint when downloading what target it is for). We were also thinking of putting in a "sanity check" in the mbed so it checked the image was appropriate, but I'm not convinced right now (most people only have one target is my guess, but at some point it'd probably have more value).

Steve Ravet wrote:
Best:  Can the bins be made universal?

Yep, this is possible. We've again got a plan on the table, and the way we'd do it would have no overhead on runtime which would be pretty cool! But it adds a level on "non-standardness", so I don't plan to do it any time soon (if ever). I think this is one of those things where doing some of the simpler options will get 90% of the benefit, so we'll start there and see what happens.

Simon