Hi there, My attempt to find such a suggestion failed, so here it is with all it's details:

As we have more than enough memory on the MSD for a selection of binaries, I soon missed a way to take control over the flashing process.

Here's a possibly not too unfamiliar situation: While debugging, you find some weird behavior in your recent code. To compare code revisions, you start flashing different binaries and comparing or measuring your mbed's output.

Possibly more interesting situation: Your mbed surroundings require you to disconnect it from the PC to run. To speed things up, you write different versions of a function and intend to run one after another.

The reason why we really need this: Oh, I'm sure you'll find one...

In both these cases it would be really useful if some sort of flash.cfg (or whatever) on the MSD would provide ways of selecting one binary of many based on filename, or even create a 'playlist' which would load the next binary on the list at the push of the reset button (or even a USB-COM command/magic code). To make things even more comfortable, the magic chip could print the filename on it's USB-COM if defined in flash.cfg.

Here's a suggestion, what this file could look like:

# Flash control
#flash_this = MakeMeRich_LPC1768.bin
flash_this = LookMaImAnArduino_LPC1768.bin
flash_playlist_enable = false

# Playlist control
load_next_on_reset = false
playlist_COM_control = true
playlist_next = "some string"
playlist_prev = "some other string"
#playlist_next = 0xBAADBABE
#playlist_prev = 0xC001BABE
playlist_return_filename = false

file1 = MakeMeRich_LPC1768.bin
file2 = NVICtest_LPC1768.bin
file3 = NVICtest_debug_LPC1768.bin
file4 = NVIC_WTF_print_every_register_to_UART_LPC1768.bin
file5 = NVIC_thisShouldWork_LPC1768.bin
file6 = DeadLock_LPC1768.bin
file7 = PinTest_LPC1768.bin
file8 = Relaxing_RGB_Fader_LPC1768.bin

I am aware that this asks for a magic chip firmware upgrade. It may or may not be possible/easy to upgrade. To know for sure, one needs to know the Magic Chip and it's security configuration.

I guess that's it for now...

Luke

I agree a feature that I need myself at the moment and would separate the mbed from all of its competition, probably never happen tho:(

sorry to say but I think most people in this business have no imagination or just do it on purpose, to limit the user.

take the file rename it's broke still not even fixed, you rename something copy or delete, the mbed disappears from pc too many bugs still not fixed.

I am talking about the whole embedded market by the way, you all have no imagination.

I may not be able to code but I tell you something I am dam good at doing something:)

Here is a thing I hacked together with a couple of minutes and a bit of "imagination", doesn't really do what you want but might inspire you to find a solution.

When p5 is pulled low, the program just copies its own binary (fast.bin) to a new file (fast.non), deletes (fast.bin) and resets, causing the mbed to load the next newest binary it has stored (which in this case is slow.bin (which flashes the LED slowly, obviously).

(may or may not ditch your USB file system - the wait(1) helps)

Cheers Tom

#include "mbed.h"

extern "C" void mbed_reset();


DigitalOut myled(LED1);
DigitalIn input(p5);

int copy;

LocalFileSystem local("local");

int main() {
    input.mode(PullUp);
    FILE *fp,*cp;
    while(1) {
       copy = 0;
       if (input == 0) {
          fp = fopen("/local/fast.bin", "rb");
          if (!fp)
		  {
			exit(-1);
		  }
          cp = fopen("/local/fast.non","wb");
          while(copy != EOF) {
             copy = fgetc(fp);
             fputc(copy,cp);
          }
          
          fclose(fp);
          fclose(cp);
          remove("/local/fast.bin");
          wait(1);
          mbed_reset();
       }
       myled = 1;
       wait(0.2);
       myled = 0;
       wait(0.2);
    }
}

#include "mbed.h"

extern "C" void mbed_reset();


DigitalOut myled(LED1);
DigitalIn input(p5);

int copy;

LocalFileSystem local("local");

int main() {
    input.mode(PullUp);
    FILE *fp,*cp;
    while(1) {
       copy = 0;
       if (input == 0) {
          fp = fopen("/local/fast.bin", "rb");
          if (!fp)
		  {
			exit(-1);
		  }
          cp = fopen("/local/fast.non","wb");
          while(copy != EOF) {
             copy = fgetc(fp);
             fputc(copy,cp);
          }
          
          fclose(fp);
          fclose(cp);
          remove("/local/fast.bin");
          wait(1);
          mbed_reset();
       }
       myled = 1;
       wait(0.2);
       myled = 0;
       wait(0.2);
    }
}

tried it,it is just the same as my code USB file system is always lost, is a bugs somewhere not sure where tho, Or maybe it is just because of the magic chip interface code.

The only other thing I can think of is to try and mod this boot-loader code somehow. I am just a user tho, I can't program:( this type of stuff is for people who I been doing this stuff for years.

http://gvworks.blogspot.co.uk/2010/10/usb-bootloader-for-blueboard.html

I really don't know what your all expecting me to do, but I don't see why you can't firmware update the mbed and make it like a nintendo wii or xbox or ps2, its the same kinda thing with the boot loaders.

Because USB file system is always lost this just want work to a usable standard

/media/uploads/mbed2f/lpc1700_usb_bootloader.zip

http://gvworks.blogspot.co.uk/2010/10/usb-bootloader-for-blueboard.html

I know the mbed magic chip code is pretty similar to the boot loader code above, are you ever gonna release the magic chip code so the community can mod it, I personal want to keep using the mbed but I am pretty much force to go with the lpcxpresso or blue board which I don't really want to do.

As far as I'm aware, a bootloader is slightly different to how the mbed works. The mbed uses the "magic" chip to run the USB mass storage device and to flash the LPC1768 (presumably via JTAG/SWD). I imagine the limitations of the file system are an unavoidable consequence of this arrangement. For the record, the LPCExpresso also works in this way.

You could presumably run a bootloader on the LPC1768 itself, but you would need to connect up your own usb socket etc.

I doubt the mbed team would release any magic chip firmware at the moment (for, I think, obvious reasons).

Cheers Tom

Sorry Tom,

but I think this is virtually the same thing, their is nothing special about the magic chip interface, it is not rocket science.

The boot sequence shown below is used when entering the secondary USB bootloader

/* Main Program */

void main (void) {

  /* If CRP3 is enabled and user flash start sector is not blank, execute the user code */
  if( crp == CRP3 && user_code_present() )
  {
      execute_user_code();
  }

  /* check_isp_entry_pin() function does not return if isp entry is not requested */
  if( user_code_present() )
  {
      check_isp_entry_pin();
  }
  /* User code not present or isp entry requested */
  enter_usb_isp();
}

maybe take a look at this Application note /media/uploads/mbed2f/an10866_2.pdf

secondary or the first not much difference, how many years has it been now 6 4 and still not release the source. I really like the mbed but and that is a really big BUT a lot of the community could do some really interesting things if they were given the source code for the magic chip interface.

Well there you go, you have the code, so get it working on the LPC1768 on the mbed - then you won't need the magic chip at all. It's not rocket science after all.

Cheers Tom

I am dyslexic tom I have learning difficulty's, I can't see what the big problem is with simon or Chris doing this anyway, it would take what 5 10 mins for them to do which could take me weeks, months's to do. I can not do it, I am going to have to post on a another forum for somebody to give me the code, and help me do it anyway.

I don't have the slightish clue how to mod the code to allow me to select between two bins.