Hi Sam,

I did change the USB connectod and did not notice that the order of D+ D- were swapped. It is working now.

Thanks, Mike

Hello,

I know this may seem stupid, but the very first thing I did when connecting the mbed M0 board to my computer was to... make room in the USB drive, and delete the mbed.htm file (as I already had the mbed website open in my web browser).

Later I found out the file contained the license key and I was lucky enough to be able to undelete the file.

I strongly suggest the mbed team renames the mbed.htm file to license.htm file or something like this so that people know the file is not only a shortcut to the mbed website, but also (and most importantly) the license file !

Again, I know this may seem stupid, but seriously, I am pretty sure I will not be the only one to make that mistake, so...

Hope this helps Bertrand

Bertrand,

with the original mbed the mbed.html reappeared 'automagically' when you restarted the mbed.

Did that not happen with the M0?

Romilly

Hello,

<<quote romilly>> with the original mbed the mbed.html reappeared 'automagically' when you restarted the mbed.

Did that not happen with the M0?<</quote>>

You're right, the file came back. Phew! Thanks for the clarification.

Is there any update to the issue of M0 mbed memory performance, as noted in my post of 2 Nov?

I tried updating to version 38 of the library, but no change in results. Is there another library that would be better to use?

-hb

Do the mbed LPC11U24's available through distribution have the ROM drivers?

This is due to the C standard libraries we are using:

• M3: ARM C standard library
• M0: ARM microlib

Microlib gives a tremendous advantage on the code space (very precious on the M0), but unfortunately all its stdio streams are unbuffered. This means that for each byte of the stream, it has to pass through the whole software stack.

You have to keep in mind that the microlib stdio streams where originally designed mainly to provide printf capabilities.

We are currently proposing a different stdio streams "space vs performance" trade-off to the ARM team maintaining microlib.

Cheers, Emilio

Yes.

Cheers, Emilio

Thanks for the explanation, Emilio. Unfortunately, it sounds like the solution is not right around the corner. That is a pity since, as noted by Igor S. back in November, "...Hopefully the issue won't be too hard to fix because it's unusable in current state."

Here's a random suggestion: would it be possible to add a new function to the mbed library that would allow direct access to the on-card memory without going through the file system? Something like the following:

#include   "mbed.h"
RawMemory  mbedflash;

int main() {
   mbedflash.write(intdata, address);
   mbedflash.write_byte(bytedata, address);
   (int) result = mbedflash.read(address);
   (char) result = mbedflash.read_byte(address);	
}

That's a bit rough, but you get the idea.

I'd gladly give up the filesystem and write raw data if it meant I could get reasonable performance. Just a thought...

-hb

Yes, it is possible. Tomorrow I'll make sure all the required API is available to do that.

Cheers, Emilio

Oooooooo ..

What is RawMemory

Sounds interesting

Cheers

Ceri

OK, I modified the library to allow the access to the underling LocalFileHandle class. This will give you two ways to write files on the local mbed storage:

(1) The usual standard library file system (preferred on the M3):

    LocalFileSystem local("local");
    FILE *fp = fopen("/local/test.dat", "w");
    fwrite(buf, sizeof(buf[0]), sizeof(buf)/sizeof(buf[0]), fp);
    fclose(fp);

(2) A new way bypassing the standard library file system (preferred on the M0):

    FILEHANDLE fh = local_file_open("test.dat", O_WRONLY);
    LocalFileHandle lfh(fh);
    lfh.write(buf, sizeof(buf));
    lfh.close();

This has the advantage of practically reusing the same code in both cases, it simply bypasses a layer (the microlib fwrite that was calling lfh.write with a buffer of length 1 for each byte in the buffer passed to it).

It is available in the latest library release: Revision 34.

Cheers, Emilio

This looks very promising, and I am eager to give it a try.

Thanks for the quick work, Emilio!

-hb