If you want to communicate from a PC-based (Win,Mac,Lin) application with MBED through the USB port it seems that serial is the only option today.

Would it be technically feasible upgrading the firmware so that you would rather use the Mass Memory interface as a way to send data back an forth?  It seems that this would be simpler than baudrate settings and stuff not to mention that SUN dropped their serial Java API (because they couldn't get it to work in a reasonable way I guess).

Currently the MassStorage interface disconnects when MBED write to it, s some kind
of patch seems needed.  OTOH it may not be feasible.

Just my two cents

Anders

Hi Anders,

Anders Rundgren wrote:
Currently the MassStorage interface disconnects when MBED write to it, s some kind of patch seems needed.  OTOH it may not be feasible.

When you write from the mbed MCU to the filesystem, the Mass Storage device is marked as removed from the Host point of view, and when you close all open files, it is given back (see the notes on LocalFileSystem).

This is done because you can't have two masters in the system; both hosts will think they own it, so you need to do the equivalent of unplugging a disk from one, and plugging in to another, and then back - we just did it all in software. The underlying reason without deep-diving too much is fundamentally that it is the OSes that interpret a Mass Storage device as filesystem, not the mass storage device itself, and that's what makes sharing "below" the operating system hard.

So you may be able to achieve what you want, just in the context of the technical restrictions.

Simon

Serial and mass storage is not the only option. mbed also has its own USB and Ethernet port, which can be used to connect it to the PC directly, bypassing the "magic" chip (which implements the mass storage interface for the flash). Here I made a crappy ms paint diagram of how mbed board is connected (as far as I understand it). Note the non-connected ports.

Maybe if you tell us what exactly you want to achieve we might give better recommendations.

Hi Igor,

Love your diagram! You've inspired me to do an un-official official one:

btw, there is no FT2232 chip on mbed. The mbed interface handles all the Mass Storage, UART, JTAG, Semihosting (so in your diagram, UART0 connects to "magic chip").

Simon

Ah, thanks for the corrections. And your diagram looks much better :) I think it would make a good wiki or notebook page.

Thank you guys for sharing this information with me (and the big bunch of other people looking into the truly amazing MBED stuff)!

From what can deduct, your are stuck with serial if you want to use the USB connector on the device.   It works, but ought to be 25-50 times slower than full-speed USB.

I assume that the LocalFileSystem use JTAG since UART0 is reserved for USB-serial?  Or are the LocalFileSystem  and Serial mutually exclusive?

Sorry for so many questions :-)

Anders

If you want full-speed USB directly to the chip, you can use the D+ and D- pins. However, the USB interface is not wrapped in a class so you will need to do some lower level programming. There are some USB samples on NXP's site.

Thanx Igor,

For the prototyping I will have to stick to what's readily available and easy.  A production-like implementation may even require a unique USB interface which is a big task.  Since my project (a new kind of security token) is not a real-time application, serial will suffice for basic concept evaluation.

Anders

Hello Simon

Thanks for your explanation and the nice sketch. I just got my mbed this morning and have been playing with it ever since. It was really a joy to compile and download my "blinky" within seconds.

Now, I had a very similar understanding of the system as you drew above. It was hard to understand how can you do all the "smart" stuff without an additional "processor" on the board. It looks like the "mbed interface" is another microcontroller like thing.

I have the following question/comment:

1. I wanted to ask if it was possible, after booting up, to use the (Mass storage) USB interface as a serial output for "debug printing" ? Now after your sketch, this does not seem to be the case. You may write to "local" file system but you cannot have "live" printing. So one must use UART1 or "real" USB or ethernet, etc. for this purpose. Am I correct?

Thanks

Asif

Hi Asif,

Debug printing to UART0 works fine using the built-in USB connector.

Anders

Hello Anders

Thanks for your reply. That is really a good news. However, after searching around for quite some time, I have not found an example that shows how to do it. I could only implicitly infer from some posts that I should use USBTX and USBRX for this purpose. But how to receive it in the PC? Would it map as a COM port? Can you please indicate an example that use built-in USB (serial) interface?

Asif

Hi Asif,

Take a look at /handbook/SerialPC

Simon

Ahhaaa....! That is what I was looking for. Thank you so much. Works perfectly.

Asif

Sorry for waking an old thread but Ander's question above never got an answer:-

I assume that the LocalFileSystem use JTAG since UART0 is reserved for USB-serial? Or are the LocalFileSystem and Serial mutually exclusive?

Can we get an answer on that please?

Yes, LocalFileSystem uses semihosting calls which are handled by the interface chip over the JTAG interface.

Thanks.

Hi,

Since the lpc1768 USB is not the USB used on mbed, can the mbed library be updated to include an easy way to interface to the lpc1768 USB?  Ways to connect to a USB HID and USB MSCD would be great.  I'm looking for use the USB as a device to download large files into SRAM.  Simultaneously, I am going to transfer the SRAM data to an output port to a slave device so the file size may be MBytes while the SRAM is only KBytes.

Thanks.

Sounds like a project for the Mbed challenge!

There's plenty of LPCxxxx samples out there (Google will help you) but as for an Mbed library, as you note, none exist as yet. I think possibly it's due to the multitude of possible configurations such a device can take make it difficult to abstract as a standard library component.